making digital teams more efficient

MAKING DIGITAL TEAMS MORE EFFICIENTPrepared by Julian Chow Jian Sheng

OVERVIEW

2 Julian Chow | Making Digital Teams more Efficient

To the Singapore Leadership Team at Text100:

Our office is in the midst of a pretty huge change at the moment, as we transition our work from providing typical PR services – media relations, analyst relations – to a full suite of integrated communications work, covering website building and maintenance, content development, paid media services, social media management, and more besides. We are at a point in the change where sufficient people have upskilled in these areas to allow us to take on a substantial amount of work. Indeed, it would not be remiss for me to say that we can probably form an “integrated communications division”.

What we lack, from my observation, is that we’re still stuck in the old mindset and processes of doing things. Project planning and execution is still very “waterfall” in nature, a relic from the days of PR old. Based on the work that’s been done over the past year, this does not allow our digital teams to function effectively, because the nature of the work is non-linear, unlike how a PR team would typically expect to work. Changes / iterations happen, and our processes need to be adaptable and flexible to allow for such change.

Here’s what I’m proposing.Julian Chow

Digital ConsultantText100 Singapore

4

.01 | SITUATION OVERVIEW


Julian Chow | Making Digital Teams more Efficient4

WHAT DO WE NEED TO FULFILL OUR VISION?

TO BECOME A FULL SERVICE MARKETING COMMUNICATIONS AGENCY

People & Skillsets

Process Structure

Budgeting & Profitability

Mindsets


MY PERSPECTIVE ON SUCCESS FACTORS

People and Skills

• Progressing well; hiring new people with the right skills

• Starting to diffuse knowledge through the organization

• Winning right type of clients allows people to develop skills (learning by doing)

• However, bottlenecks when people with highly-specialized skillsets are out

Process

• Lots of time wasted due to inefficiencies on either agency-side or client-side

• Process of working between the client and backend teams can be improved

• Higher volume of ongoing work means that team members need to learn how to prioritize

Structure

• Having T-shaped people allows teams to function rather fluidly and help people cover for each other once they are out

• Project managers are learning how to deal with colleagues that have different specializations and to be able to communicate in their language

Profitability

• Scope creep can be an issue with some clients due to us not properly defining scope of work

• We need a better understanding of work processes

• Tighter scope management also required

Mindsets

• Process is now iterative, not linear, when it comes to digital –that’s the biggest mindset change which needs to take place: Stop thinking there’s a finished product, instead, there’s ongoing iteration


THE CHALLENGE I WILL FOCUS ON SOLVING

Make Teams more

efficient

Improve control over work scope

Greater Profitability

Hire more specialists

Remove personnel

bottlenecks

Starting here creates a virtuous cycle that allows Text100 to keep increasing efficiency

8

.02 | AGILE METHODOLOGY FOR PROJECT MANAGEMENT


An approach based on a set of principles, whose goal is to render the process of project management simpler, more flexible and iterative in order to achieve better performance (cost, time and quality), with less management effort and higher levels of innovation and added value or the customer


WHAT IS AGILE?

From The Agile Manifesto (www.Agilemanifesto.org, Beck et al., 2001):

• Individuals and interactions over processes and tools• Working software over comprehensive documentation (or creating MVPs vs finished products)• Customer collaboration over contract negotiation.• Responding to change over following a plan

As you can see, these principles can easily be taken out of a software development scenario and implemented into a marketing communications project as the situations are pretty much the same: We are working with clients in a dynamic, ever-changing environment that causes shifting requirements.

http://www.agilemanifesto.org/

Main differences between traditional (what we’re using!) and Agile methodology (Dybå and Dingsøyr, 2008)


AGILE COMPARED TO TRADITIONAL PROJECT MANAGEMENT METHODS

Traditional Methodology Agile Metholodology

Mindset Systems are fully specifiable, predictable, and are built through meticulous and extensive planning

