Making Digital Teams more Efficient

MAKING DIGITAL TEAMS MORE
EFFICIENT
Prepared 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 Consultant
Text100 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.

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 certain
extent, 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 is
available
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 be
completed 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 focused
Limit 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 out
inefficiencies
• 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. Proj
Mgmt 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

Making Digital Teams more Efficient

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Making Digital Teams more Efficient

Similar to Making Digital Teams more Efficient (20)

Making Digital Teams more Efficient