High-quality adaptive outputs are developed by small teams using the principles of continuous design improvement and testing based on rapid feedback and change

Planning Done once, meticulously, upfront Planning cycle is iterative, done repeatedly

Scope of Work Fixed upfront Flexible; changes with requirements

Testing Late-stage testing when near-final Continuous improvement

Client Management Client kept in the dark, only sees outputs

Transparent; Client involved in entire process and takes more responsibility

Unfortunately, evidence continues to accumulate suggesting that using traditional, rigid processes in a dynamic environment can result in significant downstream pathologies, including excessive rework, lack of flexibility, customer dissatisfaction, and the potential for a project to be fully developed, only to discover that technological advances have eclipsed the need for it. (Collyer et al., 2010)

• Highsmith, 2004 and Chin, 2004 argue that Agile practices, techniques, and tools can be adapted to other types of products and project environments, whose characteristics resemble software projects that are innovative and have a dynamic development environment experiencing constant change.

• Work by Conforto et. al, 2014, and Serrador & Pinto, 2015, has concluded (though not definitively) that Agile project management is applicable under certain conditions in non-software development circles

• The success of Agile depends on the following:• Enabling factors from within the organization

• Moderating factors which may temper the success of Agile


DOES AGILE WORK OUTSIDE OF SOFTWARE CIRCLES?

Factors Applies to Text100?

Enablers (Conforto et. al, 2014)

Multidisciplinary project teams; members with multivariate skillsets Yes

Project oriented teams Yes

Dedication of resources to single projects No

Customer/stakeholder involvement in the project planning Partially

Supplier and partner involvement across all project phases No

Co-located teams Partially

“Pizza” team size Yes

Project managers with more than 5 years experience in iterative No

Project team members’ experience of at least 2 – 3 years Yes


ENABLERS FOR AGILE

Thoughts: We have quite a fair balance of having and not having enabling factors. Some of the main points to address if we implement Agile would be reducing the number of accounts allocated to each consultant, allowing them to focus more, and training up project managers in Agile. Getting vendors / suppliers more involved in the

project phases is another thing to look into


MODERATING FACTORS

(Serrador & Pinto, 2015)(Searchsoftwarequality.techtarget.com, 2015)

Can we?

• We have some key enablers in place – such as multidisciplinary people who are accustomed to working in project environments, co-located teams (for the most part) and small working teams

• While we lack experience in Agile, training and coaching options are available. One of the bigger things to fix (which is possible through revamping the capacity plan to match skillsets) is to reduce the spread of individuals across accounts

• Our “dare to do” mentality is aligned with Agile values so from a cultural perspective, Text100 looks to be a good fit

Should we?

• We work in a dynamic, changing environment with ever-changing client needs. Briefs, especially digital briefs, as we very well know, change along the way. Agile helps us better manage this nature of working

• We currently adopting the “waterfall” format for project management, and this causes inflexibility when it comes to adapting briefs once they change, which also lowers client satisfaction. Speccing a fixed number of outputs for each brief helps us defend against scope creep but doesn’t help with client outcomes


IN CONCLUSION: CAN / SHOULD AGILE BE APPLIED IN TEXT100?

I BELIEVE THE ANSWER IS, YES, ON BOTH FRONTS. WE HAVE THE CAPABILITY TO IMPLEMENT, ARE ABLE TO OVERCOME BARRIERS, AND CAN IMMEDIATELY BENEFIT IF IT IS DONE SUCCESSFULLY

15

.03 | THE AGILE TOOLKIT



AGILE PROCESS TOOLS – SCRUM AND KANBAN

Scrum and Kanban are process tools which help teams work more effectively by, to a certainextent, telling them what to do. Note that Scrum and Kanban are not perfect. They aim, by providing certain constraints & guidelines, to create a certain way of working in Agile

Scrum Kanban

Works with timeboxed iterations (defined as Sprints) Can be event or task-driven instead of timeboxed

Cannot add items to ongoing iteration Can add new items whenever capacity isavailable

Requires roleplay (Scrum master, developmer, product owner)

Doesn’t prescribe any roles

A Scrum board is reset between each sprint A Kanban board is continuous

Tasks need to be broken down so they can becompleted within 1 sprint

No particular item size is prescribed

Cross-functional teams are necessary Cross-functional teams optional

(Kniberg and Skarin, 2010)

USING SCRUM AND KANBAN EFFECTIVELY

Scrum

• Scrum excels at projects requiring deep collaboration and innovation such as website development or marketing campaigns

• Scrum works best with small cross-functional teams (7+/-2)

• Scrum is great for providing shared goals and work context

• Scrum encourages generalists


Kanban

• Kanban can handle a lot of interrupts

• Kanban supports specialized roles with divergent skill sets

• Kanban excels at repeatable work such as a content production hub, or a website maintenance project

• Kanban works fine for groups larger than 7+/-2 since communication and planning overhead is lower

(Sahota, 2010)

A VISUAL MODEL FOR THINKING ABOUT SCRUM AND KANBAN


(Sahota, 2010)

• The vertical axis differentiates environments with a strong focus from those with many interrupts and divergent needs

• The horizontal axis indicates the spectrum from defined, repeatable work to exploratory and innovative work

19

.04 | KANBAN EXPERIMENT


Context

• OMRON is a multidisciplinary client account consisting of web maintenance, content production, social media copy production, visual asset production and paid media advertising as the types of jobs in the scope of work

• We have been having a tough time managing the OMRON account using a traditional waterfall project management method, reason being:

o New jobs (mainly website changes) happen on a daily basis that they disrupt existing workflow

o Each team member’s work depends on the outcomes of someone else, so better visibility is needed into the status of other jobs. We didn’t have a visual way of representing this work

o Unable to prioritize jobs because individual team members don’t recognize right away the dependencies between their work and that of others

• Hence, the account team tried out Kanban over the previous one-month period to ascertain if this would help us better manage the work that’s coming in, and make the team more effective


PUTTING AGILE INTO PRACTICE

•Create a visual model (Kanban Board) to observe work travelling through the system

•Making work visible allows for identification of blockers, bottlenecks

•and queuesVisualize Work

•Complete unfinished work in order to reduce wait times for other tasks to begin

•Avoid problems caused by task switching, ensuring team stays focusedLimit Work in Progress

• Improve the speed at which work flows through the system

•Remove bottlenecks (client-side or agency-side)

•Analyse workflow to anticipate future problems caused by new jobs

Ensure Steady Flow of Work

•Measure and improve on team effectiveness by looking at the time it takes for work to travel through the systemIteration and

Improvement


PRINCIPLES OF KANBAN

(Kanban Roadmap, n.d.)

BUILDING OUR KANBAN BOARD

Guiding Principles

• Break work down into as many phases as possible

• List tasks down in as minuscule portions as possible

• Colour code tickets for priority (NOT URGENCY)

• Ensure ownership of tickets

• Limit work-in-progress, making sure things get done first before starting new things, to ensure bottlenecks aren’t created


DAILY STAND-UP MEETINGS

Guiding Principles

• We enforce daily stand-up meetings at the start of each day

• Each team member needs to update verbally as well as on the board the list of things he/she is working on for today

• Project manager to remind on items that have been left in the “Doing” column for too long

• Everyone agrees on the work that is to be done by the team, as a collective, before we break off to complete tasks

• Keep meetings to 10 mins and below


FORTNIGHTLY REFLECTIONS

Guiding Principles• Ask ourselves three questions:

• What did we do well• What could we have done better• What didn’t work


What Worked What Didn’t Work What Could Have been Better

• High-priority and dependency tasks are completed first, which allows the team to move faster

• Everyone in the team gets a better big picture view

• Enforcing time to regroup and discuss allows us to plan ahead

• Discipline: Some small tasks which are completed during the day aren’t listed

• We didn’t reflect upcoming tasks until we thought of them

• Track time to complete tasks in order to weed outinefficiencies

• Involve client in the process as he controls the approvals

• Instil personal responsibility in the team to be present for all Kanban meetings and not push it out due to work

• Reduced load on project manager on chasing for deadlines as everyone knows what they’re supposed to do and by when

• Prioritizing bottleneck tasks first (such as content development) which allow other tasks to move forward faster, thus increasing overall team efficiency

• Understanding priorities allows team members to move work around or put them on hold, thus increasing mindshare, and enabling higher-quality work


RESULTS SO FAR

NEXT STEPS: IMPROVING THE PROCESS


Insert timestamps into tickets so we can grasp

how long they have been in the system

Project manager must run the stand-ups and ensure that individual

follow-ups are completed

Identify possible bottlenecks during

standups for tasks with dependencies

Break the “Doing” column into more

granular steps?

Bring the client into the process

Estimate time to complete work on

ticket

REFLECTIONS ON THE EFFECTIVENESS OF KANBAN / AGILE

Kanban has definitely been a better approach to managing interdependent workflows within a team as compared to waterfall. I particularly love how it’s less rigid than Scrum and has customizability to be used in our own way

One area in which Kanban may be weak is that it’s so focused on doing, we forget to stop, step back and think

Being able to prioritize, due to visualization of work, has helped the team be more efficient


One of the questions I have is: Is there a limit to the efficiency gains? This needs to be further explored

Discipline and rigour is key for Kanban to work –this has to be enforced through a dedicated individual

For more complex build-type work, we might need a combination of Scrum and Kanban – this needs to be explored further

I would like to attempt to quantify efficiency gains in terms of hours in order to see how far we are progressing with Kanban

• Great way for digital teams to work more effectively

• Need to find a way to quantify efficiency gains

• If we think this is successful, we also need to test the model on PR teams and see how we can adapt it


CONCLUSION / SUMMARY

Agilemanifesto.org, (2001). Manifesto for Agile Software Development. [online] Available at: http://www.agilemanifesto.org/ [Accessed 1 Feb. 2016].

Chin, G. (2004). Agile project management. New York: AMACOM.

Collyer, S., Warren, C., Hemsley, B. and Stevens, C. (2010). Aim, fire, aim-Project planning styles in dynamic environments. ProjMgmt Jrnl, 41(4), pp.108-121.

Conforto, E., Salum, F., Amaral, D., da Silva, S. and de Almeida, L. (2014). Can Agile Project Management Be Adopted by Industries Other than Software Development?. Proj Mgmt Jrnl, 45(3), pp.21-34.

Dybå, T. and Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), pp.833-859.

Highsmith, J. (2004). Agile project management. Boston: Addison-Wesley.

Kanban Roadmap. (n.d.). 1st ed. [ebook] Leankit. Available at: http://info.leankit.com [Accessed 31 Jan. 2016].

Kniberg, H. and Skarin, M. (2010). Kanban and Scrum. [S.l.]: C4Media, Inc.

Sahota, M. (2010). Scrum or Kanban?. [online] agilitrix.com. Available at: http://agilitrix.com/2010/05/scrum-or-kanban-yes/ [Accessed 8 Feb. 2016].

Searchsoftwarequality.techtarget.com, (2015). Why Agile projects fail - VersionOne surveys Agile development for 2015. [online] Available at: http://searchsoftwarequality.techtarget.com/photostory/4500251246/VersionOne-surveys-Agile-development-for-2015/3/Why-Agile-projects-fail [Accessed 8 Feb. 2016].

Serrador, P. and Pinto, J. (2015). Does Agile work? — A quantitative analysis of agile project success. International Journal of Project Management, 33(5), pp.1040-1051.


REFERENCES

THANK YOU

making digital teams more efficient

Documents