Scaling Excellence v0.1 FREE

SCALING
How to Manage
Complex
Software
Projects across
Distributed
Teams Using
Agile Methods.
EXCELLENCE
F
R
E
E

E
X
C
E
R
P
T
SCALING EXCELLENCE
How to Manage Complex Software Projects across Distributed Teams Using Agile Methods
Tony Raehalme
tony@scalingexcellence.com
www.scalingexcellence.com
FREE EXCERPT
version 0.1
10.10.2011
What is This Book About?
The Background Story
Getting Out of the Pit
How This Book is Built
The Excellence Pyramid
GLOSSARY
CHAPTER 1:
Adapting to Change 1
No Piece of Sofware Is a Clone ....................1
Long Live Questoning and Challenging ........2
Maximize Visualising ....................................3
Visualise Company Flow ........................4
Transparency and Open Communicaton,
Trust and Honesty ........................................5
Working in a Mult-Cultural Environment.....6
Collaboraton across All Departments ..........7
Conficts Are Good ........................................8
Constant Learning and Improving ................8
Track Record and Progress............................9
CHAPTER 2:
Organizing the Work 13
Delegate Proactvity ...................................14
Avoid Thrashing ..........................................15
Quality above All ........................................16
Never Rely on Overtme ......................17
Relatve Estmatng .....................................18
Scope Management ...................................19
Diferent Types of Backlogs ........................20
Project Portolio Management ...................23
What is a Project? ...............................23
Thrash tll You Drop ..........................24
Project Life Cycle .................................26
Workfow .............................................27
Risks for the Business ..........................29
CHAPTER 3:
Scrum and Beyond 31
Determinaton through Chaos ..........32
The Usual Pitalls ........................................33
Roles ................................................................... 36
Role of Managers ............................................... 42
Stop Demotvatng ....................................... 43
Short Cycles ........................................................ 44
Daily Synchronizaton ......................................... 44
Plan, Execute, Review and Refect ...................... 47
Company Sprints and Releases ........................... 48
To Release or Not to Release? ..................... 51
Big Bang or Incremental? ......................... 52
Agile Project Management ................................. 54
The Tool to Track the Whole ........................ 54
Roll-Outng Tools and Processes .................. 55
Roll-Outng through Resistance ................ 56
Inital Planning ............................................. 58
Tracking Progress ......................................... 59
Release Forecastng ..................................... 59
Decumulate Uncertainty Incrementally ...... 61
Gathering Task Hours .................................. 62
Making Team Data More Comparable ......... 63
CHAPTER 4:
Vertical Slice Development 65
A Perfect Product ............................................... 65
Short Feedback Loop .......................................... 66
Launch It Already ......................................... 68
Follow the Business Value of Features ............... 69
Product Ownership across All Layers and Tiers .. 70
Early Integraton between Teams ....................... 71
CHAPTER 5:
Organizing Teams 77
Team Room ......................................................... 77
Inappropriate Behaviour in The Team Room
78
Collaboratve Designing ...................................... 79
Practces for a Geographically Dispersed Team .. 80
Two Cases of Dispersed Teams ................. 82
Efortless, Spontaneous Communicaton .... 83
Virtual Teams and Group Forums ......................84
Architectural Governance Group ................84
Virtual Test Team ........................................85
Product Owner Group ................................85
ScrumMaster Group ...................................86
Innovaton Forum .......................................86
Preparing for Dependencies between Teams ....87
Working with Shared Resources ........................87
When It Makes Sense to Have a
Specialist Team ........................................88
CHAPTER 6:
Growing Teams 91
Theres No I in Teamwork? ................................91
Building Motvaton ...........................................92
When Charity Doesnt Work as a Common
Cause .......................................................93
Dealing with Negatvity ..............................94
I Hate Our Product! ..............................95
Ask What Motvates People .......................96
Dont Touch My Code! ..........................98
Team Building ..................................................100
Team Responsibility and Behaviour Rules .......102
Rotatng People ...............................................103
Rude Awakenings ..................................104
Overcoming Mediocrity ...................................106
Avoiding Burnout.............................................107
Great Team Focuses on the Big Picture .108
Measuring Excellence ......................................110
CHAPTER 7:
Scrum in Action 115
Teach Teams to Pull .........................................115
Building the Backlog ........................................116
Keeping the Backlog in Shape ..................117
12 Person Project Team to the Rescue ..118
Invest in Good User Stories ......................120
Estmatng Work Complexity ........... 121
Reusable and Distributable
Stories ........................................... 122
Defniton of a Ready User Story ..... 124
Company Defniton of Done .................. 125
Preparing for the Sprint .......................... 126
Task Breakdown ............................... 128
Deliberate Over-Commitng......... 129
Getng Commitment from Teams ... 130
Scrum Wall ............................................. 133
Operatonal Tasks ............................ 135
Burndown Charts............................. 135
But It Makes Me Look Bad! ....... 136
Daily Stand-Up ................................. 139
Sprint Review (Demo) ............................. 140
Preparing for the Demo ................... 141
Demo Structure ............................... 142
Importance of Proper Demos ....... 143
When Is Sprint a Failure? ........................ 144
Constant Improvement through
Retrospectves ........................................ 146
Example of Retrospectve Notes ... 148
Project Retrospectves .................. 151
Team Satsfacton............................. 152
CHAPTER 8:
Software Craftsmanship 155
Risk-Based Testng .................................. 155
Blame It All on the Tester ............. 156
Coding Practces ..................................... 159
Dealing with Legacy Code ....................... 163
CHAPTER 9:
Non-Development Teams 167
Operatonal and Support Teams ............. 168
Marketng and Sales Teams .................... 169
Last Words
About the Author
Dear reader,
Thanks for downloading the free version of my e-book. For
a bit over a year now Ive been working on this. Its not quite
done yet but I decided to put it out in the public already. I
could have easily fine-tuned it until forever (the anti-lean
startup), but I decided to release it already and maybe even
get some feedback.
This book is mostly based on experience. I have over five
years of daily experience working with agile methods which
includes 130 person projects, managing bottleneck teams,
driving organizational change and so on. This book is a story
about one mammoth project that didnt go quite as planned.
If you feel like supporting me you can buy the full version
from my website. You will receive all updates automatically.
Feedback is also welcomed.
Happy reading !
Cheers,
Tony Raehalme
10.10.2011
Helsinki, Finland
www.scalingexcellence.com
tony@scalingexcellence.com
If you handle Finnish check out my article Vallankumouksen
toteuttaminen kettersti in Projektitoiminta Magazine 2/2011:
www.scalingexcellence.com/publication
http://www.scalingexcellence.com/book
CLARIFY VISION
Courage for transparency and
open communication
SCHEDULE PRIORITIES
Focus on prevention and long-term investments
MANAGE DAY-TO-DAY WORK
Daily collaboration and commitment to goals
DEFINE THE PRODUCT AND OWNERSHIP
Early integration and short feedback cycle
ESTABLISH WORKING PRACTICES
Iterative and incremental releasing
ORGANIZE AND BUILD TEAMS
Proactivity, responsibility and efficacy
ix
F
R
E
E

E
X
C
E
R
P
T
What is excellence and how do you achieve it? Moreover how do
you scale it throughout multiple teams, departments and entire
organization? Excellence is exceptional quality that surpasses
ordinary standards. It can be anything from stunning, exquisite
skills to outstanding performance. How do you first of all achieve
outstanding performance in an organization and then make sure
it stays that way? There are no shortcuts. Excellence is what you
can achieve with continuous, disciplined daily effort when you
are striving towards a clear vision using high-efficiency methods
despite your current skill levels. It is a habit of sustainable pace
with continuous improvements. It is a long-term investment
that starts bringing results already in a short time, but if you get
impatient and violate that pace productivity degrades immediately
and you run into quality problems. Sustainable pace contributes to
stress-free environment, work enjoyment and enables possibilities
for innovation. It is a realistic way to reach remarkable results in a
systematic approach. Expect high results but in a sustainable pace.
Habits are learned and undesirable habits can be unlearned. All
it take is determination and discipline. Come up with habits that
strive towards excellence.
Scrum is a framework for agile software development and based
on industry-accepted best practices. Its proven to be a tool for
achieving that outstanding performance in software teams.
1
It
is a tool for digging out organisational dysfunctions and like a
minimum collection of best practices that get you started on the
right direction.
Honestly, it is a piece of cake to scale hi-speed Scrum teams if
there is little co-operation and dependencies between the teams,
and if they are all working on their own little islands on their own
1 [Schwaber, K., & Sutherland, J. (2010). Scrum Guide]
What is This Book About?
Excellence is an art won by training and habituation. We do not act
rightly because we have virtue or excellence, but we rather have those
because we have acted rightly. We are what we repeatedly do. Excellence,
then, is not an act but a habit.
-Aristotle
x
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
products. Scaling across independent teams is not even an issue
worthwhile discussing. Things get more complicated when teams
are working on the same product flooded with dependencies.
Things get even more complicated when those teams are
distributed across multiple locations. Great thing about Scrum is
that it comes with day-to-day duties. It provides that habituation
you can utilise. If you stubbornly stick with those routines it will
build a solid foundation for improving productivity constantly. Only
thing left will be to pinpoint the areas that produce the maximum
value in your business.
When it comes to the software development industry people
(especially more technically oriented) often have the stubborn
habit of making even the simplest things overly complicated.
Techies love coming up with highly complicated technical solutions
even for simple people problems. Truthfully it can be a lot of fun
creating technical solutions, and therefore its very tempting to
start working on a nice solution and forget about the problem
since you dont have to spend any time on actually defining the
problem. Just go straight to the silver bullet that solves everything
imaginable. For example you might over-engineer a solution for a
web-shop where at checkout you list all kinds of recommendations
what to buy, offers of the day, most sold items of the day and thus
insidiously end up making checkout a heavyweight process when
the customer really just wanted a smooth and quick possibility to
pay for the items with minimum effort. It might be nice to develop
additional features, but those extra features add to complexity and
end up costing time and money since chances are they prolong the
project. Not to mention how incredibly wasteful those are if they
werent even needed in the first place.
When is the fault ever in technology that causes projects to fail? On
the other hand even if things are simple it doesnt mean they are
easy. It requires a lot of determination to keep things simple when
there constantly emerge complicating factors from stakeholders.
Complicating factors do not necessarily have anything to do with
technology, but just with how software is preferred to be used or if
people change their minds: How customers and stakeholders are
accustomed to using software and how it supports their working
processes. Keep technical issues completely separate from people
issues and focus on delivering what is needed right now and nothing
more. Foremost that means digging out what exactly is needed and
more importantly why. Then making sure those needs are still valid
xi
F
R
E
E

E
X
C
E
R
P
T
after weeks or months as the solution is developed. If the needs
change then the solution is changed as well.
Biggest obstacle for achieving excellence is disruption in developing
those excellence-striving habits. Its a common sin to neglect
routine, recurrent events (overriding the agreed processes)
such as having planning, review and retrospective sessions in the
excuse of urgent and surprisingly frequent one time exceptions.
Maintaining automated test and build environments gets down-
prioritized and maybe even forgotten as the rush kicks in. Priorities
change too often, people leave and take their knowledge with them
(unmaintained documentation). Defects are not fixed as they pop
up, just hidden under the rug while the quality debt keeps piling up.
Quality is ignored until you hit big enough of a rock and it becomes
self-evident there is something wrong with the product. Then you
have fire after another and eventually supporting eats all resources.
One thing leads to another and so the whole project collapses like
dominoes. In software development you can make the same thing in
countless ways and technologies, and its so easy to loose focus, get
dazzled by the latest tech trend or get lost in details. Predictability
is everything. You can only have predictability if you are aware of
your history and velocity. You need to have a backbone and be able
to trace your steps where you were six months, one year, two years
ago, and where you are heading at: Short-term plans and long-term
guesses (product vision). Its very difficult to estimate the total
amount of work you are going to do even for six months because
there are so many influential factors. Thats why you have to chop
the work into smaller chunks for near future and adjust the plan as
you know more. But the velocity is always incorrect if at the same
time you are developing quality debt.
Imagine a software development department consisting of 15
distributed teams with around 130 persons. All teams have
unstandardized working practices and environments. Suddenly
those teams are all part of one big common project and responsible
for developing a joint product. How do you get a firm grip out of
those teams that are not only distributed but also have their own
working methods? How to avoid complete chaos when you start
a project across teams in a multi-cultural environment? You need
a systematic approach to tackle the situation to first of all get
everyone on the same boat with a common goal and set easily
measurable targets and milestones to follow progress. First of
xii
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
all train the people that manage the teams and give them all the
support you can. Delegate proactivity and show ways for each team
to contribute to the goal. Synchronize and standardize the working
methods and tools as well as environments (continuous integration,
coding standards and such) for all teams. Set common ground rules
for everyone and define a shared acceptance criteria.
Seems simple enough and even quite straightforward on paper.
In fact so simple that theres a big chance of failing. If all it takes
is really that easy then why do there still exist multi-team agile
projects that fail? It has little to do with the actual technology or
product at hand but a whole lot with people issues.
This book is all about the day-to-day work. This book is not about
architecture nor any other technical detail for that matter. Neither
is this about managing budgets or developing heavyweight project
management processes. This is about daily routines in working with
people from different cultures and kicking your teams to the path of
excellence in concrete steps. This is about building a collaborative
working environment that is rapid in accommodating challenging
situations. Expect the unexpected by building an organisational
culture that isnt fragile when change occurs.
The Background Story
You might wonder where is this all based on? It is easy to come
up with fancy processes and project management practises but if
those are not based on actual hands-on experience then they are
quite useless. In 2009 at a Finnish charity organization building a
gaming website there was introduced a business-critical mammoth
project to heavily refactor the current platform. This project
involved all product development teams who were not accustomed
to working together in such intense manner. To complicate things
product development department is geographically scattered in five
locations in two time zones and its a multi-cultural environment
with about 20 nationalities. Product development department
consists of over 15 teams and 130 people. Whole company has
around 400 employees.
Rationalities behind the project were to first of all get rid of a
bunch of legacy code, make the system easier to maintain and
faster in releasing new features. If you change something in one
component you shouldnt have to touch all the other components
xiii
F
R
E
E

E
X
C
E
R
P
T
as well. System stability already was there but development was
rather cumbersome. Another reason for the project was to roll-out
new commercial Content Management System (CMS) tool, which
actually was changed to another one during the project.
Most of the teams were already using Scrum framework, some
more sophistically than others. Agile methods were scaled in this
organization around a year before the project started and the
processes werent perfect or that fluent but manageable and drastic
improvements were ongoing continuously. Scrum was initially
introduced in this organization by two teams in 2006. I started in
the organization in 2005 and was one of the Scrum experimenters.
The project was definitely no picnic and didnt go quite as planned.
In the end the original half a year plan (as set by management) ended
up taking three times longer. Initial deadline was far from realistic
but nevertheless everyone did their best to meet it (apart from
overtime). When first deadline wasnt met another one was set and
yet another one until the project was actually released. Refactoring
projects are hardly ever any fun and this was no exception. It wasnt
very motivating experience since we were working on building
1:1 copy of the current site, which gave pretty strict limitations for
innovation. Honestly the project was boring as hell. But that doesnt
mean that working on it was boring. On the contrary we had a lot
of fun collaborating and learning together, and made the best out
of a non-ideal situation. Thats why its so important to build a
collaborative environment. Even if people dont exactly agree with
the goals they will give their best shot for working together.
In a way this book is a case study how a distributed organization
utilizes agile methods and manages joint projects. There are
standardised processes for managing portfolios, projects, releases,
environments and yet having enough flexibility to continuously
improve the organisational workflow. Even though in this case the
product is a gaming website these set of practices can be applied to
building any software product.
My duties during the project included ScrumMastering four teams,
mentoring one team, roll-outing an agile project management
tool with work processes for the organization, and additionally
following the overall project progress.
xiv
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
Getng Out of the Pit
Changing the CMS tool in the middle of the project and thus dropping
a part of the original plan is an interesting story itself. Amusingly
enough already in the beginning of the project it was crystal clear
for technical people in product development that the commercial
tool was a bad choice, not least because in-house competence in the
tool and technology was close to zero. But key persons in the project
saw it differently. If you stare at the selling points long enough then
of course any tool will seem like a solution to all your problems
(even for those you dont have). But you need to understand how
that tool will be integrated into the working environment and how
it fits the development processes and team working practices. It
clearly didnt fit into the sophisticated automation process that
product development had developed through the years, and it took
a year to convince the management.
But it is too easy to always blame the management even if there
exists lack of trust. There was fault also in product development
department for not driving the cause thoroughly enough and
making management truly understand the concerns. For quite
some time we were overly optimistic that somehow we will be able
to make it work even when there were countless of uncertainties.
There was fault in all of us but there is no point in blaming anyone.
The point is always to learn from mistakes, improve and move on
without bitterness, resentment or any other silly emotion.
To be fair the tool was chosen during ongoing process of
codetermination negotiations, layoffs and complete organisational
restructure, so at that time the spirit was quite low anyway. Some
little CMS tool or even the whole project was definitely the last thing
on everyones minds. When the dust started to settle some months
later the project had already been initiated and decisions made.
At that point it was tough trying to convince anyone to change any
plans and so it seemed like it was already too late. Even after failing
with the tool for half a year consultants did their best to convince
everyone that it will work and tragicomically most people bought it
and thought it is already too late to back down.
Eventually management did decide to drop the commercial tool and
go with a Plan B to further develop an open-source tool where in-
house competence was already high. By doing this the organization
basically flushed one million Euro (1 000 000 ) investment
xv
F
R
E
E

E
X
C
E
R
P
T
down the toilet in license and consultancy fees as well as in-house
development effort. It was definitely a tough call especially as it
came in such late phase of the project. It takes a lot of courage to
throw away your earlier work and start fresh. Theres always that
nagging voice that keeps taunting about the effort invested so far.
Somehow you need to realize that you are in a swamp or bottomless
pit and things are not going to get better simply by pushing harder.
The saying Quitters never win and winners never quit doesnt apply
in creative work. When you are in a dead-end, no-win situation
it makes no sense to keep going, repeating the same pattern and
banging your head to a wall. Winners are wise enough to quit, stop
wasting energy and start looking for new opportunities. As Seth
Godin writes in the Dip
2
: Quit the wrong stuff. Stick with the right
stuff. Have the guts to do one or the other.
This decision showed great leadership. Finally. Project termination
is always an option but in this case it wouldnt have made any
sense since the refactoring part of the project was nearly done.
Only thing left was to put a proper CMS tool in place to the process.
Plan B was executed very rapidly and after relentless verification
and rehearsing rounds the release took place in January 2011.
This release was by far the biggest, most complicated and riskiest
release in the history of the organization and yet by far the most
stable and predictable one.
For sure the project was an immense learning experience for all
included participants and it exponentially increased the maturity
level of the organization. Live and learn.
How This Book is Built
If I had more time, I would have written less.
-Mark Twain
This book was written applying many of the methods described in
this book. First you get the big picture straight: Start with a general
idea, maybe even a title and come up with a scope to narrow down
the subject as much as possible. Create a table of contents and try
to estimate how big of an effort the totality is. Write down anything
2 [Godin, S. (2007). The Dip: A Little Book That Teaches You When to Quit (and
When to Stick). Portfolio Hardcover]
xvi
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
that comes to your mind but constantly keep in mind the chapters
and structure. Dont get fixated on the details or fine-tuning too early
and writing perfect sentences. Focus on the big picture, add and
remove content as you go. You can write the details closer to your
deadline. Write all chapters and headings to one paper to visualise
the big picture. Come up with milestones. Follow your progress
to get a sense of accomplishment and not to get too overwhelmed
by the amount of work. Summarize and try to say more with less
words.
Ask people to review your work (also outside your field) to see
if everything is written as clearly as it is in your mind or are you
maybe missing something. Explain your book concept to outsiders.
Do they think youre on to something or just simply wasting your
time? Even when the feedback is negative dont get discouraged.
Have the courage to give your work for ruthless criticism. If people
fail to understand you its your job to make yourself understood.
You cannot really blame the receiver if the message isnt clear
enough. Analyse the feedback, dont get defensive but instead try
to see your work from other peoples perspectives and then revise
furiously.
Use some version control system so that you can press delete for
non-value adding text without a blink of an eye and yet still be able
to revert back to previous versions. If possible start working with
the lay-out to see how the end-result will look like and see what
kind of pictures you need, in which size and do you maybe need
to rearrange the chapters. Integrate different parts (plain text,
pictures, lay-out, covers, design) as early as possible. Is everything
clear for people who are not as familiar with the context as you are?
Print drafts to see how it might look like in the physical world. Come
up with realistic deadlines for fine-tuning each chapter. Finally read
the book from cover to cover to see if it delivers what you expected.
Well, actually it didnt go quite as smoothly for me. I kept pushing
the deadline a little since new ideas started popping up and I
repeatedly underestimated the amount of work. But on the other
hand I didnt work too intensively at all. I just wrote whenever there
was some extra time, usually after work or even during a carefree
work day. Hardest part about writing a book isnt actually producing
the text, but having determination in arranging it all into concise
chapters that actually make sense. A lot of times you feel like calling
it quits and moving on to something new. Motivation is always a
xvii
F
R
E
E

E
X
C
E
R
P
T
Chapt er 1:
08ll l0 0080
Chapt er 2:
0f8lIl l00 N0fk
Chapt er 3:
$0f0M 80 8000
Chapt er 4:
0fll08l $ll00 0090l0M0l
Chapt er 5:
0f8lIl 108M8
Chapt er 6:
6f0Nl 108M8
Chapt er 7:
$0f0M l 0ll0
Chapt er 8:
$0llN8f0 0f8ll8M880l
Chapt er 9:
800090l0M0l 108M8
challenge and like with everything else you need a systematic way
to take care of the unpleasant stuff.
The Excellence Pyramid
This book is built like a pyramid in the sense that the first chapter
is the vertex like a tip of the iceberg and last one the basis. There
are nine chapters in six levels. In the beginning focus is on the big
picture and each chapter dwells into more details. Nevertheless
chapters are quite loosely tied and can be read in any chosen order.
First level is where top management plays a crucial part. Vision has to be
crystal-clear for the whole company and organisatonal culture is built on
trust and honesty, transparency and open communicaton. This requires
tremendous amount of courage but sets the journey to the right path.
Whole company is focused on striving for collaboraton and establishes
opportunites for innovaton to reign.
When the vision is clear its tme to set priorites straight and get those
in the schedule. All work is visible and there is a structured process for
managing backlogs and projects. There are no death marches, projects
dont appear from nowhere and priorites are not changed every week.
There resides enough patence to see the outcome of experimentaton
and focus is on long-term investments. Issues are not merely fxed but
prevented.
Working practces are disciplined which increases predictability and
adaptability. Change is not simply adapted but initated. Third chapter
goes into the Scrum working practces how whole organizaton focuses on
iteratve and incremental approach: What it takes to scale agile methods
and what are the usual pitalls. Products are shipped monthly following a
disciplined release process. Projects are followed with litle efort and it is
possible to come up with realistc release dates early on the line. Plan is
constantly adjusted to changing circumstances and not vice versa. Plans
do not defne the future.
Vision is not clarifed only for the company but for each product that is
being developed. Defne the product and give the team full ownership so
that they are made responsible for the fnal result. Fourth chapter deals
with coming up with ways to defne value and creatng short feedback
cycle. Deliverables from all teams are integrated early by providing the
tools and environments for teams to utlize. If its not integrated then its
not done and if its not done then it has no value.
CLARIFY VISION
open communication
SCHEDULE PRIORITIES
The last three chapters are what form the basis. Everything comes
from the day-to-day work. Excellence is a habit. Its not that big
of a deal doing great sometimes, but its another thing achieving
greatness every single day.
Even though aim of this book was to have an objective view it is still
very much subjective. After all there is no absolute truth and most
things are up for interpretation. Anything stated in this book does
not represent the views of any organization or person apart from
the authors own unless otherwise stated.
If you are in a rush just browse through the key points to get a
glimpse.
Everything comes down to teamwork. In a company with hundreds
of employees its easy to get on each others way or step on
somebodys toes. Chapters fve and six deal with organising and
building the teams, and making teamwork something that everyone
regards as the core value. Responsibility is shared, common efcacy
is acknowledged and motvaton isnt defned by perks or rewards.
How to motvate people when the actual work is boring. What it
takes to make a decent team an excellent one.
Day-to-day work is consistent and represents the long-term goals.
Seventh chapter dwells into the daily work in the Scrum world. When
the project with milestone goals is clear its tme to chop that scope
into features and then user stories so that team can start the actual
work. Teams are taught to pull for work, demonstrate achievements
and given tools to improve infnitely. Sofware crafsmanship with
testng arrangements, coding practces and legacy issues are dealt
in the eight chapter: How to guarantee you are not unconsciously
increasing debt and each team is developing long-term solutons.
Chapter nine concentrates on non-development teams and how
teams that have no product arrange their work. Teams outside the
product development department also need standardised processes
to atain focus and accommodate the compelling future.
CLARIFY VISION
open communication
SCHEDULE PRIORITIES
CLARIFY
VISION
Courage for transparency
and open communication
1
F
R
E
E

E
X
C
E
R
P
T
CHAPTER 1:
Only thing certain is uncertainty. Change is simply inevitable.
Whatever the current state is it wont last forever. World is
constantly changing and only thing constant is the cycle of those
changes. Change can be hard and even painful, but if you are not
willing to change how you can ever improve and adapt to the
changing market? When the market changes are you going to
stick with your old perception of the market and drive business
accordingly? Are you sure that the perception you have today will
hold tomorrow? Embrace uncertainty. Acquaint adaption to change
into the organisational culture without artificial enforcing. After
all you cannot really change culture as its something that evolves
during time. But you can still direct its course and its a lot about
dealing with mindsets.
People resist change and uncertainty if they are too stuck on their
comfort zone when everything new feels like a threat. But change
can also be an opportunity for something better. To minimize that
resist its better to avoid big leaps and go in small steps instead.
Its very demotivating yet unfortunately oh so common that
organizations set unrealistically high goals (without necessarily
the means to achieve those goals), take on drastic changes and then
half a year later wonder why those goals werent met.
No Piece of Sofware Is a Clone
Why is building software so different from building a house or
compiling a car? What makes it so unpredictable? Every piece
of software is different and there are no clones. Even with same
the technology and tools you can still build the same product in
countless of different ways.
Biggest problems in software development have nothing to do with
technology itself. All you need to do is just always build the features
Adapting to Change
It is not the strongest of the species that survives, nor the most
intelligent that survives. It is the one that is the most adaptable to
change.
-Charles Darwin
2
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
CLARI FY VI SI ON
that bring most value with the least amount of effort. Many of the
problems lay in people issues. Misunderstandings and assumptions,
miscommunication and distrust. These are just few of the many
popular plagues that ravage and pollute the industry.
Long Live Questoning and Challenging
What is a problem? Problem is the difference between desired and
actual state. Before coming up with solution to a problem you need
to be aware of what the real problem is and more importantly what
makes it a problem. Defining a problem comes before solving it.
Root cause analyses can be done using the Five Whys
1
and Fish-
bone diagrams
2
, but these only get you so far. You also need to
understand what is the desired state. Any defined process can
hardly ever be taken into use as such. Understand the problem
before introducing any hottest state-of-the-art solution. Solutions
are context dependent. There exists no one-single-truth or silver-
bullet solution to everything. That is why you always have to inspect
and adapt. Be open to all options for as long as possible instead of
chaining yourself to one and thereby painting yourself to a corner.
By questioning you can find new paths. It has to be allowed to
question priorities and everything surrounding the business,
but prerequisite for that questioning is a non-judgemental
approach. Quite often when people are questioned they interpret
it as criticism and judgement. Its no wonder why people who go
around asking why and questioning everything all the time are
often considered as nerve-wrecking and difficult. Who would like
continuous judgement? Thats why you have to make it extra clear
that questioning is done not to criticize but to understand and
clarify. If people do criticize then they are also expected to come up
with a realistic improvement suggestion.
Constructive criticism is still criticism. It is bound to have a
destructive and limiting effect. Criticism is a very effective way
to shoot down innovation. Instead focus on giving productive
feedback that doesnt feel threatening. This type of behaviour is
1 [Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production.
Portland, Or: Productivity Press]
2 [Ishikawa, K. (1990). Introduction to Quality Control. Productivity Press]
3
F
R
E
E

E
X
C
E
R
P
T
Chapt er 1: Adapt i ng t o Change
really healthy and can save companies from bad business decisions.
It should be encouraged by the top management.
During time software architectures and configurations in integrated
systems tend to become so complex and vast that no one thoroughly
understands the whole system on a singular detailed level. Long
gone are the days when every system had a responsible person who
knew every single little detail there existed. Therefore do yourself
a favour and acknowledge your limited knowledge and start asking
questions. It takes courage to admit that you dont know when in
doubt but doing that builds integrity and credibility. Admit you
dont know the answer and it needs to be found out. Assumption
is the enemy. Assuming is the worst thing you can do. Challenge
yourself every day and dont regard anything as a dogma. Dont get
too fixated on processes or take anything for granted. If it works
then go with it and come up with ways to improve gradually, but
always have patience to see the outcome of those improvements.
Coming up with processes is easy but roll-outing and making sure
people follow those processes is another thing. People will not
respect and follow processes if there exists merely some arbitrary
meaning. Processes have to be open to criticism and altered when
needed. If an old process seems futile or leads to bureaucracy and
unnecessary handovers then change it. Just because something has
existed for a long time doesnt make it worthwhile. What waste lies
in your processes? Have courage to challenge everything.
Allow questoning and welcome productve feedback.
Maximize Visualising
Clarity is everything. Company priorities, goals and strategies
have to be known by every single employee in the company so that
people have a chance to contribute. Which project has the highest
priority? What are the targets and the ways to achieve those
targets? Visualize in company Wiki or intranet and preferably on
physical walls at each office so that it is impossible for passer-bys
to miss. Visualize all important information so that it just screams
for attention.
Scrum produces good amount of data. Gather and publish the
appropriate data. Make defects and impediments visible for the
whole company with assigned teams. While it might seem scary
4
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
CLARI FY VI SI ON
to display for everyone who is responsible for each defect in the
system or impediment slowing down development it will for damn
sure boost motivation for teams to fix their defects and managers to
solve their departmental impediments.
If you have a habit of sending lengthy e-mails chances are that
people wont even bother reading your text. If you send links
theres a chance people wont see those if it takes even a second
too long to load. An image tells more than thousand words. But if
you go to the other extreme and send flamboyant e-mails with tens
of images, different colours and fonts it will become an annoyance
and the point gets missed anew. Summarize, simplify and visualize
the key points in prioritized order and leave out the details. Those
who are interested in details can ask for the details but you should
concentrate on the majority, not the minority few. Use everything
feasible to get the point across. Come up with creative ways to
visualise data and focus on physical tangible objects.
In todays age of information overflow people are drowning on
information but the problem isnt actually the amount of data. The
problem is in the filtering of that data. The challenge is to first of all
find the appropriate information from the massive amounts of data
and secondly rephrase that key data into easily understandable
manner. Make it easy even for outsiders and people who dont know
the details to understand the point. Acknowledge that nowadays
quite few things in reality are self-evident.
Eliminate ambiguity and assumptons, and leave no room for
individual interpretaton.
Visualise Company Flow
How does information flow from one department to another?
When an idea is born how long does it take for that idea to produce
value or benefit for the customer? Visualise flow in the company to
identify the bottlenecks that prohibit efficiency and productivity. In
order to improve you must first identify the problems and best way
to grasp something is to visualise it for example on a white board.
Use Value stream mapping
3
to get an overall picture of all processes
3 [Rother, M. & Shook J. (1999). Learning to See: Value Stream Mapping to Add
Value and Eliminate MUDA. Lean Enterprise Institute]
5
F
R
E
E

E
X
C
E
R
P
T
in the company: both value-adding and non-value adding (waste)
processes. Then you have a baseline for improvements.
Transparency and Open Communicaton, Trust
and Honesty
Might seem like a noble headline but this is what truly effective
management comes down to, and nobility has nothing to do with
it. By using agile software development methods the management
gets transparency over product development but it has to go both
ways. There has to be visibility over management as well: What
are the goals and the means to achieve those goals. What is top
management spending their time on: Sipping cappuccinos all day
long or trying to find out new business opportunities? Concrete
actions with schedules are visible so that people are also publicly
made responsible for completion of those actions.
Rather give too much information than too little. It is surprisingly
usual how top management assumes lower management will
automatically represent information down to their departments,
and eventually the lower you go in the organisational ladder the
less information there exists. People just assume information flows
automatically. Give concise information regularly, keep it short
and simple, and make sure there is no room for misinterpretation.
There should be full transparency in all work unless you are
working on some super secret tasks that require confidentiality.
Just like work in a sprint is transparent and everyone is welcomed
to the review session to see whether the sprint goal was met or not.
Visibility builds trust. Without trust there can be no true teamwork.
If you love secrecy then forget about building a great, trustworthy
collaboration. Just stay in your ivory tower and pray your world
never changes.
Rumours and gossip can have a tremendously damaging and
poisoning effect in the working environment. With transparency
and keeping communication open you limit the amount of gossip.
If management encourages and practises transparency employees
feel confident enough to question the truthfulness of awkward
rumours instead of contributing to the propagation.
By default people are trusted and given certain boundaries of
freedom but with that trust comes responsibility. People are not
6
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
CLARI FY VI SI ON
going to give valuable input or be committed and motivated if they
feel they are not trusted. If they feel like they are not being listened
to or are afraid of judgment then they stop giving input. If people do
something to break that trust then stop trusting them. If someone
deliberately misuses that freedom then throw them to the wolves.
But it is definitely a screwed-up approach if first thing people have
to do is to prove their trustworthiness and everything they do is
audited. Trust people and let them do their work at peace instead
of bullying with constant supervision. Trust that people actually
want to do a good job. Trust people to make good and responsible
decisions and empower them to decide how to do their job. Clarify
the goals, milestones and timelines then meet regularly to see things
are progressing accordingly. If you dont clarify the expectations on
both sides then how can you hold anyone accountable for whatever
happens? Make sure the receiver understands your expectations
and vice versa; you are aware what kind of support the person in
question expects from you in return.
This is not to say you trust anyone blindly or live in some nave
bubble and let yourself be treated like garbage. Not at all! It is just
that by giving benefit of a doubt you make people accountable for
their actions and get better commitment for meeting their goals.
You agree the expectations from both sides together. Of course you
could try the opposite and make people accountable for every single
hour of the day, but when has that ever increased productivity?
By default people are trusted and respected.
Working in a Mult-Cultural Environment
For people with different backgrounds and cultures you need
to set common ground rules that are easy to comprehend and
adapt by all. What might be considered as humour in one culture
might be insulting in another. Terminology is the first thing to
be standardized. Like in the gaming organization with over 20
nationalities and English the main communication language, it takes
quite a bit of effort to fully understand each other since its not most
peoples native language. Even understanding each others accents
is sometimes burdensome.
Do not assume that you automatically perceive behaviour of different
cultures or draw any conclusions. Trust that people are honest and
avoid generalizations. Have the patience to understand the working
7
F
R
E
E

E
X
C
E
R
P
T
habits of different cultures without judgement or prejudice. Key is
empathetic listening. Truly listen to people without interrupting to
hear and reflect their concerns and consequently improve mutual
respect. During a discussion you really listen to what the other
person is saying instead of passively waiting for your turn and
thinking how you will reply. You dont anyway need to come up with
clear-cut answers (probably better that you dont) as long as you
show that you care and try to help. In communication the words
you say have 10% significance, 30% is how you say those words
(tone of voice) and 60% body language. If you are not sincere, it will
show. Integrity builds trust.
In Finnish culture it is common to separate your work life
completely from your personal life whereas in some other cultures
doing this is considered as rude. This is something you should be
wary about and encourage people to give more but without any
forcing or pressure. People will never do this if they dont feel safe
and comfortable in the working environment. Show the ways to
bestow but dont expect everyone always to take on it.
It is common that employees come and go. Nowadays its more
of a rarity that employees have exclusive, strong loyalty for one
employer for decades. Therefore it has to be easy and quick for new
employees to join in, understand the practices, get into the company
flow and eventually contribute. Build an environment that is easy
and inviting to join.
Lay common ground rules and standardize terminology.
Collaboraton across All Departments
It might not always be so obvious to identify teams that are not
stated in the organisational chart. Therefore you need to identify
your non-transparent teams. Top management is a team that
defines the company vision and business direction. Different
departmental heads are a team. They are in charge of making sure
their departments meet the company targets in line with other
departments. ScrumMasters form a single team. They rely on each
other for help to be able to work better for their teams and improve
quality of their teams work and organisational workflow. Product
Owners are a team that together look into most profitable products
that bring biggest value.
8
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
CLARI FY VI SI ON
Enforce collaboration not only in teams but also across departments.
There is no us and them, only we as in the whole company.
Conficts Are Good
Silent consensus is not a desired state. Its the last thing needed
if it means there are no counter arguments. Why on earth would
you want only people who always agree with you? Dont you have
the courage to stand behind your opinions and decisions, explain
your actions and views if questioned? Persons who give productive
feedback and have a different view or approach are more valuable.
Innovation isnt born when everyone just nods. Courage to challenge
each other is vital for exceptional success.
Diversity is good. Diverse groups breed diverse ideas. Innovation
comes out of different visions and perspectives. To come up with
exceptionally outstanding ideas you need synergy and many types
of different ideas to choose from. Not to mention it would be pretty
boring world if everyone just agreed on everything all the time. If
two people argue about a solution it doesnt necessarily mean one
is right and the other one is wrong. Its always relative. It might
be that both are right but with a different view or perspective,
and it just as well might be that still neither one is feasible for the
company looking yet from another perspective. Quite rare things in
todays world have one single undisputable truth. Dont get fixated
on trying to always be right.
Be open for all ideas despite the source and whether or not
you like the person presentng the idea.
Constant Learning and Improving
Constant learning and chances for experimentation are built into
the day-to-day work. If people continuously have a chance to
develop their current skills and learn new ones they are less likely
to get bored and quit. Quite contrary people are more likely to
innovate and prosper, get true satisfaction and meaning out of their
work. Even if the project is boring it doesnt mean the work has to
be. Embrace learning and improving amongst peers. That doesnt
mean you send employees to a different course every week, but
people are just given time to look into new technologies and limited
9
F
R
E
E

E
X
C
E
R
P
T
freedom to try out those technologies in practise. Leave time aside
the work for some personal development. A typical cynic might ask
what if you train the employees and they leave? Well, would you
rather not train them, prohibit their learning and let them stay?
If people are not valued they wont feel inspired and motivated
by their work. There is no purpose for the work and eventually it
turns into resentment. There is no commitment for the employer
nor there should be in that case. Dont treat people as disposable.
People are more than just resources.
Invest in people and empower the risk takers. Failure is expectable
in experimenting and learning new things, but fear of failure is
paralysing. You fear taking risks and making a fool out of yourself
so much that you never leave your comfort zone. In the Finnish
culture it is more embarrassing to fail after trying than not trying
at all. This is just simply mad! People with courage continuously
striving to improve are more valuable than passive people content
with the status quo. Failure is not embarrassing. People who have
never failed have never tried anything new. Always improve and
have stamina to see things through even if things seem bad. It just
might be that success is right around the corner.
Track Record and Progress
Those who fail to learn from history are doomed to repeat it.
-Winston Churchill
Besides the history of the world you should be aware of your own
personal history. Where were you two months, six months or a year
ago? How have you improved in the last two years? You are never
perfect. You are never quite there yet. You always have to improve.
Every single day for the rest of your life. World keeps changing and
you adapt or initiate the change and pioneer the way.
Scrum is rigorously about continuous improvement, which might
feel a little demotivating and backbreaking if you dont constantly
keep track of your progress. Sometimes it might feel there are just
too many things to improve and you are not doing very well if you
dont acknowledge what has already been achieved so far. Its not
about the destination; its about the journey. Thats why you need
10
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
CLARI FY VI SI ON
a track record that clearly shows you how each team, department
and whole organization has improved and what are the next steps
to keep on improving.
How have you improved in the last six months?
11
F
R
E
E

E
X
C
E
R
P
T
SCHEDULE
PRIORITIES
Focus on prevention and
long-term investments
13
F
R
E
E

E
X
C
E
R
P
T
CHAPTER 2:
It is not enough to simply prioritize your to-do list. You also need
to sort those priorities by urgency and come up with preventive
measures to avert the same items from popping up repeatedly. It
is vital to recognize which part of that list is truly important and
on which part you could work with preventive actions. If teams
constantly spend a lot of time on support then how could it be
prevented and time saved for more productive work? Save the
productive hours for productive work and focus on prevention. If
youre always too busy to sit down and have proper planning then
consider your priorities and measure with severe criticism what
part of your day is waste. No, its not lunch, coffee breaks or going to
the toilet. Its the non-value adding tasks that you could avoid and
repetitive tasks you could do maybe once a week instead of every
day. If someone is always asking your help for doing the same thing
then train them how to do it instead of doing it for them. Look at the
big picture and longer periods than just a few days or weeks.
You also need to chop your to-do list into manageable chunks. It is
exhausting to work on a mile-long list. You constantly need to be
Organizing the Work
Dont prioritize your schedule. Schedule your priorities.
- Stephen Convey
URGENT NOT URGENT
IMPORTANT
1. DO NOW
production issues
release support
2. PLAN TO DO
improve build and test
automation
preventive measures
regression testing
NOT
IMPORTANT
3. REJECT
interruptions from
colleagues
repetitive tasks
4. RESIST AND CEASE
pointless routines
14
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
SCHEDULE PRI ORI TI ES
aware of and visualise your progress to get a sense of achievement
every once in a while. Otherwise that list might seem like a never-
ending gigantic list and it is more tempting to call it quits than
continue. It is easy to work on the fun stuff, but you need a way to
tackle also those unpleasant duties.
Its pointless to make day-by-day schedules, because usually there
pops up unexpected issues during the day and if you havent left
enough slack then your plan for the day goes out of the window.
When your to-do list is made for a week leave slack for those
unplanned issues. Usually in software development you dont
exactly know what you will work on each morning you go to work.
Thats why iteration plans are made for a minimum of one week
instead of one day. Its a useful way to stop and apprehend what is
urgent and important, and what is not.
Delegate Proactvity
Successful delegation is one of the key elements that contribute to
the success of a project. Product Owner tells the team the end result
and value, what is needed and why, not how it is achieved. Goals and
user stories are delegated, not daily tasks. Sure way for a project
manager to loose sanity is to personally supervise completion of
each task and telling contributors how to do their job. Thats just
mad way of managing people! Making people accountable for
every working hour doesnt allow them to be very innovative at
their work, and on the other side its not very fun to supervise how
employees spend each hour of the day. Micromanaging people just
isnt fun. Hold people accountable for the actions and results, not the
working hours. Give them advices rather than orders, tools rather
than detailed instructions. By telling people how to do their job you
cripple them, make them dependent on you and limit chances for
innovation. Rather teach people how to take control and matters in
their own hands. Equip people with the proper tools and step aside.
Align company objectives with team objectives, which are then
again aligned with individual goals and ways to contribute to
those goals. Establish chances for individual improvements and
continuous personal development. It doesnt matter how you do it
as long as people have a chance to influence, improve and grow as
workers. Value long-term results and let people self-evaluate their
15
F
R
E
E

E
X
C
E
R
P
T
Chapt er 2: Or gani zi ng t he Wor k
own performance. The opposite approach is that people do exactly
and only what they are told to do. Nothing more. Imagine how that
is going to work in a project with hundreds of people.
Delegate responsibility for results along with commitment, not
tasks: what, not how.
Avoid Thrashing
Everything should be made as simple as possible, but not one bit
simpler.
-Albert Einstein
Lean Software Development
1
integrates software development
with Lean manufacturing practises which are based on preserving
value with less work and eliminating waste. Everything is either
contributing or not contributing to value. Think everything from
the perspective of value for your business. What is waste and does
not produce any value for the business? For example testing has no
business value. Testing doesnt produce anything but of course it
doesnt mean you should drop it. What it means is that you should
test sooner rather than later and avoid heavyweight testing phases
where you freeze all code for months.
Same principle applies for growth. Growth is not good if it means
that costs run up to the roof. Measure cost per income: For every
100 you earn how much do you spend?
Educate people even in the grass level to think their work from
value perspective. How can each employee in his or her daily actions
directly influence for better value or even increased income? Every
employer should feel like they have a true impact on the company
and therefore care about the business. Care as much an owner.
Employees start caring like an owner only when they feel like their
voice is being listened to. Fastest way to stop this from happening is
to maximise control and minimize initiativeness.
What part of the work brings business value (and more
importantly what does not)?
1 [Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An
Agile Toolkit. Addison-Wesley Professional]
16
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
Quality above All
Quality is everyones responsibility.
-W. Edwards Deming
Time, quality (scope) and money. Traditionally managing projects
and meeting project goals has been a lot about balancing between
these three. But, you should never jeopardize quality in any grounds.
Then again it is rare that project would have limitless amount of
time and money in its use so you have to cut from somewhere. It
is better to descope content and cut down amount of features than
deliver more with questionable quality. Prioritize features and cut
down the ones with lower priority: Deliver less with guaranteed
quality. Start by delivering those immediate features that produce
maximum value. On the other hand even if you had all the time
and resources in the world it doesnt guarantee you quality. Thats
why quality comes first and high quality is the absolute minimum
requirement that you start with. If you suffer from quality problems
then slow down development and get your act together.
What is a defect or bug? Its the difference between expected and
actual result by the customer or end user. That means if developer
considers something as expected while customer doesnt then you
have a problem. Instead of taunting the customer, Its a feature, not
a bug, and teaching people how to use your software the right way
maybe you should reconsider your approach and make products
that can be used by intuition. Training is waste unless its part of
your business model and you charge heavily for it.
Same quality requirement stands for people as well. Its the quality
of working hours what matters, not quantity. Workaholics and
adrenaline-junkies are the worst workers. They destroy productivity
by being highly error prone and disorganized in their work, not
to mention they make others feel guilty for not working 12 hour
days. Adrenaline junkies go from one rush to another switching
context constantly in the end achieving very little. Constant context
switching is very exhausting for the mind. In order to be productive
work has to be organized and prioritized. The key to efficient,
productive time management is to organize, prioritize and prevent.
Then complete tasks in prioritized order and focus on completing
rather than starting. Even if you do work 12 hour days its totally
useless if you are not working on the right things at the right time
in the right order. It doesnt make any sense if you start working on
17
F
R
E
E

E
X
C
E
R
P
T
details before the big picture is clear.
Programming is not manual labour. It is not like digging ditches in
the yard or compiling mobile phones in a factory. The amount of
time spent simply does not equal the amount of completed work.
You cannot lock ten monkeys in a dungeon for two weeks and expect
them to deliver a working piece of software. Programming is intense
mental activity and most of which is done away from a keyboard.
It requires well-rested brains and productive mind capable of
coming up with creative solutions. Defects and design failures are
commonly caused by human errors: Simply lack of concentration
and focus. Stressed out developers who are constantly pushed to
their limits and working on the edge 24/7 are the key for a sheer
catastrophe. It just creates software hardly even worth writing.
In software development you can always refactor and work more on
quality. You simply cannot have too big test coverage or emphasize
quality too much as long as you release frequently. If teams are idle
do not come up with nonsense, artificial tasks just for the sake of
it. It is more destructive doing the wrong thing than doing nothing.
Realising that you have spent the last couple of weeks on building
something that has absolutely no use causes resentment towards
the person who assigned the task, and quite rightly so. Teams can
always improve quality assurance, destroy technical debt or even
take some time for personal development and training if they run
out of work. On the long run it is cheaper to keep teams idle than
building wrong things.
Slack is good as long as its not all the time. As Tom DeMarco puts it,
slack is necessary for an organization to work effectively and grow.
2
Value keeping work prioritzed and organized over keeping
people busy.
Never Rely on Overtme
It goes without saying that sustainable pace and overtime dont
sit very well together. If there is a need for continuous overtime
then clearly there is something wrong. The day you start asking
for constant overtime commitment is the day you start asking for
2 [DeMarco, T. (2002). Slack: Getting Past Burnout, Busywork, and the Myth of
Total Efficiency. Broadway]
18
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
trouble. Overtime can be an effective method to tackle a short-term
issue for example a critical production problem. But it is always a
very short-sighted situation and never do it by forcing. You wont
get your project back on track by overtime. You might get a little
ahead but on the cost of quality, which then again prolongs the
project.
It might be a good learning experience for a team to work overtime
to save their sprint from failing. But if it is pushed outside the team
then the consequences are not good. There is nothing wrong with it
if teams want to work overtime as long as it is not a habit. Otherwise
you start loosing some of the benefits you actually gained by using
iterative development methods of not over-committing. People
wont have enough time to deal their days work before the next
day. People wear out, start making stupid mistakes and thus lower
quality and technical debt is simply inevitable. Handful of lovely
production defects are waiting you behind the corner possibly
already in the next release. Usually these issues could have been
easily avoided. A well rested mind is a sharp mind. When you push
for overtime you are actually alluring defects to your project.
Lack of resources is no excuse for doubling anyones workload.
Less resources equals less productive hours. There is no way going
around it. In any case you only get maximum of six productive hours
per day per person no matter how hard you use your whip. After
that you only get mindless zombies who are highly error prone
even in the simplest tasks, and thats no good even for repetitive
work, not to mention creative work.
Relatve Estmatng
I would rather be vaguely right than precisely wrong.
-John Maynard Keynes
Estimating is never precise. In fact it is more like a guessing game.
The longer periods and bigger entities you estimate the bigger
your error margin will be. The trick is to estimate small chunks
and concise periods so that you minimize the error margin. Even
after countless of sprints when teams are highly experienced with
estimating changes for their product there still exists an error
margin. There will always exist an error margin. Estimations are
never ever 100% accurate! Thats something you cannot escape
from. Therefore planning for too long period is simply thrashing
19
F
R
E
E

E
X
C
E
R
P
T
unless you happen to have a reliable crystal ball.
Humans are not good at estimating time simply because the human
factor is usually neglected. People tend to make up schedules
according to best-case-scenarios for super productive days without
a single interruption and without considering how much time in
reality it takes for humans to recover from hectic periods and from
each interruption. Even worse is that as soon as those estimations
are given people actually try to live up to those chaotic schedules,
usually on the cost of quality and general wellbeing. Humans are
not robots no matter how much of a cyborg you hope to be. Dont
demotivate everyone by planning projects for happy day scenarios.
If you are planning for robots then and only then you can forget
about recovery time.
Unless you are estimating entities smaller than a maximum of few
days there is absolutely no point in estimating in hours. Estimating
is done in relative measures. For example story point is a relative
unit size measuring complexity of the work. It estimates the
complexity of a given work, not time. Compare work packages to
each other and then estimate in relative units. In its simplest form
it means categorizing all work packages as small, medium or large.
In any case estimations (especially for time) usually will not hold.
Acknowledge the error margin, adjust the plan and adapt when
situations change as time goes by and knowledge of the work
increases.
People who do the actual work give the estmatons.
Scope Management
Never set a deadline with fixed, nonnegotiable scope unless you are
100% certain you will meet that deadline with the agreed scope
with high quality. Instead set milestones with goals and negotiable
scope. Constantly prioritize the content using the MoSCoW
Method
3
. In software development requirements are very prone
to change and by not carving requirements in stone but constantly
prioritising you have better chances of delivering the greatest and
most immediate business benefits early. If you dont leave any
3 [Clegg, D., & Barker, R. (2004). Case Method Fast-Track: A RAD Approach.
Addison-Wesley Professional]
20
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
room for change in the requirements then you better be damn sure
that those will never change and are 100% accurate even after the
release.
MUST have is first priority content and absolutely must be part of
the first release. Without these features project is a failure. SHOULD
have is second priority and these features are equally important
but not needed in the first release. These directly contribute to the
project success but in latter releases. COULD have requirements are
less critical nice-to-have features that for example might increase
customer satisfaction, but do not directly contribute to the project
success. These can be dropped without drastic impact. WONT have
are least critical features that wont be part of the first or second
release, but are an option for future releases.
Diferent Types of Backlogs
There are different types of backlogs such as a company backlog for
visualising project and program priorities, project backlog for all
releases, release backlog with all the products and features, product
backlog for each team and finally a sprint backlog that contains the
work for each iteration.
Company backlog is the parent and portfolio. It includes all ongoing
projects and programs in the company. Everything has to be listed
and prioritized in this list, otherwise it is hidden and non-prioritized
work that will definitely cause misapprehension sooner or later.
Teams are not allowed to work with any hidden projects, because
there is a big chance they are thrashing. Every project is visible
and represents company vision. There really is no reason why any
team would want to have hidden projects since getting your project
prioritized also means you get support from the management. If
Company Backlog
(Projects/Programs)
Project 1
Project 2
Project 3
1. Epics / User Themes
2. User Stories
3. Estimated User Stories
Product A Backlog
(Team Backlog)
Sprint 1
Sprint 2
Sprint Backlog
(Estimated User Stories)
Product A
Product B
Product C
Release 1 Backlog
(Products/Features)
Project 1 Backlog
(Releases)
MUST
INCLUDE
Release 1
Release 2
Release 3
Release 4
SHOULD
INCLUDE
COULD
INCLUDE
WONT
INCLUDE
21
F
R
E
E

E
X
C
E
R
P
T
the priority is low then it is not current and resources should go to
higher priority item.
Company backlog is prioritized by the management (or the person
having the role of Chief Product Owner) once a month and these
priorities have to be visible and known by every single employee
in the company. If there appears a conflict between projects for
example in resources, getting environments or support it has to be
crystal clear which project has highest priority. Despite the projects
first priority is always current production e.g. critical production
issues and second priority is the next company release. If there are
any quality issues all teams always have to stop whatever they are
working at and give their full support for fixing the issues. Keep
your table clean at all times.
Project priorities cannot change every week. It is exhausting for
the mind if you have to switch context constantly and work on a
different project every week, or even worse every other day. There
has to be stability and predictability in the working environment.
Multitasking is overkill and deteriorates productivity. In any case
it is more efficient to start and finish one project at a time, instead
of sharing resources all over the place and requiring one person
to work on five projects. If at all possible complete projects one
by one. Complete ongoing work before starting new. One whole
team could work on several projects at the same time, but that is
not optimal use of resources and just leads to low productivity.
At bare minimum dont let teams work on multiple projects in a
single sprint. The most ridiculous situation I have seen was when
one team was working on four (4) different projects in a single two
week sprint.
Project backlog includes the content for each release with all the
features. Each project has an assigned project manager and an owner
(sponsor) from the management who has the mandate to make
decisions regarding resources and budgets. Some would argue the
need for having project managers when using Scrum as the duties
are usually divided by the Product Owner and ScrumMaster. In its
traditional form (creating work breakdown structures, assigning
tasks and making up Gantt charts) it really makes no sense or if
there is just one team working on the project. But when there are
multiple teams working in a project there has to be a single person
who is responsible for making sure project delivers exactly what
is expected when things dont go quite as planned. Value comes in
26
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
a similar fashion. Project meets its end when objectives are either
achieved or no longer applicable and therefore its terminated.
One feature clearly isnt a project. Neither is something that one team
can complete on their own in a single sprint. If the work requires
proper planning, effort from several teams and prioritisation then
it is a project and should be visible in the company backlog.
Project Life Cycle
Project has four phases: proposal, planning, execution and closing.
Project must first pass a defined entry criteria before accepted to
the company backlog. Only projects that are seen as valuable for
the company are accepted. Prerequisite for acceptance is a project
charter, which is a single 1-2 A4 pages short document that states
the business opportunity, deliverables, risks, scope, timeline,
objectives and participants of the project. It has to be crystal-clear
what the project is about and what value it delivers. If the project is
accepted to the backlog initial planning starts.
During the execution phase plan is adjusted in according with the
actual progress. This is not plan driven approach and release dates
Idea! Project
proposal
(1 A4 page)
PMO accepts
project to
backlog
Management
prioritises
project as #1
All teams plan
together
All teams
execute plan
Marketing
planned
Company
release
Marketing
executed
Follow-up & improve

COMPANY SPRINT
1 day 1 day 1 day
27
F
R
E
E

E
X
C
E
R
P
T
are always made using project velocity, not by any wishes or hopes
of customers. Schedule is made from the estimations of people who
do the actual work and scope is not fixed. After goal has been met
and deliverables validated a proper closure is held to systematically
improve project work. Additionally having a closure creates a sense
of achievement so that people are ready to move on. Its important
to celebrate even small achievements and give as well as receive
appreciation.
Workfow
So how does this all work in practise? First someone gets an idea.
That idea is so good that the person wants blessing from the
management. It also requires considerable amount of work and
therefore project proposal is definitely required. So the person
starts working on the project proposal and books a time slot with
the PMO. Research and preparations are done beforehand so well for
the idea that PMO accepts it to the company backlog and so the idea
formalises into a project. If the proposal hadnt been good enough
for example missing mandatory information like what resources
are required then it stays rejected until acceptance criteria is met.
Idea! Project
proposal
(1 A4 page)
PMO accepts
project to
backlog
Management
prioritises
project as #1
All teams plan
together
All teams
execute plan
Marketing
planned
Company
release
Marketing
executed
Follow-up & improve

COMPANY SPRINT
1 day 1 day 1 day
28
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
PMO doesnt make any decisions regarding whether a project is
worthwhile or not. That decision belongs to the management.
Purpose of the acceptance criteria is solely to guarantee that the
project has really been thought through and sufficient information
is available for the management to make that decision.
In the next prioritisation meeting the management goes through
the backlog. The idea in question is a great opportunity to beat
competitors and pioneer the market, and it can even be completed
in a single company sprint if all teams contribute. Therefore it
is prioritised as first priority as at this point there are no other
conflicting projects of higher importance. If there were ongoing
projects then those would be completed before starting anything
new. When a project cannot be completed in a single company
sprint then it is divided into several releases. Each company sprint
always leads to a release even if its only an in-house rehearsal.
Whole company is immediately informed that there is a new first
priority for the next company sprint so that there are no surprises
during the planning day. All teams are not only encouraged but
obliged to contribute to the completion. When the company sprint
planning day comes the management informs that the goal is to
release this project with the given features. Each team answers
whether or not they can commit to the goal. This means every
single team in the organization, including non-development teams.
Each Product Owner has written stories and team estimated those
before the planning. In planning these stories are only broken
down to tasks. As soon as the plan is ready for execution and it is
clear what is developed and released, how and when, marketing
department can start planning their campaigns. Latest on the
release day marketing campaigns are executed.
When the idea reaches the market its time to actively follow-up on
the value that materialises. Releasing new features has no value if
nobody is using those features. Most important part is always to
analyse the produced value and improve everything for the next
round. In this case the value is increased revenue. If the same
thing is done again which part could be left out to produce the
same value? Or what could have been done to achieve more value?
Maximise value and eliminate waste.
29
F
R
E
E

E
X
C
E
R
P
T
Risks for the Business
If a project has no risks, dont do it
-Tom DeMarco & Timothy Lister
Risks cannot be avoided, but they should be managed and
prevented. Every business needs a systemic way of analysing risks.
Failure Modes and Effects Analysis (FMEA)
5
is a very effective
procedure for illustrating risks of a system classified by their
severity and likelihood already in the early design phase. Come up
with a structured process to evaluate risks not only on project level
but also at business level. When you identify risks then mitigate
those risks systematically.
Risk management is not hard but takes some effort. Easiest way to
do this is to uphold a risk chart displaying impact and probability.
Mitgate risks and uncertaintes.
5 [McDermott, R. E., Mikulak, R. J., & Beauregard, M. R. (1996). The Basics of
FMEA. New York: Productivity Press]
ESTABLISH
WORKING
PRACTICES
Iterative and incremental
releasing
31
F
R
E
E

E
X
C
E
R
P
T
Scrum and Beyond
CHAPTER 3:
When it comes to software development Scrum has evident proof
of delivering high quality in the littlest time. It is an iterative
and incremental approach in controlling risk and optimizing
predictability. Scrum is a not a heavyweight process. In fact it is not
a process at all. It is a framework that provides merely the backbone
or skeleton to build upon. Scrum alone is not enough. It is just the
start. It doesnt give you the answers, but it does bring forward the
issues you suffer from. Most of it comes down to common sense and
it is up to you to decide how to tackle those issues. Scrum exposes
problems laying in the organization and teams, and it also exposes
poor performance from team members. Scaling Scrum does not
only affect product development department. It will and absolutely
should affect rest of the organization as well, such as sales, business
and finance and this is something to prepare for.
From a team members perspective in traditional projects when the
project is frustratingly dull like refactoring projects often are
it is very tempting and fairly easy to be a slacker (speaking from
a personal experience). Hide n slide between the tasks. Sure, you
are working on a deadline, but not really that committed to specific
tasks and no one is actually following how long you are working on
a single task. Just take your time. You can spend your days browsing
interesting tech articles while on the side doing some actual coding
work every now and then whenever you feel like it. Only do the bare
minimum to make it seem like you are progressing. Just make sure
to come up with something nifty to say to your project manager in
the weekly meeting: Maybe you ran into unexpected complications,
problems with the environments or whatever BS. All in all, probably
not very productive if you think about the progress of the project
you are working on.
This is just the opposite in Scrum where you are forced to stand up
next to a Scrum Wall together with your peers and pick up post-it
tasks and report progress every single day. Sounds quite horrible
for a slacker who may be used to working in an ultra-relaxing pace
alone in his or her own comfort, but in the end it makes work a lot
more enjoyable, because you know exactly what is expected from
you and when. Nobody is allowed to come yell at your face, I heard
32
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
ESTABLI SH WORKI NG PRACTI CES
DETERMINATION THROUGH CHAOS
Agile practces were scaled in the gaming organizaton around 2008,
a year before the refactoring project was started. It all originated
from 2006 when the team where I was together with another one
by our own initatve we started practsing Scrum methods. This was
done to frst of all reach stability, focus on long-term plans and create
more collaboratve working environment and additonally to make
teams work more visible for outsiders with public demos.
It was not uncommon at all that priorites changed every week
when one stakeholder was shoutng louder than the other. The
management was informed about our trials and also briefy trained
about these methods in order to create awareness. Since it worked
for us other teams picked on it and a couple of years later it was
decided to scale Scrum across all the teams. So it was a basic botom-
up approach. One department afer another was trained and support
from the management was eventually received afer benefts were
proven. Priorites werent allowed to change overnight anymore.
Scaling included common company sprints with joint planning,
reviews and retrospectve events and also common releases with
agreed Defniton of Done. All stakeholders were required to atend
planning and review sessions and product development started
pulling from other departments instead of getng pushed like in
the bad old days. Rest of the organizaton started to accommodate
the working practces of product development. Enthusiasm spread
around and eventually other departments such as sales and
marketng also started experimentng with Scrum methods.
It was a complete chaos at least for the frst half a year afer company
sprints were introduced. A lot of the tmes it felt more like thrashing
than productve, but stll we didnt quit before the real benefts
started to show. Productvity prety much hit the ground foor when
compared to the past. We spent most of our tme building integraton
environments and improving automaton instead of developing. It
requires determinaton to keep going even if things look bad and
worse than before. You have to comprehend the maturity level of the
organizaton and remember that big changes take tme. If you quit in
the middle then the whole efort just turns into waste.
33
F
R
E
E

E
X
C
E
R
P
T
Chapt er 3: Scr um and Beyond
you were supposed to do this!. Everything has to be visible on the
task board. There is no guilt for getting a little behind on your tasks.
Not to mention that when you are stuck you get help from a fellow
team member without even asking, latest the next day.
In Scrum world it is a lot easier to be a project manager, because
Scrum produces a good amount of data and you dont have to care
about every single detail. There are many tangible phases how you
can measure project progress and manage deviations from the
plan. Instead of asking you can just look at teams Scrum Wall and
burndown charts to see their progress and issues. Instead of holding
weekly status meetings you can just go to teams demo session or
try out the product yourself in their environment to confirm they
have delivered what they promised.
It is always challenging to keep people intrigued with the project
unless on the rare occasion that the project is actually so fascinating
that it thrills all participants. But even then people tend to get
demotivated and bored eventually: Usually because the progress
isnt what it should be or due to hindering factors or just the working
environment (either physical or virtual). Using Scrum wont solve
that, but it helps to keep focus and visualises the problems early. A
team member doesnt have to suffer alone for weeks. Have patience
and understand the learning curve things just take time.
During a large change process things ofen seem to get worse
before they get beter.
The Usual Pitalls
In a lot of cases when organizations or teams claim Scrum doesnt
work for them it is merely lack of discipline and dedication of
following through. When you run into problems during a change
process it is easy to blame the thing that initiated the change. In
the beginning it is vital to do everything by the book to assure
everyone truly understands the basics in day-to-day experience,
along with the real work. You can start experimenting after fully
interiorizing, but you cannot expect to start running if you cant
even walk straight.
The usual pitfalls can be pinpointed to three categories: lack of
commitment and focus, bending the rules and fear of change.
42
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
(individual success is not enough)
Collaborate with other teams
Everyone else that might have a business input or asset is a
stakeholder. One of the first things to do in a project is to identify
all stakeholders.
Best way to get processes rolling at an enterprise level is to give
strong training and support for the ScrumMasters and Product
Owners. Strong leadership in these roles can really do wonders.
Product Owners need training how to estimate value for their
products, build a backlog out of that value and split it into workable
chunks that fit into one sprint. Product backlogs have to be
standardized. ScrumMasters need training how to support and
build their teams. This is where the Product Owner Group and
ScrumMaster Group forums come in place. These are the correct
channels to train the people that manage the teams, introduce
new processes for the teams and make sure everyone is aligned in
realising the company vision.
Product Owner decides WHAT the team is working on and
more importantly WHY. Team decides HOW they do the work
and ScrumMaster sees to it that the work gets DONE!
Role of Managers
Unlike is sometimes suggested different managers definitely have a
role in Scrum but they are freed from spending or more like wasting
their time on supervising daily tasks. Instead managers can put
maximum focus where it actually matters: More on the business
side and improving the whole working environment. Destroy
bureaucracy and anything that comes in the way of teamwork and
collaboration.
Managers have to get involved in the teams work which by
minimum means participation in the sprint demos and showing
that they actually care. Communication cannot go only one direction
(top-down) and managers have to go in the trenches to listen to
the employees. Jurgen Appelo in his book Management 3.0
2
talks
about managers who do all they can to keep people active, creative
2 [Appelo, J. (2011). Management 3.0: Leading Agile Developers, Developing Agile
Leaders. Addison-Wesley Professional]
43
F
R
E
E

E
X
C
E
R
P
T
and motivated. It is the responsibility of managers to empower
employees and come up with creative ways to build commitment
and excitement for projects. Every work needs a sense of purpose.
Every employee deserves autonomy and trust to make decisions
regarding their own work.
Stop Demotvatng
Traditional Finnish way of managing people is to stay silent when
things are going great and start shouting when there appear
problems. Never even consider encouraging anyone, open your
mouth only when someone screws up or departmental results have
not been met. Be the cynic who always finds something negative
to say. This is an excellent way to destroy motivation and increase
resentment. When people make mistakes or their collaborative
behaviour is not ideal those persons have to be confronted, but that
shouldnt be the only time you talk to them. Instead praise good
work and provide ways for poor performance to improve.
It has been studied that employees often quit not because of the
actual work or the company but because of their immediate
supervisor.
3
People quit their managers. Even when employees
love their work its easy to make their life miserable by mistrusting,
blaming, micro-managing, and giving only negative feedback. There
exists research
4
showing that its actually more important to stop
demotivating rather than motivating employees. Employees seek
equity (respect and fair treatment), achievement (being proud of
the work) and camaraderie (productive relationships with peers)
from the work and its up for the management to fulfil those goals.
As long as the basic functions (job security, salary, benefits) with a
decent working environment (physical and virtual) are there the
management doesnt have to worry about motivation. Developing
a purpose, celebrating achievements (giving credit for a job well
done) and building a collaborative, encouraging atmosphere will do
the trick. Have direct conversations with individuals and groups,
3 [Harvey, P., Stoner, J., Hochwarter, W., & Kacmar, C. (2007). Coping with Abusive
Supervision: The Neutralizing Effects of Ingratiation and Positive Affect on
Negative Employee Outcomes. The Leadership Quarterly, Volume 18, Issue 3,
Pages 264-280]
4 [Sirota, D., Mischkind, L. A., & Meltzer, M. I. (2006). Stop Demotivating Your
Employees!. Harvard Management Update, Vol. 11, No. 1]
44
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
show interest in employees ideas and give people a chance to give
input.
Management empowers, energizes and does all their best not
to discourage employees (just stay out of the way).
Short Cycles
Team iterations in Scrum are 1-4 weeks. The longer the iteration is
the harder it is to manage and estimate the appropriate workload.
Four weeks is actually too long time and theres too big of a chance
for the sprint plan to go bonkers. Even three weeks is long and
should be only allowed in exceptional situations. Two weeks is a
good recommendation.
Sprint consists of planning, execution, review and retrospective. If
the team is new and unaccustomed to working in sprints it is very
practical to create a two week cycle flow to get the team in the
pace of working in sprints. Teams need predictability and stability.
Sprint length is not varied and for example every other Monday is
spent for sprint planning and every other Friday is for the demo
and retrospective. That means eight full days are reserved for the
actual work and the team always have a few days off with weekend
in the middle before starting something new.
Some people are against having sprint planning on Mondays, but
personally I have had no negative experiences with Mondays.
It usually feels good to plan on the first day of the week and the
previous demo on Friday already feels like ancient history. There is
long enough break between the sprints to achieve closure and focus
on the upcoming work. But the day doesnt really matter as long as
a constant flow is maintained. In any case its good to experiment as
long as the experiment lasts long enough to truly see the outcome.
The goal starting already from day one is to deliver production-
ready features by the end of each iteration.
Create a fow of working in sprints.
Daily Synchronizaton
Most meetings in any field of business are sheer waste and should
45
F
R
E
E

E
X
C
E
R
P
T
be avoided at all costs. Usually meetings are unorganized without
a clear agenda, poorly planned and lack proper before-hand
preparation from the participants, outcome is weak and hardly any
decisions are made. In general they are more like casual chatting
sessions with colleagues aiming for boredom all on company time.
The amount of meetings in Scrum is one reason why people get
cautious but Scrum meetings are actually different. They are time-
boxed, have a clear focus and always with an agenda. Commonly
people who criticize the amount of Scrum meetings tend to
overlook the fact that these are the absolute maximum lengths and
people are not supposed to belong to multiple teams and projects.
Make it a habit to start all meetings on time, keep a fast pace, never
overtime and always within scope. If certain subjects dont concern
all participants then take it offline. If someone is missing then
dont wait, just start without them. It is not efficient to come up
with any kind of penalty system, because it makes being late and
absent acceptable. If someone is late or absent, confront them in
private and say it is not acceptable behaviour. Some people like the
attention they get when being late and would gladly pay fines in
advance for permission to always be late.
When teams are scattered in several offices take full use of video
conference systems. It is the bare minimum to have one at each
office. Forget about phone conferences simply because there is
always too much noise on the lines and communication wise it is
important for people to see each other even if it is just a virtual
reflection.
Daily Scrum, also known as the daily stand-up, is a maximum of
15 minutes meeting where the team members report to each other
where they are with their tasks, what are they going to do before
the next check-up, is something holding them back and do they
need help. It is a lot more than just a status meeting and reporting
where you are with your tasks. Otherwise everyone could just send
an e-mail. It is an opportunity to check that everyone is on track,
to collaborate and moreover encourage team members to work
together as a team. If one member is not sure what to do then rest
of the team suggests ways to contribute in meeting the sprint goal.
Scrum of Scrums is a handy tool for digging out issues in the
organization. ScrumMaster or any other team member from each
team reports the status and progress of the teams sprint. Also
46
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
non-development teams such as system administrators, sales and
customer support participate in the meeting to make their work
more transparent and in synch with the development teams.
Anyone in the organization is free to join the meeting, listen what
is going on in the organization and ask clarifying questions or give
a comment if something has been misunderstood. At situations
where a team might be working on the wrong thing its important
to speak up. People are encouraged to question matters and not to
take anything for granted: Not to criticize but to support each other
in always delivering value. If something seems odd or doesnt sound
quite right its for the Lead ScrumMaster to investigate further.
Unlike the Daily Scrum this meeting can be considered more of
a status meeting as there are more participants and it should
never-ever exceed 15 minutes. With 15 teams it means absolute
maximum of one minute each. Therefore all subjects are kept on
a very high-level basis. The teams cannot say they are working on
some mysterious inside projects and there is nothing new to tell.
The teams just say which user stories they are working on, are
there any issues preventing them for meeting their sprint goal
and do they need any help. Are there any foreseeable issues that
might jeopardize the deadline (sprint demo)? Have they possibly
encountered anything that might cause harm for other teams? Are
they able to meet the Feature Freeze date for the next release and is
their release testing on track?
If certain teams are taking longer then cut them short and focus
on the big picture: Does the spoken issue really require the
participation of each team representative? Even a minute per team
is quite long. You can always handle issues after the Scrum of Scrums
meeting with solely the involved teams. There is no need to involve
all teams for every single issue. With such a group of people it is
too easy to waste time and if it happens recurrently participants
will start to resent the meeting, and rightly so. Keep it daily, but
have it on a lightweight basis. You can also use this meeting to go
through critical defects, impediments and status of the next release
but keep in mind the time box. ScrumMasters are full-time and
represent multiple teams. It will become quite an uncomfortable
situation if there are 20 team representatives all waiting for their
turn to speak. It is actually a good practice that team members
occasionally attend this meeting along with the ScrumMaster so
that they start looking at the big picture.
47
F
R
E
E

E
X
C
E
R
P
T
Just as the Daily Scrum this meeting is an opportunity to synchronize
the work: Confirm that every team is on board, assist other teams
if someone is on distress and moreover an opportunity to ask for
help. Some teams might be accustomed to suffering in silence but
that is not acceptable if there is a possibility for others to help. If
teams are aware that the progress looks bad then they are obliged
to report it. It is not acceptable that a team sprint fails but outsiders
were not aware of it. It is not acceptable that one team fails to meet
the Feature Freeze date for the company release, but it wasnt
announced beforehand.
People can behave in these meetings as they wish and the group
in question decides the behaviour rules. Especially the Scrum of
Scrums meeting can easily turn into overly-serious, uncomfortable
church gathering and it is the chairmans responsibility to keep
it efficient yet laid-back. If people are relaxed and can have fun
together its a lot easier to be efficient.
Be prepared that it is only a matter of time before some participant
starts arguing how these daily meetings are waste of time taken
away from real work or whatever. This is quite a poor argument
that doesnt bear the light of day. Compared to more traditional
processes these set of rules are really nothing. It is definitely not too
much asked that every member gives a small amount of their day to
keep others posted on what they are working on and to check that
everyone is on the same page. There exist by far worse time wasters
in a usual working day. In that perspective it is waste of time going
to the toilet and having a coffee break.
Start by synchronizing teamwork daily in all levels that make
most sense.
Plan, Execute, Review and Refect
Besides the daily meetings sprint planning, review and retrospective
are the only mandatory meetings there exist and each has a special
role. None of them can be skipped. If you have a hard time managing
even these then there is some serious lack of dedication.
In the sprint planning Product Owner suggests user stories for the
sprint, which team then breaks down to concrete tasks: Detailed
plan for the next two weeks. Team together with the Product Owner
agree the sprint goal, length and sets times for the review and
48
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
retrospective.
Sprint review (demo) is open for anyone interested and mandatory
session for stakeholders to participate. You need to emphasize to
the stakeholders and rest of the organization the importance of
sprint demos. Demo session is the right forum to give input. Demo
session is the time and place to check if everything is delivered as
expected. Not organizing some random meetings or status check-
ups for each stakeholder.
In the retrospective meeting team together with the ScrumMaster
and Product Owner reflects on the sprint and comes up with
improvement action points to be taken into the next sprint.
Stakeholders and managers can take part whenever possible,
mainly as observers.
Company Sprints and Releases
Releasing and especially the frequency of releases is a commonly
debated subject. There is no clear-cut answer since it is context
dependent. It all depends on the product you are building,
development practices, environments, release process and more
importantly how often is it ideal for your business to release new
software? Essentially you release when you get something done
instead of leaving it on the shelve to dust but releasing too often
can also be a problem.
Companies with a large customer base should always avoid doing
sudden big (or too frequent) changes, because you need quite a lot
Teams Sprint #1 Teams Sprint #2
Retrospective
Joint Sprint Planning
Release
Quality Gate 2
(Company Demo)
Quality Gate 1
(Feature Freeze)
Company Sprint (1 Month)
49
F
R
E
E

E
X
C
E
R
P
T
of time to research the effect and profitability of those changes and
in worst case you might actually alienate your customers. Change
always creates resistance. Rather make those changes gradual. If
the customer base is small then maybe it is not such a big deal that
there are constantly popping up new features or the new version
is drastically different from the previous one. But for a large
customer base, like in the gaming organization there are hundreds
of thousands customers, it is simply out of the question! Instead
you work on smooth changes, inspect the effects of those changes
and then improve. Find the perfect balance that suit the customer
needs and your vision.
When scaling Scrum a workflow is made to cover the overall process,
which means company sprint that consists of joint planning,
execution, review, release and retrospective session for the release
and sprint. In this example the company sprint is one month (four
weeks) and includes two team sprints (two weeks each). If the
company sprint is longer you need additional team sprints since
you definitely want to limit every team sprint to two weeks.
There are pros and cons for synchronizing sprints for all teams but
the advantages overweight the negative consequences. Downside
is that you have 15 sprint demos in a one or two day period. Then
again nobody is usually attending each demo so its not that big of
a deal. But even if the sprints are not synchronized those have to
be aligned with the company sprint schedule. All teams plan on the
joint sprint planning for their first sprint and are done with their
second sprint before the company sprint ends. Synchronized sprints
COMPANY SPRINT
W
E
E
K

1
MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY
Company Planning
Team Sprint #1 Planning
W
E
E
K

1
W
E
E
K

2
Team Sprint #1 Demo & Retro
W
E
E
K

2
W
E
E
K

3
Team Sprint #2 Planning
W
E
E
K

3
W
E
E
K

4
Company Demo
Company Release
Company Retro
Team Sprint #2 Demo & Retro
W
E
E
K

4
50
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
contribute to predictability, stability and ease communication
as well as organizing. Its easier to require participation from
stakeholders when team demos are always held around the same
time (that time of month). Its also easier to communicate working
with environments for example system administrators can never
perform any system upgrade during demo days.
Both team sprints include planning, review and retrospective
sessions. Release work is visible in teams sprints and each team
has a separate user story for release tasks in their second team
sprint. All teams take part in the joint sprint planning no matter
what they are working on. All teams have to be present so that it
is easy to collaborate, get commitment from each other and solve
dependencies across teams. If some team is missing it makes
planning a whole lot harder, because you cannot be sure of their
commitment and the worst thing you can do is to assume that
everyone is on the same page.
At the start of the planning the company sprint goal along with
the release candidate products are presented by the Chief Product
Owner (or alternatively the Release Manager). Teams are informed
what features would be desirable to release from the companys
perspective. Teams can also propose additional content. Its the
duty of the Chief Product Owner to coordinate with teams about
their content (before the planning) and either reject or accept their
proposals. Each team then goes though the content and decides
what they can complete before the Feature Freeze date. Then
team holds detailed planning for their first team sprint. Theres no
point in making a detailed plan for the second sprint yet as things
might change. Each team notifies whether they commit or not to
the company sprint goal and content. If not then their content
is descoped out of the release, and company goal and content
are re-evaluated. This is the time to speak out if there are any
uncertainties. Commitment means that team does everything in
their power to meet that deadline and they will be hold accountable
and responsible for their words. By the end of the day it has to be
crystal clear for everyone which products are going to be released
during the company sprint.
At some point you need to freeze all code to verify content is
high quality and nothing has broken when adding new features
(regression testing). First Quality Gate is the Feature Freeze date,
which is the deadline for new development. After Feature Freeze
51
F
R
E
E

E
X
C
E
R
P
T
no code changes are allowed apart from bug fixes. At this point you
can give the whole release in for testing for all interested. You can
even arrange an in-house testing session for each release. At bare
minimum the testers from all teams take part in assuring the quality
of the release. At this point the state of quality and likelihood of the
release is already clear. If there are still critical defects then its a
clear sign that teams lack dedication for high quality and root cause
for those defects are analysed. Teams have to be overly critical what
they consider as ready to be released.
Length of the Feature Freeze period should be as short as possible,
because the longer it is the harder integration becomes and there
is no point in having new development frozen half the time. It is
possible to discover quality problems earlier in the process. Point
of Feature Freeze period is not to start testing and you wont get
better quality simply by prolonging the freeze. Its purpose is solely
for verifying that everything has remained in high quality. Second
Quality Gate is the company demo, which is the deadline for bug
fixes. If there exist problems with any of the content then those
have to be descoped before the demo, so that the release is not
jeopardized. All content must be easily removable so that in case
of quality problems the release can still be carried out without the
problematic features.
To Release or Not to Release?
In the company demo the sprint content (features waiting to be
deployed to production) is very briefly demoed on a high-level
basis to the whole company and the session lasts for maximum
of 30 minutes. Just like in the teams sprint reviews quality report
with conclusion (GO or NO-GO recommendation) is presented by
the quality representative. What are the risks for the release and
is it safe to deploy the content to production? Quality Assurance
department only gives a recommendation and even if its a NO-GO
the release can still happen. The Chief Product Owner makes the
call and either accepts or rejects the release. If the presented risks
are smaller than potential business or opportunity loss due to not
carrying out the release then green light is given.
If the content is rejected then no new development is started before
the release content is in acceptable shape. The factory line doesnt
move even an inch until the problems are fixed. When the content is
accepted the release is held the next working day. If the release gets
52
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
BIG BANG OR INCREMENTAL?
At early phase of the refactoring project it was decided to have
a big bang approach for the release, because among other
legitmate reasons it would have been quite challenging to make
big architectural changes gradually. That would have additonally
meant maintaining two producton systems simultaneously and
the efort to release incrementally seemed quite big. It didnt
seem bad approach at the tme as the negatve consequences
for incremental release did override the positve for example in
complexity. But in retrospect it was far from optmal soluton since
the release got prolonged on several occasions and the scope just
kept growing bigger and bigger. During the project everything
imaginable was changed including the whole hardware. That
meant a VERY risky release, not least because there practcally
was no rollback possibility other than taking the old site back
online and thus loosing all events occurred in between.
Milestones and frst release was planned with estmated user
stories. Project lead together with the Lead Architect and a few
team architects had estmated the whole project to take around
a year. That wasnt good enough for the steering group as they
wanted the project to be released in six months. Even though
teams didnt see it as realistc everyone did their best to meet it.
Afer those six months it was even more evident the CMS tool is
inadequate but critcism was ignored and instead a new deadline
was set. Needless to menton that this was a very frustratng
situaton. Since company sprints didnt end up with producton
releases, rehearsal releases took place instead. Project was
incrementally built on the shelf.
Big bang approach is risky. If for any reason you have to quit
halfway through for example face project terminaton then
you have nothing to show for. Same applies for large-scale
organisatonal changes. Dont take overly ambiguous quantum
leaps on changing the whole organizaton overnight. Chances for
it to go down to hell are extremely high. There is always resistance
to change and the bigger the change the bigger the resistance.
Even if the cause was something everyone would eventually
support (even world peace) there will be people saying It wont
work and instead of contributng to the success they hold on to
53
F
R
E
E

E
X
C
E
R
P
T
the status quo and have no will to change. Unknown is scary and
people need tme to adapt to change. Big changes are hard to
impose and you have much easier chances to success when you
focus on selling small yet frequent incremental changes.
On the other hand there are examples of successful large-
scale big bangs. In 2007 enterprise cloud computng company
Salesforce.com transformed from waterfall development to agile
development in just three months.
1
Entre R&D organizaton
with 30 teams and 200 persons was converted overnight. An
organisatonal change program was launched with a dedicated,
fully empowered cross-functonal roll-out team (members
from each area of the organizaton) and 30 ScrumMasters and
35 Product Owners (initally program and functonal managers)
were sent to training. Experienced, outside coaches were hired
to assist and the whole roll-out process was transparent. But
the key for its success was the strong executve commitment to
change the entre organizaton overnight.
1 [Fry, C., & Greene, S. (2007). Large Scale Agile Transformation in an On-
Demand World]
58
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
Inital Planning
There is no point in creating a detailed plan too early, because first of
all it requires a tremendous amount of effort and secondly chances
are that some of those details are actually incorrect (when you have
to guess) and the effort put to planning would then become waste.
Start with the big picture and figure out the details when they
become current. Nobody starts building a house by first choosing
what kind of the curtains will be (well not a practical person
anyway). Create a timeline and milestones with targeted goals.
5

Then those goals are turned into batches of features and minimum
scope (with MUST and SHOULD content) to fulfil the goals. But that
scope is not fixed. Keep your options open for as long as possible
and leave flexibility in the plan for the details.
If you create a project plan and estimate release schedules with
fixed scopes you need estimated user stories that define the
complexity of the project. In other words a project backlog with
release contents and product backlogs from each involved team.
That means every involved team goes through what is needed
from them, each Product Owner creates user stories and the teams
estimate those. Only after having done this you get a sense of how
much the total work actually is. Without these estimated user
stories the schedule you might make is completely unreliable and
gives a false sense of predictability. Estimating project completion
without user stories is simply guessing with a high error margin.
Epics and user themes are created to sustain long-term focus and
product vision, but no schedules are planned by using solely those.
But creating a project backlog with user stories is a lot of work and
you definitely dont want to do it in vain if we are talking about 15
teams. Usually there is no point in creating user stories for too long
time ahead, because the likelihood for thrashing is high since its
very difficult to estimate in detail the work you are going to do for
the next half a year.
Better approach is to define the goals for each milestone and
maintain estimated user stories at least for the next but no more than
two company sprints. One company sprint (one month) includes
two team sprints and every company sprint leads to a release. If not
5 [Poppendieck, M., & Poppendieck, T. (2009). Leading Lean Software
Development: Results Are not the Point. Addison-Wesley Professional]
59
F
R
E
E

E
X
C
E
R
P
T
to a production release then at least a rehearsal release. Project is
built incrementally and the outcome of the project is usable after
each sprint and added increment.
Milestones with goals are made for every second company sprint
(four team sprints). Even though each company sprint has its own
goal it is not made as a milestone, because then there would be very
little slack. With two company sprints even if one team sprint (two
weeks) fails there are still three team sprints left to get back on
track.
Tracking Progress
For tracking projects across multiple teams gathering completed
task hours from each team can be useful but hours alone tell you
pretty much nothing about the progress. It might just as well be
that earned value and actual completion is 0% while completed
hours show 50%. Track progress in entities where it makes sense
and not on too fine-grained, detailed level. User stories and features
make more sense than hourly tasks. For user stories you need to
focus on completion instead of ambiguous percentage.
It doesnt make any difference whether a user story is 1% or 99%
completed. Its business value in both cases is zero. Only 100%
completed work matters. There is no almost done in Scrum. Partial
work has no value. User story is either 0% or 100% done. Therefore
progress increases only when user stories are 100% completed.
Completed means developed as well as tested by the team and
verified as well as validated by the Product Owner and stakeholders
in the Release Candidate environment. Completed equals usable.
Useful hierarchy is Project Team Product/Feature User story
where you track the progress of each product by how many user
stories are completed.
Progress increases only when something is completely done
and verifed.
Release Forecastng
How many sprints will it take to finish a project? Release forecasting
is a crucial part of any project. It is not enough to have a project
burndown with remaining work. You also need to visualise the
60
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
61
F
R
E
E

E
X
C
E
R
P
T
completed work and the total amount because those are prone to
change. If the remaining work stays the same sprint by sprint you
need to identify is it because nothing gets completed (unexpected
complications) or is new work being introduced (clarified scope).
After each sprint is completed the figures (to-do and done story
points) are updated. New user stories are added to the backlog
as new things popup. It is expected that the total amount of work
changes as more work gets done and understanding of the whole
gets clearer. It is impossible to know everything beforehand in a
project that lasts for months unless you have earlier completed
exactly the same kind of a project with identical scope, same
technology, same resources and so on. So, unless it truly is a
clone you have to expect the unexpected and prepare adapting to
change. Along the way you realize that to meet the project goal and
milestones you need to complete other work as well and your old
perception either clarifies or might even completely change.
Project backlog includes work from all teams. Forecast is calculated
by using the company sprint schedule and velocity which you get
only after completing at least one sprint. It is the amount of story
points all teams have completed during a sprint. Future sprints
are estimated using the average velocity (mean value from the last
three sprints).
Adjust the plan as you go.
Decumulate Uncertainty Incrementally
In a hypothetical example on the left we have a large project that
has been given eight months time to deliver. Writing user stories
for the next eight months wouldnt make any sense so the totality is
divided into three milestones.
Before starting the project there exists a great deal of uncertainty.
User stories are written throughout the project for upcoming
two company sprints and after the third milestone all remaining
work have been estimated. The complete amount of work remains
uncertain until the third milestone. User stories are the details that
help us to meet those milestone goals and decumulate uncertainty.
DEFINE
THE PRODUCT
AND
OWNERSHIP
Early integration and short
feedback cycle
65
F
R
E
E

E
X
C
E
R
P
T
DEFINE
THE PRODUCT
AND
OWNERSHIP
CHAPTER 4:
Vertical Slice Development
A Perfect Product
Im actually as proud of many of the things we havent done as the
things we have done.
-Steve Jobs
Why is it that so many companies want to flood their products with
excessive amount of features? Why is it that companies have to
make the amount of features a selling point? Not even necessarily
the right features just as long as there are plenty of them. Its like
being a jack of all trades and master of none. It makes more sense to
be best at something with full effort than putting little bits of effort
into everything and unintentionally watering down the whole with
lack of focus and dedication.
Trying desperately to account for everything, satisfying everyones
needs and gratuitously increasing amount of features only creates
complex products and end up making the users confused. Products
become more complicated to use and companies need to invest
more in training, not to mention that the threshold for new users to
start using those grows. Apart from some engineers people usually
dont want to read lengthy manuals and brick size specifications.
Software has to be intuitive and effortless to use with low learning
curve. It is difficult to get new customers excited about complicated
products.
According to the Pareto principle roughly 80% of the effects come
from 20% of the causes. In software around 80% of the benefit is
derived from 20% of the features. In 2002 a study made by the
Standish Group
1
showed that 45% of features and functions in a
typical system are never used, 35% rarely or sometimes and merely
20% of the features are used always or often. That means 80% of
the features are simply waste and should be removed. Its better
to piss off few persons using those features of minimal value than
spending tons of money on building and maintaining something
that majority of the users ignore. Features of little value are
1 [Standish Group International Inc. 2002]
66
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
DEFI NE THE PRODUCT AND OWNERSHI P
removed to reduce complexity, and making the product simpler to
use and easier to maintain.
Do only what is necessary and as simple as possible. Market is
changing constantly and you cannot account for everything at an
early phase. That is why you have to be able to change and release
software fast and simple. It is simply a necessity to support constant
refactoring.
Dont deceive yourself into building things that might be needed
later. If it is not needed right now or theres even a slight hesitance
of its usability then dont bother. If you are lucky you might have
guessed right but what are the odds against you? Can you take the
risk youre wrong? Dont waste your time. Building services that
might be needed later and making maximum flexibility as your
prime goal increases complexity. Eventually your project scope
will hit the roof and the whole shabam will become too heavy to
maintain. In reality you are just building future legacy. If it is needed
later then you build it later. Focus on releasing small set of features
as early as possible and build the system in such a way that it is easy
to change and add new features.
Product is not perfect when it has all the features in the world
and when you can no longer come up with anything to add. That
would be just a mess like an overfilled suitcase that doesnt stay
closed. Product reaches perfection when it only has the core
relevant features left of which even a single one cannot be removed.
Achieving this is the objective.
Product is perfect when it has only features with maximum
value.
Short Feedback Loop
If I had asked my customers what they wanted, they would have said
a faster horse.
-Henry Ford
While it is true that most customers really do not exactly know
or understand what they want that is no excuse for delivering
something that has no demand. If you are further developing an
already existing product then instead of guessing you minimize the
feedback cycle. If you are starting from scratch then first you identify
67
F
R
E
E

E
X
C
E
R
P
T
Chapt er 4: Ver t i cal Sl i ce Devel opment
a Minimum Viable Product (MVP). MVP consists of one or several
Minimum Marketable Features (MMF)
2
, the smallest portion of
work providing value to customers. Come up with a solution to an
existing problem: means to achieve benefit and desired state. Once
you identify a need you release an increment of that solution to the
market, get the feedback and alter your product vision accordingly,
then release second and third increments and so on. The longer
you wait for the next release the harder it will be. Scope expands
and expectations grow. If you bind yourself to one release per year
then odds are already against you. Better be damn sure you built
the right features at the right time. Otherwise you just missed your
chance!
Identify most valuable features by frequent releases. Find out early
if there really is need for the features you are building or are you
just wasting your time. Bottom line is to make products that you
want to use yourself and focus on the end-users that actually use the
products. They are the ones that judge whether a product is needed
or not. Architecture, technology, specifications or any technical
mambo jumbo doesnt matter if the actual user experience isnt
appealing.
In company perspective short feedback loop means that all
employees can use release candidate versions and everyone has
access to test environments. Chances are that stakeholders had a
completely different idea than the Product Owner. Therefore you
need an environment where people outside the team can go check
what the product feels like in practice. Even better if it isnt needed
to wait for the sprint demo. Trying out the products and giving
feedback has to be made easy and effortless.
Everyone can influence the design, not just designers and engineers.
Everyone can give input and all improvement suggestions are
strongly welcomed. That is not to say you implement every little
crazy idea you get but you definitely listen to those! Do not even
implement every change request you get. Instead identify which
ones of those change requests are truly necessary and beneficial:
Which feature brings the most value with the least effort. If the
value/effort ratio isnt good enough then ignore it.
Some companies even release in-house press releases before
2 [Denne, M., & Cleland-Huang, J. (2003). Software by Numbers: Low-Risk, High-
Return Development. Prentice Hall]
68
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
starting to build the actual product or feature. Doing this enforces
not only getting input from employees but also creates awareness
for the idea. If the feedback is negative and seems like there wouldnt
be enough demand then the idea is either improved or just ditched
before wasting any time on implementation. If the decision is to
proceed in building the actual feature then that press release works
as a requirements document and backbone to what the product can
be compared to along the way.
There is one thing to look out for in building prototypes though.
Beware of making them look too good too early because otherwise
people think it is ready for release no matter how many times
you explain it is only a prototype. If customers see good looking
graphics they probably forget the backend work. Leave some clear
signs that it is merely a draft and work-in-progress so that people
cannot make any false assumptions.
Release ofen in small increments with minimal set of
marketable (core) features. Even beter if you can get feedback
for ideas before building.
Launch It Already
If you are not embarrassed by the first version of your product,
youve launched too late.
-Reid Hoffman
Ideas alone without execution have little value. What can you do
with only an idea? How far can you go with it? Even a killer idea
can be ruined with poor execution. Its the execution that matters.
Even though it usually is the best not the first product that reigns
the market you simply cannot improve enough without any actual
releases. If youre not embarrassed by the modesty of your initial
version of your product when you ship then you waited too long.
Otherwise how can you tell you are going to the right direction?
Perfect timing is a tricky thing to estimate. Release early and
improve your product vision gradually because fine-tuning without
releasing is risky. You can end up polishing your product for too
long. Then when you finally get around to release your perfect
product and by chance somebody else has already beaten you to
it your whole effort becomes futile. As soon as you have the core
features in decent shape launch it. Then you will see if customers
69
F
R
E
E

E
X
C
E
R
P
T
understand your vision.
Lean Startup
3
is a concept focused on validated learning and
ferocious customer-centric rapid iteration. Rather than waste time
on elaborate business plans you test the vision continuously, adapt
and adjust before its too late. A feature is not done before the
impact on customers is measured.
Follow the Business Value of Features
There is surely nothing quite so useless as doing with great
efficiency what should not be done at all.
-Peter Drucker
How much value is earned by features? Product Owner estimates
the business value when building the product backlog which is
quite challenging but it is only an estimation. It is not the end of
the world if the estimation turns out to be fallacious. Point is just
to start doing it and get better at it. But it is not enough in simply
forecasting business value you also need to follow and come up
with a practise in counting the earned business value. It might not
make sense on such a small scale as a single user story or feature.
Instead count value in entities that make most sense such as epics,
user themes or multiple features.
If user stories are not producing value then everything surrounding
is useless. Thats why you have to be aware of the increase or
decrease of value. Value of course depends on the given product
and context. It doesnt have to be direct revenue and it can also be
measured by the usage and popularity compared to other features
or earlier versions. Value can also be in terms of saved time (less
clicks or navigation) and increased efficiency depending which
type of feature is in question. This value is then compared to the
cost, which can be counted for example from the development
hours spent with the user stories. If the return on investment is
poor then backlog is re-evaluated and the effort put in where the
value is higher.
Are you building the right things?
3 [Ries, E. (2011). The Lean Startup: How Todays Entrepreneurs Use Continuous
Innovation to Create Radically Successful Businesses. Crown Business]
72
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
Build and Release
Management
Server
Version Control
System
Developer
Build Artifact
Repository
Manager
Team Development
Environment
Company Integration (CI)
Environment
Release Candidate (RC)
Environment
Performance Testing
Environment
Stage
Envinronment Production
you set it as your target right from the start. This doesnt contain
only the vertical layers but also all the verticals layers integrated
together horizontally.
In order for multiple teams to work together common continuous
integration environments are simply a must. To get it rolling for
multiple teams the minimum setup of required environments
are development environment for each team as their private
playground, Company Integration (CI) environment for all teams
to integrate their products from day one whenever something is
started and a Release Candidate (RC) environment where you have
only the completed features that are going to the next release.
These do not need to be physical environments and virtualisation
provides much more effortless solutions.
Apart from teams personal development environments all of these
are shared and open for all employees. Idea behind openness is that
anyone in the company has access to browse the RC environment
to see what features have been completed and what is going to
the next release. Are all teams delivering exactly what is expected
or have there possibly been any misunderstandings? More
importantly theres a chance for everyone to try out all the products
73
F
R
E
E

E
X
C
E
R
P
T
and give feedback before releasing. Usually the development and CI
environments are broken because teams are constantly developing
their products there and trying out new things. CI can always have
incomplete features but everything in RC stands for 100% done and
ready for production. Additionally there is needed a production-like
Stage environment where you store the clone of current production
for troubleshooting, experimenting and a place to run rehearsal
releases. This environment should be as alike to production as
much as possible including the hardware. Otherwise doing releases
includes more variables and leaves a lot in the hands of faith.
Doing releases shouldnt have any uncertainties whatsoever and is a
fully replicable, repetitive process without any failures. Everything
that is feasible to automatize is automated and manual intervention
is minimized. Rehearsing the same release 10 times in a row doesnt
generate into a different outcome. Running all scripts returns a
replicable outcome. Additionally there can also be a performance
testing environment for testing stability, load handling, scalability
and so on. Of course there can be additional environments as well
but this is just the bare minimum setup.
Developers work on their local machines and commit code to
Team Development
Environment #1
Team Development
Environment #2
Team Development
Environment #15
Release Package
Release Candidate (RC)
Environment
Reference RC
(previous release)
Production
Company Integration (CI)
Environment
Performance Testing
Environment
...
74
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
the version control system as often as feasible (multiple times a
day). Version control system defines the versioning policies for
branching and merging. Bottom line is that teams are not allowed
to hide in branches to first of all achieve transparency and secondly
to avoid merging nightmares. There exists no single solution that
applies for all imaginable possibilities in all companies and teams
as it all depends on the product and working practices. Solution
thats ideal for you might not be feasible for others. Build and
release management server holds configurations for the builds,
which are then imported to the build artifact repository manager.
All archives and packages are stored here. Deployment targets and
environments are configured in the build server, which exports all
builds and packages from the repository and deploys those to the
target environments. All deployments can be scheduled and theres
no need for any manual intervention. Manual work force is needed
when things go wrong and the system fails to recover by itself
e.g. something gets stuck along the way whether its caused by a
network or power outage or any other inconsistency.
Teams can basically update their own environments and CI as they
wish, but no manual updates to RC environment are allowed. Ever.
All content is automatically built and deployed through a release
package configuration, which is basically a list that contains all the
packages and archives required by the release. By doing this you
first of all verify that all release content is in the release package
and ensure that teams are following the process and not doing
any quick-n-dirty solutions or fixing defects manually. If teams
are allowed to make manual fixes to RC then you somehow have
to make sure those fixes go to production as such and theres a
chance those fixes will be missed. Manual updates shouldnt even
be possible. Everything concerning the release content installation
is automated. This way you can at any given time install the whole
release content to any given environment.
RC is built every day from scratch with the release package to make
sure the environment has all the latest content. Teams always
demo from RC. If something is not available in RC then it cannot
be considered as done. If you cannot use the feature there then it
simply doesnt exist. When team completes new features during
the Feature Freeze period (no updates to RC allowed) then those
features are demoed in the next team sprint demo.
There are many different ways how to compile this kind of
75
F
R
E
E

E
X
C
E
R
P
T
integration setup and switching content and applications from one
environment to another. There exist many great tools in achieving
this with rather small effort but the key point is that the process has
to be fully automated. Content switching between environments
and any other kind of repetitive, routine work is sheer waste of time
if done manually, not to mention its staggeringly boring and highly
error prone job. It is not at all that seldom you accidentally deploy
wrong version of an application if you are doing it manually and
have 10 other applications to worry about.
If you have to start from scratch then building this automation setup
is quite a workload but the return on investment is definitely high.
All of this comes down to preventing defects as early as possible,
equipping teams with appropriate tools for building high-quality
software and pressuring teams to work together towards common
goals.
Letting defects slip by to production is substantially expensive
and embarrassing. Test everything is a naive illusion you might
get from people with very limited understanding of testing. Just
imagine the exponential growth of the amount of your test cases
and the volume of work when you set yourself to cover all possible
use scenarios with all possible parameters and their dreadful
maintenance. Dont get fooled you can prevent all your defects
by simply adding more testing resources. Sufficient integration
environment setup is the first step to start with and something you
simply cannot live without, or it will eventually hit you hard for
sure as death and taxes.
If feature is not working in the Release Candidate environment
then it is simply NOT DONE.
ORGANIZE
AND BUILD
TEAMS
Proactivity, responsibility
and efficacy
77
F
R
E
E

E
X
C
E
R
P
T
CHAPTER 5:
Organizing Teams
In order for the team velocity to be reliable and teamwork stable
team formation should stay intact most of the time. If the team is new
then it is especially important that there is stability and formation
doesnt change every other week. Estimations are team dependent
and if you change the team formation after work estimations are
given then those become invalid.
It is not recommended to have specialist teams such as dedicated
testing, database, user experience or design teams, because this
creates handovers which then causes queueing time and severely
slows things down. Increasing knowledge-sharing isnt good
enough justification for specialist teams, because there exist other
ways like having virtual teams. Creating specialist teams increases
dependencies and complexity, and should be avoided unless
there truly is a good cause. Instead have all the required skills for
completing a feature in a single team and try to make that team as
cross-functional as possible for instance encourage the designers
to pair program with coders. This enforces knowledge-sharing
and appreciation of each others work. If during a sprint some
member is idle then pair up or work in groups instead of coming
up with artificial tasks. If at any point there exist tasks that only one
member can do then immediately pair up. If one member is away
everything doesnt fall apart.
Single team member cannot be expected to be able to build every
aspect of the feature but the team should be. Having specialist
teams also causes teams to concern only about their part instead
of the totality. Cross-functional end-to-end feature teams makes it
possible to spot potential problems way ahead and develop systems
that aim for maximum user experience from day one.
Pairing is caring.
Team Room
Scattering a single team across different locations makes
collaboration much harder and will never reach the same standards
78
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
ORGANI ZE AND BUI LD TEAMS
INAPPROPRIATE BEHAVIOUR IN THE TEAM
ROOM
Years ago together with a team I belonged to we had a very awkward
situaton dealing with outside people in our room. The room was
mainly reserved for our team, but additonally there was one man
who ofen had a female colleague visitor from another ofce. As
they seemingly worked on the same project she ofen spent weeks
at our room. Besides the intrusive noise they made afer a while
they started to behave in a very, lets say hmm... inappropriate
manner. Meaning she sat on his lap as they made out there right
in front of us like we werent even in the room. Needless to say this
is outrageous behaviour at a work place.
We mentoned this to his and our bosses but to our surprise didnt
get any support. Therefore we confronted the couple but as they
didnt get our discrete hints we decided to write on the room white
board, People not belonging to this room are not allowed to stay
here longer than 15 minutes. As the man saw this he went bonkers.
He wiped it out and yelled how dare we judge their relatonship,
and furthermore suggested to the person writng the text to take
this outside in the streets. Yet management stll refused to deal
with the situaton even afer numerous complaints from us. How
could we possibly get any work done as there was such distractng
behaviour ongoing?
The man was a bit of a troublemaker and had been forced aside
from his own project due to frequent unexplained absences and
other reckless behaviour. Basically he was coming to work every
day just to surf on the net while socialising with his girlfriend.
The situaton eventually escalated so bad that the guy actually
came to work with a baseball bat and threatened his former project
colleagues. This violated the very basic need every employee
deserves: safety.
This situaton could have easily been avoided if the management
had just stepped up and dealt with it accordingly when the inital
problems appeared. It didnt have to go that far. Its a work place
afer all, not a private hotel room. Admitedly, this is one of the
most surreal work-related situatons I have experienced. Truth is
stranger than fcton.
79
F
R
E
E

E
X
C
E
R
P
T
Chapt er 5: Or gani zi ng Teams
of excellence that a collocated team can. Ideally one team is located
together in open space which is equipped with several whiteboards,
flipcharts and proper tables suitable for working in pairs and fluent
communication. No cubicles or anything alike that create barriers
for communication are allowed. Team should have a projector and
a screen available in the room so that it is totally effortless to show
something from one computer to everyone for instance in code
reviews, demo preparation, user story estimation and so on. It is
more efficient to have all team related meetings in the team room
instead of having to organize meetings in separate meeting rooms.
Conference phone is handy when there is need for whole team
to discuss with stakeholders or at least possibility to have good
quality conference calls over the Internet emphasis on the word
quality. Nowadays you can get good quality speaker phones for an
affordable price.
Room also needs one bigger display for constantly displaying
valuable information such as production data, company
impediments and defects, statuses of environments and builds,
and whatever data team needs to be aware of. Its handy to have
a webcam on the roof at each team room so that teams can check
which team members are present at another office when they want
to have a quick conference call with another team. Its important to
see each other during conference calls. Of course this requires that
people are not paranoid and afraid of the Big Brother trying to get
them when seeing a camera on the roof.
People outside the team can sit in the same room as long as they
dont in any way disrupt the teams work. Noise is non-disruptive
only when it directly relates to either your personal work or your
teams work. ScrumMaster sits together with the team to make sure
team is totally shielded from disruption and to fully comprehend the
teams daily work. When ScrumMaster handles multiple teams the
person sits together with the more problematic and of course you
can and should move around. Product Owner doesnt sit together
with the team since the person has to continuously interact with
stakeholders, which can be quite an annoyance to the team.
Collaboratve Designing
White boards are especially handy for sketching quick designs
within a group. When you want to save those just take a picture
and upload it to teams Wiki space (you could even automate the
94
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
business area maybe not very likely.
Celebrate small victories and make the progress visible. Never
tell teams how to do their job. Instead tell only the end result and
let them figure out the details and get out of the way. Embrace
misfortune as a learning opportunity. Make the importance of
uninteresting projects visible. How much a dull refactoring project
actually eases the end users suffering or generates profit? Even
a dull project needs a purpose. One of the most effective ways of
motivating a team is peer-responsibility. People care much more
about letting down a fellow colleague or the team than about any
company goal. It always feels bad to let down your teammates even
if you dont give a damn about the project or the company.
Incentives dont really work in creative work and they have a
tendency to backfire. Offering a lump of cash to dig ditches faster
probably gives a boost to productivity and gets the job done faster.
But in creative and cognitive work it actually limits the possibilities
for faster completion. Coming up with creative solutions is tough
when you are pushed into it.
Dealing with Negatvity
Especially in Finland people love to complain just for the sake of
it so much that it is almost like a religion. If you trust the popular
belief then Finland has to be one of the worst places to live and being
a Finn is something to be ashamed off. Weather is awful as is the
food and culture, and all Finns have well-deserved low self-esteem.
Foreigners are truly out of their minds for wanting to work or live
in Finland. Anything negative is blown out of proportion whereas
positive is belittled. It is like the complete opposite of nations which
praise their nationality. Life sucks and then you die, boohoo! In the
working world we Finns love to moan how other departments suck,
company priorities are all wrong and the management has no clue
of real work. Blame is always on others while you are just simply as
beautiful and perfect as it gets. Things are always screwed up but
nobody ever bothers to actually do anything about improving the
situation.
This cynical, pessimistic approach does seem quite amusing but it
can have drastically damaging effect on team morale. Worst of all it
spreads like a plague and even if it isnt even based on facts as much
as on mood swings people tend to buy it. Dont let your project
95
F
R
E
E

E
X
C
E
R
P
T
Chapt er 6: Gr owi ng Teams
I HATE OUR PRODUCT!
Some years ago a team that I belonged to was responsible
for building a back ofce applicaton. This applicaton was
full of legacy code and during the years it had become
extremely complex. All of us were very frustrated with the
product as developing new features was quite slow and
refactoring was huge amount of work as the code base
was heavy and fragile.
During one of our team discussions one member boldly
confessed, I dont like our projects and I hate our product,
because its so boring and overly complicated. He then
contnued, But I like learning new things, implementng
them in practce and I really enjoy seeing how much the
users actually get a kick out of each release. We make the
product more user-friendly bit by bit and their daily work
gets easier. Nothing wrong with saying that. Honesty is
good even in its brutal form. This was a bold statement
that visualised the elephant on the room. When that was
out in the open all of us actually agreed and each member
told his own personal motvaton to contnue: What does
each one of us get from the work?
In a way it really opened our eyes and gave a purpose for
the work that we considered as unpleasant. It was relieving
to know that everyone else on the team considered the
product unpleasant as well. In the end even though none
of us liked our product we were very motvated in building
it beter.
96
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
morale go down to the gutter just because of a few rotten apples.
People get motivated when they feel they can influence on
the way things are done. Always welcome criticism and focus
on transparency, openness and making giving information a
continuous flow. Let people question the project and priorities.
Never shoot down any discussion even if its tone is negative, instead
focus on making people give productive feedback. Provide multiple
ways to contribute and affect things. It is acceptable to criticize and
complain but you are expected to give concrete action points how
to make things better. Even if criticism is factual basis its pointless
to whine if you are not doing anything about it. Either shut up or do
something about it!
It is very irritating to do useless work for example finding out
that features you just built are wrong because a key person
didnt give input early enough or a business decision was made
but not informed. This is devastating for motivation if not dealt
accordingly. If this happens encourage people to take it as a chance
to improve. Be open about making mistakes and never come up
with any excuses. Transparency and open information comes first
especially in misfortune. Hiding problems and disputing mistakes
is unfortunately common and shows lack of maturity. Making
mistakes is not embarrassing but hiding or denying them is. Take
responsibility, own the problems and understand the world doesnt
end here. Inform everyone that this has happened but corrective
actions are going to be made such as involving appropriate
participants earlier or letting the management know that decisions
which affect teams are needed to know immediately.
When you handle things in such a professional manner mistakes
like these will on the contrary contribute to building up motivation
and maturity of the teams. Consider it as a valuable opportunity to
strengthen teamwork.
Own your problems and discuss about mistakes openly.
Ask What Motvates People
If you solely rely on motivating people with carrot-and-stick then
how can you know the carrot you offer is good enough for people?
Is your carrot really attractive enough to motivate? If people dont
give a damn about your carrot then you are even better off without
97
F
R
E
E

E
X
C
E
R
P
T
Chapt er 6: Gr owi ng Teams
it and threatening people with a stick is just ridiculous. A lot of
times in the corporate world projects and products just arent very
fun and you cannot expect employees to live and breathe, and give
their lives for those. So how can you get people engaged and active
when the project itself isnt interesting?
Its better approach to go straight towards the fire and ask people
what matters to them and discuss motivation openly instead of
guessing. With one team we quite often discussed together that
what do we get out of working with our projects. Whats in it for us?
What does every member of the team get out of the work? Business
value might be good for the company but what do we personally
gain? Even if it felt like the project was quite unpleasant everyone
always felt better after the discussion and sharing with others why
should we bother with it (besides the obvious reason that its our
job and we get paid for it). Usually we decided to just get the job
done so we can move on to more fun stuff.
Its sometimes good to think things clearly from a selfish perspective
because it sets your priorities straight. Dont do anything simply
because supposedly you have to. Only thing you have to do is to pay
taxes and eventually die, but even taxes can be avoided with a good
enough lawyer. In reality very little things in this life you actually
under all circumstances have to do, really. On the other hand its
also worthwhile to consider what is there to loose? What is there to
loose in helping others?
Christopher Avery in Teamwork is an Individual Skill
2
talks about
The Responsibility Process. Responsibility by his standard means
owning your ability and power to create, choose and attract.
Different phases before owning the responsibility might include
laying blame or justifying and having shame or obligation. If
you choose not to own it then quit during any of these phases or
ignore the issue and live in denial. Mastering responsibility in daily
practice includes intention, awareness and confrontation. Intend
to act responsibly when things go wrong. Catch yourself at any of
these different mental states and confront yourself how to learn,
correct and improve.
Whats in it for you?
2 [Avery, C. M., Walker, M. A., & OToole, E. (2001). Teamwork Is an Individual
Skill: Getting Your Work Done When Sharing Responsibility. Berrett-Koehler
Publishers]
MANAGE
DAY-TO-DAY
WORK
Daily collaboration, focus
and commitment to goals
115
F
R
E
E

E
X
C
E
R
P
T
CHAPTER 7:
Scrum in Action
Having lab days where team can work whole day on whatever they
feel like (as long as its not related to any sprint or user story) is a
very useful practice. Team members can for example look into new
technologies and the next day each member presents to the team
what they got out of the day. A lot of creative ideas can burst out of
those days. Additionally it substantially increases work satisfaction
when employees have freedom and flexibility to spend part of
working time for personal development.
On the other hand sustaining a continuous sprint schedule (or flow
if you will) is more evident for success. It is unfortunately usual
that during dedicated lab days the team actually ends up spending
their day-off for support duties and tasks that should be visible
in a sprint and thats definitely not the purpose. If you have lab
days then be absolutely certain that team has no other obligations
whatsoever. Otherwise you are simply a shmuck for claiming
typical work time as teams free time. When sprint schedules
are synchronized you can dedicate a day for this from all teams
to make sure there are no overlaps. Its at least worth trying out
once in a while with different agendas to see what is the outcome.
Come up with creative agendas for teams to use their lab day and
improve work life in all levels. At bare minimum leave slack inside
the sprints for chances to personal development.
Teach Teams to Pull
Build the confidence into the team to pull for work instead of getting
pushed. Goal is to find the capacity what team is able deliver in a
sprint and then utilize it into perfect balance between user stories,
support duties and personal development time. Product Owner has
to be cautious about pushing for stories. An inexperienced team
might always accept what is asked from them and yet in the end
accomplish very little of it. Then next sprint you do it all over again
and you can forget about predictability.
This is usually what happens with a demanding Product Owner if
the ScrumMaster isnt on guard. You also consciously need to avoid
116
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
telling the team how to complete the stories what is surprisingly
challenging for some people. Product Owner cares only about
the end result, not about details or the way the team decides to
implement the solution.
Try to fnd the perfect balance between user stories, support
dutes and personal development.
Building the Backlog
After the product and ownership is defined you can start building
the product backlog and figuring out a release road map with goals
what to achieve from each release. Come up with a feature list for
each release. Epics and user themes define the vision whereas user
stories are specific features or functionalities. User story can be
anything from one tiny feature to investigation how that feature is
implemented (spike). Several user stories are delivered during one
sprint. Nevertheless user story is only the start of discussion and
never a replacement for good ol communication. Thats why it is so
important that the Product Owner is always available when needed
by the team.
Product backlog is the spine where everything is built upon. It is
the centre of the Scrum universe. If your backlog doesnt represent
value (either wrong priorities or useless features) then everything
else surrounding is waste and you are simply thrashing. If you are
not building the right things at the right time in the right order then
it makes no difference whatsoever how super hyper productive
the teams are. Thats why you need to put maximum effort on
transforming value into a concise backlog. Identify minimum
marketable features, the smallest possible set of features that bring
business value and start writing user stories from there.
What often seems to be lacking in companies is the support for
Product Owners. They receive no training and support for their
work and have little co-operation between each other. It seems
like they are working just by themselves on their own little islands.
At worst they might even be competing against each other. This is
extremely bad situation, because there is no standardization for the
workflow and there might exist great deal of variety for example in
the quality of the user stories. In that case its very difficult to divide
the work between multiple teams in case of critical situations in the
project. The most essential part in the whole process is learning to
117
F
R
E
E

E
X
C
E
R
P
T
Chapt er 7: Scr um i n Act i on
write good user stories. It is not for the team to decide what they
work on. Product Owner has to be able to prioritize features from
the business perspective, write them into an easily understandable
manner and then be there to support the team in building it.
Put maximum efort on standardized company Product
Owner training in identfying value and learning to write clear,
independent user stories that represent maximum business
value with minimum efort.
Keeping the Backlog in Shape
Product backlog is divided into three categories. The first category
is a general backlog that contains epics or themes what the team is
going to work on at least for the next quarter of a year, preferably
half a year. You need a vision where the team and product is heading
to even if priorities keep changing. Vision is a necessity but not
a detailed plan and thats why you dont make the first category
too detailed. You need flexibility when priorities change (its only
a matter of time). If you make detailed plans for these and they get
dropped then you have accumulated waste. You can always add
items that are only on an idea-level basis to this category and start
fine-tuning from there. Think of it as the first initial starting point.
Second category includes user stories. These are not estimated,
but they are split down to reasonably sized, workable chunks.
Multiple user stories should fit into one sprint. For these stories the
Product Owner has to find out the requirements from stakeholders,
estimate business value and define acceptance criteria. When all
that is done, stories are presented to the team for estimation.
Category three includes ready, estimated user stories for the next
couple of sprints. Only stories from the third category are taken
into sprint planning, ever!
Maintaining this setup of backlog might seem a handful at first
glance. If youre starting from scratch then build the backlog in
small steps. In order to achieve it with as little effort as possible
hold at least weekly estimation sessions where the Product Owner
presents user stories and the team estimates how much work it
is. This session does not include any task breakdown whatsoever
and should not take more than an hour. It is an opportunity for
the Product Owner and the team to discuss future user stories
130
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
mean? What is the expected deliverable? Therefore visualise sprint
and project goals to make sure there is no room for misassumptions.
In sprint planning team commits to the sprint goal which means
they give their word to do their very best on completing all the work.
Not just completing with questionable quality but with quality as
defined by the agreed Definition of Done and therefore ready to be
deployed to production. It is not the end of the world if the goal is
not met, but the team should feel disappointment and eagerness to
prove to the rest of the world that they can and will do better.
When you run into problems instead of postponing the demo
session and prolonging the sprint keep the demo session. Present
user stories that have been completed and give a status report of
the unfinished work. Then move the uncompleted user stories back
to the backlog and take this as a learning experience. Always focus
on keeping the promised dates. Dont teach teams the treacherous
belief that if everything isnt done on time you can always get away
with it just by simply postponing the deadline (sprint demo). It is a
lot more useful to teach teams that almost 99,9% done means NOT
DONE and it is not acceptable to slide away from deadlines. In these
situations you descope but keep the deadline.
Almost completed feature is worth nothing. Sounds too harsh? Well,
who the hell would want almost working software?? Imagine if you
are making an online order and after just given your credit card
details the website crashes. In such a situation does your sympathy
really go for the team responsible building it that maybe they just
had a tough sprint? Are such dysfunctional features really worth
something?
The only acceptable reason for postponing a sprint demo is in
case of unexpected catastrophe such as the network is down and
all environments unusable, building is on fire or a natural disaster
took place. Other than that there are no good excuses. Terminating
the sprint and demo comes in place when priorities have changed
for example user stories no longer present business value or
production issues are eating all resources (fire-fighting) and it is
no longer feasible to meet the sprint goal. In that case you organize
a new sprint planning session whenever possible: whenever the
fire has been put out and focus on preventing such fires ever from
happening again.
In company sprint planning all teams state whether they can commit
131
F
R
E
E

E
X
C
E
R
P
T
or not to the content. By committing the teams promise to do their
best to complete all the work. Everyone doesnt have to agree it is
the ideal choice but everyone has to agree it is the suitable choice
at the time. Dont get too fixated on a perfect solution but the most
suitable solution at the time.
Only commit to your part. Dont commit to guaranteeing the work of
outsiders. If you are dependent on a third party provider or vendor
then notify them about your deadline and do everything in your
power to make them meet that deadline. But you shouldnt promise
to meet any deadline if its not in your hands. In that case make
sure your stakeholders understand it is not in your hands already
in planning. It is not acceptable for teams to blame others for not
meeting a deadline. That risk should have been acknowledged
already in the planning, before committing.
Do NOT postpone demo sessions. In problematc situatons
keep the date, but descope content. Never slide away from
deadlines!
Scrum Wall
The most important tool for the team is the Scrum Wall where
members gather around for the Daily Scrum every morning. Having
a Scrum Wall is not only important for the team but also very useful
for outsiders, because it visualises all the work in prioritized order
showing the progress and possible impediments. Therefore Scrum
Wall should always be a physical board because it makes organizing
the work a lot more effortless without the limitations of any tool.
Its not dependent on network or electricity plus its more in your
face and leaves less room for misuse and misinterpretation. Virtual
Scrum Wall is a nice asset and easy way to display the work over
network to other offices, but it is always only a secondary accessory
if team is collocated. If team is dispersed on multiple locations then
you have to resort to the virtual world.
User stories are on the top of the Wall and prioritization goes from
left to right where the one on the far left is first priority. Under the
stories are the tasks on post-it notes. Each story has a different
colour of post-its for clarification. Theres a magnet map located on
the top left. Everyone has a bunch of magnets that identify who is
132
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
T
i
m
e
l
i
n
e

f
r
o
m

f
i
r
s
t

s
p
r
i
n
t

d
a
y

t
i
l
l

t
h
e

d
e
m
o

T
e
a
m

m
e
m
b
e
r
s

m
a
g
n
e
t

(
e
v
e
r
y
o
n
e

h
a
s

t
h
e
i
r

o
w
n

b
u
n
c
h
)

T
a
s
k

A
m
o
u
n
t

o
f

d
a
y
s

t
a
s
k

w
a
s

i
n

p
r
o
g
r
e
s
s

U
s
e
r

s
t
o
r
y

A
m
o
u
n
t

o
f

d
a
y
s

u
s
e
r

s
t
o
r
y

w
a
s

i
n

p
r
o
g
r
e
s
s

T
e
a
m
s

m
a
g
n
e
t

m
a
p

(
d
i
f
f
e
r
e
n
t

c
o
l
o
r
s

&

s
h
a
p
e
s
)

I
m
p
e
d
i
m
e
n
t
s

a
r
e

a
d
d
e
d

t
o

t
h
e

w
a
l
l

a
s

w
e
l
l

A
c
t
u
a
l

h
o
u
r
s

s
p
e
n
t

f
o
r

t
h
i
s

u
s
e
r

s
t
o
r
y

133
F
R
E
E

E
X
C
E
R
P
T
working on which task. They are like personal avatars. Below is the
timeline displaying all dates before the demo. Timeline is important
because it constantly reminds you how many days you got before
the demo. Its so easy to vanish on the belief that there will be time
later on. There is an area on the far right of the Wall for operational
tasks that pop up during the sprint and not part of any story.
Before the sprint starts all post-its are on the top below the stories.
As task is started it is taken down to the current date along with
the team members magnet to clarify it is in progress. If it is not
done the next day a green line is drawn below for every day it is
in progress. This way you have to move post-its only once and just
tape them if they dont stick. Remaining hours are marked every
day to the bottom right corner of the post-it with a pencil and actual
hours are added to the top left with a marker. All tasks that dont
have a magnet in the timeline area and have the actual hours are
considered done. If you cant use magnets for any reason then come
up with some other way to visualise which member is working on
which task. It might not make sense for a small team but it definitely
makes a difference if team has nine or even more members.
Impediments are also added to the whiteboard with a red marker,
so that it is clearly visible which tasks have been impeded and for
how long. If task is impeded and depending on someone outside
the team then you draw a red line. You can write other important
information to the Wall as well such as marking specific dates
(e.g. Feature Freeze), release schedule and so on. These are just
the minimum recommendations. Its also a good practice to print
a calendar at each month and fill it with sprint schedules, out-of-
office dates and so on. Make it easy for team members to visualise
data that is important for everyone to be aware of. It is the duty of
the ScrumMaster to make sure that the Scrum Wall is tidy and it is
crystal clear what is the status of each story and task (not started,
in progress, impeded, dropped or done).
Everyone should always have a task in progress. If not then pick
up one, create a new task or pair up with someone. Just by looking
at the Wall you get a quick glance of the whole sprint and see how
the sprint is progressing. Stories are completed in prioritized
order. Ideally team should work on stories one by one but specially
for large teams it might not be very efficient that everyone is
working on the same story. Use common sense. Nevertheless
focus is on completing current work before starting new. If it
134
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
becomes a problem and your sprints often end with half the stories
incomplete then come up with a Work in Progress (WIP) limit.
Make constraints that enforce team members to work together; for
example only some amount of stories can be worked concurrently.
The Product Owner and ScrumMaster do not put any tasks on the
Wall nor should they complete any tasks for the team. Scrum Wall
shows solely the teams work.
A thing that makes the use of Scrum Wall so efficient way to work
is the social pressure that comes along with it. Team members are
obliged to report to each other daily and visualise their progress.
It might feel a little intimidating for beginners at first, but no team
will object to its use when they understand the drastic increase of
visibility and boosted productivity. It is not acceptable to say you
are working on some tasks outside the Scrum Wall. Everything has
to be visible on the board.
This type of Scrum Wall works as an excellent information radiator
for retrospectives as well because it holds so much information.
You can see if team had impediments and for how long those
lasted, how long each task was in progress and which days were
more productive than others. How many hours was each task
estimated and how long it actually took. It is so easy to come up
with improvement suggestions when you have this in front of you
every day.
Make sure all work the team is doing is visible on the board.
Operatonal Tasks
During a sprint the team can do tasks outside the sprint scope
but those should be tracked to see what is beneficial and is there
any waste. Operational tasks are tasks done during the sprint
but not part of any user story. Since at the gaming organization
the finance department wanted to track hours based on projects,
we decided to divide operational tasks into support (for other
projects), unplanned (project related) and waste (unrelated to any
project). Support includes production issues (task force duties),
maintenance, bug fixing and support for other teams. Unplanned
includes operational and build master tasks such as maintaining
automated tests or builds. Waste is work unrelated to any project
such as installing local development environment.
135
F
R
E
E

E
X
C
E
R
P
T
It might seem harsh to label some part of the daily work as waste
but it doesnt really matter what you call it. If waste sounds too
scary then call it as bananas. Point is that you keep track of what
the team spends its time on and consider what work is valuable and
what is not. How much time are you wasting when the network is
down? Eliminate waste and come up with methods for prevention.
If in every sprint you waste one day fixing same kind of issue then
how could you prevent it from happening again? Its really good
practice for the team to identify what tasks are they doing outside
the sprint scope. But if a task takes less than an hour its probably
not worth writing down.
Prevent waste.
Burndown Charts
The core reason for having burndown charts is to visualise the need
for action. If things were going perfectly and always as expected
then of course you wouldnt need any charts. You wouldnt need to
track anything if everything went as planned. Visualising progress
allows you to react in matter of days instead of weeks.
Its far too easy for the team to get caught up in the moment thinking
Hey, we know our status, if anyone else wants to know they can
just come ask us. Sounds pretty good from the teams point of view
but for outsiders wanting to check out the status of lets say 15
teams it is a sheer nightmare. On the other hand if you never react
to anything the team does between the demos then you dont need
any charts. More likely you need another job instead.
Burndown charts show the progress of the sprint. There are two
types of burndown charts for every sprint: one for tasks and the
other one for user stories. Tasks hour burndown chart is the
estimation of how many hours it will take to complete the sprint
(remaining task hours) and hours are subtracted daily. Task hours
include operational tasks. Story points are subtracted only when
a whole user story is done. The story points burndown is actually
more useful because you can still be left with nothing completed
even if the task hours are going down. Looking only at the tasks
burndown can be quite deceiving because in the end you might
have hours close to zero but still none of the stories are done.
Even if you decide not to have physical burndown charts make sure
136
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
BUT IT MAKES ME LOOK BAD!
It is decisive to visualise the amount of days tasks are in
progress. If you dont have the space for drawing a tme
line for each day of the sprint then come up with another
way for instance mark a spot on the post-it each day the
task is in progress. Usually people are surprised how many
days they actually spend with a single task because ofen
tme just seems to fy by.
With one team I had quite an amusing episode related
to this. One of the members was multtasking against my
recommendatons and he constantly wanted to work on
four tasks at the same tme. As a ScrumMaster I let him
have his way without preaching too much to see if maybe
he was a wonder multtasker and if it worked out. Maybe
he was a genius and I was the idiot for trying to inhibit
him.
Afer a few days passed by he completed some of the
tasks, but one task had been in progress for already
fve days and the green line just grew longer and longer
each day. Eventually he wanted to move the task to the
current date and wipe the green line away, but as I didnt
let him do that he replied but it makes me look bad.
That is exactly the point! It defnitely should make a team
member look bad if he or she is constantly startng new
tasks before fnishing current one and doesnt manage to
get anything done. If a task is prolonging for several days
then it is a clear sign that something is wrong and should
be addressed. Maybe the team member is struggling with
the task and needs help. In any case when you visualise
the days this is clearly visible even for outsiders. By doing
this you encourage the team to focus on completon of
tasks.
Multtasking at its core is bad for productvity because
it disrupts the focus. It is something to look out for
and constantly be reminded to the team. Only tme
multtasking is allowed is when the tasks are clearly
related but even then it is just plain ridiculous to have four
137
F
R
E
E

E
X
C
E
R
P
T
tasks simultaneously in progress. Ask the person if it really
is efcient way to work and benefcial for the sprint.
If someone started and spent tme with a task then they
are not allowed to put it back to not-started state. It is
in progress untl it gets done. If the task becomes invalid
then just leave it on the Wall, mark it as done and give
the actual spent hours. Dont take any started tasks away
because you need to visualise where did the sprint tme
go even if it was waste. This is excellent data for the
retrospectve. You can come up with a maximum length
for a task if it becomes a problem. Team is free to add
new tasks and remove only not-started tasks from the
Wall during the sprint to refne the plan.
144
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
tempt the team claiming something incomplete as done.
Usual reason for failed sprints:
User stories and goal are poor
Too much work done outside the sprint
Lack of shared focus
Usual reasons for stories remaining incomplete are under
estimation of the work, impediments, dependencies, unclarity and
unexpected absences such as sick leaves. Does it mean that you are
automatically a failure because you didnt account for those in the
planning? Of course not. That is why sprint needs a goal to define
whether it was a success or not. Otherwise the point of sprint
remains merely in completing some stories. On the other side is
a sprint success if goal is met but no stories are completed? Well,
basically yes but the planning was quite rotten then.
Even if team hasnt managed to complete a single story the sprint
demo is still held. Naturally no stories are demoed since nothing
is done but the team gives an explanation why nothing has been
completed. It is the team members who give the explanation to
the Product Owner and stakeholders, not solely the ScrumMaster.
Always give credit whether its negative or positive to those who
do the actual work. That means the team, not the ScrumMaster or
Product Owner who are there only to help. It is the team who does
all the work and deserves all credit. ScrumMaster at all situations
must be unbiased and objective, state the facts without making up
excuses. Dont let anyone badmouth the team but never take the
blame for the team either. If you take all blame when things go
bad then you teach the team nothing about accountability of their
actions. A good leader takes a little more than his share of the blame
and a little less than his share of the credit.
Actually, failing is a great opportunity for the team to collectively
take responsibility for their actions and grow maturity level. Look
on the bright side. Failure is often much more educative experience
than success. It is not an event where you chew down the team to
pieces for not delivering but more like a session where they have a
chance to explain why they didnt meet the deadline and what is still
missing. Chances are that it wasnt only a case of over committing.
Is there something disrupting teamwork? Is there something going
on that managers should be aware of? It takes a lot more courage
to admit that features are not done yet than trying to cover up and
145
F
R
E
E

E
X
C
E
R
P
T
finishing work with low quality.
Product Owner then answers whether same stories will be re-
planned and what will be improved and done to avoid the same
thing from happening again. Making mistakes is acceptable but
making the same mistake over and over again is not. It is more like
the definition of insanity.
Sprint demo is the place for teams to shine (or rot).
Constant Improvement through
Retrospectves
Regardless of what we discover, we understand and truly believe
that everyone did the best job they could, given what they knew at
the time, their skills and abilities, the resources available, and the
situation at hand.
-Norman Kerth
Retrospectives are the single most important element in the whole
process because it all comes down to the essence of Scrum: constant
improvement; inspect and adapt. Whole team together with
the ScrumMaster and Product Owner look back on the previous
iteration and decide what to improve during the next one. Yet it
always seems only a matter of time before people start criticizing
the need for retrospectives. Well, if everything is going just dandy
and there is no longer room for improvement then maybe its factual,
but how many teams can say that? The retrospective doesnt serve
its purpose only to reflect on the problems but also to realize what
has been achieved. So, ignore the nagging and insist that teams
have them after every single sprint even if its only on a lightweight
basis. It is better to have a brief 15-minute casual discussion than
not having one at all. Make it a habit. Its like a ritual for closing the
sprint.
Common reasons for people to hesitate having retrospectives are
that action points are not followed, overall mood is negative and
blameful, sessions are held just for the sake of it without any relation
to daily work (e.g. issues like My vacation was good) and of course
the evident fact that engineers just dont like talking about feelings.
Be prepared for resistance and constantly improve the session in
the manner that team feels comfortable with. Retrospective event as
146
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
any meeting can become tiresome if not developed. It is a challenge
to keep the session fresh. A book by Esther Derby and Diana Larsen,
Agile Retrospectives: Making Good Teams Great
5
dives into getting
most out of retrospectives. There are cabillions of different ways
of conducting this meeting and it definitely should be varied. Try
something different every once in a while. Try a different approach.
Review the retrospective meeting to make sure that the team is
satisfied and gets most out of it. It is not the teams fault if these
events become boring. After all, if the ScrumMaster is boring then
of course its going to be a boring meeting.
If you have two week sprints then retrospectives should be very
lightweight as they take place every other week. You can have
more thorough retrospective maybe once a month. Nobody likes
unnecessarily long meetings, not to mention unnecessary meetings
what some people without a deeper insight might consider
retrospectives to be. Spending a whole day to dwell into everyones
deepest, darkest thoughts will be a great challenge for engineers.
It is better to keep it lightweight and continuous. The main point
of retrospectives is to get the team to communicate together and
express their concerns, building trust so that team is comfortable
in questioning each other and coming up with ways to improve
the work. One person doesnt speak for the whole team and
nobodys thoughts are rolled. From Product Owners point of view
retrospectives can be a chance for recognizing, eliminating and
preventing waste in the teams daily work.
Retrospectives always end up with concrete action points to be
taken into the next sprint. When coming up with action points it is
useful to have a focus point: what can be done concerning the team
itself, what can be done to help other teams and what actions or
insights should be proposed to the management. The main focus
area is where you have an influence on. It is absolutely of no use
in stressing about something you dont have an influence on for
example development teams most likely dont have a lot of influence
on company business decisions. It is useless to stress about things
you cannot affect. Making your opinion heard is pretty much all you
can do.
Action points are only taken for people within the team, not
for outsiders. Chosen action points are gone through in the next
5 [Derby E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great.
Pragmatic Bookshelf]
147
F
R
E
E

E
X
C
E
R
P
T
meeting. If there are long-term action points, then write those on a
white board as well just to keep those in mind.
No matter which way the session is held the manner has to be
positive. One thing to look out for is retrospective sessions becoming
nagging or slandering chats. Always keep it in a positive manner
and focus on what was good, what was not that good and what
can be improved. Dwelling in negativity or going around saying
how everything sucks is not productive and eventually will make
everyone feel demotivated. Either stop whining or do something
about it. Its also a good idea to get out of the workplace every once
in a while and hold the retrospective at a joint lunch.
A really effective way of getting input from all team members
and ensuring they take lifts from their chests is to split into pairs
(or a group of threes) and have people interviewing each other.
ScrumMaster and Product Owner also take part. Every person
says what was good, not-so-good either in their own actions or
in the sprint in general, and suggest individual action points for
themselves what to improve during the next sprint. Everyone
considers how can they with their individual contribution make
the team better. After everyone is done every pair presents their
results. Interviewer stands up and goes through the notes and
afterwards the interviewee has a chance to add something if he or
she wishes. Areas where the team should dwell into include good
things, not-so-good things, what did the team learn, what should be
changed, is there something puzzling and so on.
The ScrumMaster facilitates the session and every team member as
well as the Product Owner should be present. Everyone has to give
input including the Product Owner. The ScrumMaster should not
raise issues in order not to seem bias. Retrospective is also the time
to hold the Product Owner accountable for the quality of his or her
work. Is sprint length respected or is new work trying to be added
after planning? Are the user stories good enough?
Invite outside people who have input and need to be aware of the
teams concerns. That might include other teams members and
stakeholders. Its really good for the teams supervisor to be part of
these sessions sometimes. But that requires that team is confident
enough and have courage to speak up even in outsiders presence.
After the session the ScrumMaster writes the action points on the
155
F
R
E
E

E
X
C
E
R
P
T
CHAPTER 8:
Software Craftsmanship
Risk-Based Testng
Point of testing is not to find defects but to prevent them. It is next to
impossible to test everything under all possible scenarios with all
possible parameters therefore testing is focused on what matters
most and where the risk of failure is severe for instance monetary
transactions. This is why testing has a lot to do with analysing
risks and likelihoods for failure. Amount of test cases and even test
coverage tells you pretty much nothing about the quality of the
product. Its the quality of the tests that matters. Are you testing
the right things? If not then you are just wasting effort.
Testing starts the same day as development, not at the end of
the sprint after implementation is done. Otherwise you are just
having mini waterfall process inside the sprints: first design, then
implementation and finally quality verification. This is not efficient.
Its very risky if testing is left until the last minute. Chances are that
you discover defects which you dont have time to fix before the
demo and you are only left with untested, incomplete user stories.
As the business value of incomplete work is zero then your whole
sprint doesnt manage to deliver any value.
You need to constantly analyse risks. Not after something is done but
before even starting the work. To make it a systematic process the
team analyses the risks for each user story before implementation
and starts working on test scenarios from there. When FMEA is done
before implementation it creates an excellent basis for building the
functionalities and pinpointing testing to the right areas. Which are
the parts that in failure have highest severity? In order to prioritise
and visualise the risks you need to give a value for each risk. For
every software function a failure mode is detected and severity
number is given on the scale between 1 to 10, where 1 equals no
danger and 10 equals critical. Same ranking is given for occurrence
and detection as well. Next you can count the risk priority number
by multiplying these three numbers (RPN = S x O x D). This way
you identify the greatest concerns, and highest RPN values have the
first priority for corrective actions. Doing these four steps for every
user story might seem quite burdensome therefore you can start
with a lightweight basis just as long as you do it. 15 minutes per
156
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
BLAME IT ALL ON THE TESTER
My frst real sofware job was to be a test automaton
engineer in a senior J2EE development team. This was
not an agile team and the working practces were far from
disciplined and systematc.
The frst thing was to start working on a project that was
already a year late. There was tremendous hurry and
pressure from the management to complete the project.
Only instructons I got from our project manager was
to test everything and it was solely up to me alone to
decide which parts of our products are critcal to test.
Worst part was that I had no clue about the end user
behaviour of our products and neither did the developers.
If you asked what is some feature used for a lot of tmes
you got just silence. When the situaton is like this testng
is a sheer nightmare. Work is full of uncertaintes but the
tme schedule is so tght that you are not given any tme
to uncover those uncertaintes. There is a big chance of
wastng tme on putng a lot of efort on testng parts
with litle value for the end user.
One tme I got back from vacaton there had been a
critcal producton issue in a product we maintained. I
got my fair share of blame from my boss and developers
that Im not doing good enough job in verifying the
quality of our products. Testng was solely on me and I
was like an outsider even though I was a team member.
Quite amusingly when at one tme developers had a get-
together one developer aferwards commented that I
wasnt invited as Im not a real coder. Even though it was
partly sarcasm it clearly showed the general atmosphere
that as a tester Im not as much part of the team as the
developers are but more like a second-rate citzen.
In a team no member can be an outsider and there is no
hierarchy within the team. Whole team is responsible for
testng and assuring the quality of their work. If these kind
of issues emerge in your teams then you have to put them
straight.
157
F
R
E
E

E
X
C
E
R
P
T
Chapt er 8: Sof t war e Cr af t smanshi p
user story coming up with potential risks is usually enough. After
all it is more important to consider the risks and prepare for them
than counting some numbers.
When it comes to agile testing a common puzzle is what to automate
and where do you need manual testing? Automation is never a
replacement for manual testing. Its an extension. You put the
manual effort where the use of human brains brings the most value
and automate repetitive, boring tests such as regression testing.
Humans are needed for exploratory testing and in scenarios that
are tricky to automate or maintenance is burdensome. Even if there
are extensive automated regression tests manual testing is still
needed. Manual testing is always needed. But use the manual work
force on issues hard to spot with automation.
It takes little effort to write idiotic tests that make no sense
whatsoever but it requires a bit more thinking to write long-lasting,
reusable tests. It demands input from the whole team. This can be
rather challenging but when done properly it will pay-off greatly.
Good tests are easily maintainable, trustworthy and readable.
They dont concentrate merely on happy day scenarios but also on
negative testing. Tests should be fast and easy to run. Even if you
have a large set of automated tests there should be a test suite of
acceptance tests that are fast to execute. Good automated tests are
environment independent, re-runnable and reusable.
Each team works in at least three different environments (the
teams private one, CI and RC) and testing is mainly done in the team
and RC environments. But since the acceptance criteria defines that
everything has to be working in the RC environment then that is the
environment what matters the most. There is no value in a feature
which works in some developers local environment but fails in
the RC environment. But features are already thoroughly tested
and verified before put to RC. This is the environment for release
candidates that are ready to put to production and mainly used for
verifying that none of the old features have broken.
Each team has a dedicated tester who has three duties:
Commitment for the team to verify quality in everything
that team delivers
Constant interaction with the Product Owner and
stakeholders to validate that the team delivers what is
expected
158
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
Commitment for the company releases and testing other
teams products
Team tester has to be in even tighter cooperation with the Product
Owner than the team, because he or she is responsible for making
sure in the daily work that the team focuses on the end user value
and considers risks. Before sprint starts the tester goes through
the acceptance criteria for each user story with the Product
Owner (or ideally with the customer) and gives input from the
teams perspective. Often developers are too attached in thinking
everything from overly technical perspective and thats where the
tester comes with a very unique role in the team.
Tester is closer to the end user. Whereas the Product Owner
concentrates on the value that the end user benefits the tester can
solely focus on the end user experience. When sprint starts the
tester writes functional manual tests and use case scenarios how
user stories can be tested. These use case scenarios also function as
part of the documentation therefore they have to be extra readable.
Next thing to do is to write automated acceptance tests for the user
stories. As functionalities are implemented the tester verifies those
functionalities with own tests and by going through the tests made
by developers.
Does tester need to be able to code? Testers are not required to be
coders since nowadays many test automation tools are easy to use
and require little or even no coding for instance you can record the
steps you perform in a website. So thats no excuse. You can easily
get started even without any prior coding experience. Coding is not
a prerequisite for testing and as with any skill competence can be
developed if there is will to learn and improve. More important is
to take in the end user perspective and thorough comprehension of
risk analysis methods. Drive the team into the direction where risk
management is part of their daily work.
Transition from a traditional Quality Assurance team member
to an agile team tester can be quite challenging. But it is also
very rewarding as the tester actually affects the product before
implementation even starts. First of all the tester is part of the
team instead of an outsider. This minimizes the harmful dividing
and handovers between developers and testers. Strangely enough
it is quite common that testers and the need for them both in teams
and companies in general is often greatly underestimated and
159
F
R
E
E

E
X
C
E
R
P
T
undervalued. Developers treat testers as second-rate citizens and it
is perfectly acceptable behaviour in companies. This is something
to look out for and emphasize that testing is responsibility of the
whole team, not just the tester. But the tester needs a proactive
approach to work hand in hand with the developers starting from
day one. Tester is the quality gatekeeper for all that team delivers
and it is not acceptable for a tester to say I didnt know this had to
be tested.
Testng starts the same day as development.
Coding Practces
Even if teamwork is good and features seem decent you need ways
to ascertain that the team is not taking any shortcuts that end up
costing valuable time in the future. Progress might seem great
while the team is at the same time perhaps unwittingly increasing
technical debt that will eventually paralyse improvements. Speed
requires good design. Extreme Programming (XP)
1
is a set of
engineering practices that are tightly integrated into Scrum. As
Robert C. Martin put it, Scrum is a day-by-day process whereas XP
is a minute-by-minute process that fills those days.
2
Scrum doesnt
take any stand on coding itself and the guidelines that form software
craftsmanship come from XP. Without these practices you leave too
much in the hands of chance and stand on an unstable ground.
First of all code is owned by the team, not individuals inside the
team. Any team member can touch any part of the teams code.
All written code is reviewed by the whole team or at least by one
peer. Code reviews are sessions where the whole team (not just
developers) sits down and the writer presents his or her work.
This doesnt concern only code. Documentation, designs and tests
are also reviewed together by the whole team. Have joint review
sessions for everything that makes sense to review together such as
graphics, new technology and so on, but the absolute minimum is
on a user story level. Story is not done before it is reviewed together.
Try also reviewing work across teams.
1 [Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-
Wesley Professional]
2 [Martin, R. C. (2010). What Killed Waterfall could Kill Agile]
160
If you find
this material
worthwhile,
please support
me and buy the
full e-book for
a special price
(before the
official release)!
Cheers,
Pair programming is a technique where two members work using
one workstation. One person does the typing (driver) while the
other one reviews (navigator) each line. Navigator comes up with
ways to improve and sets the strategic direction whereas the driver
can focus solely on the current task and use the navigator as a safety
net to keep focus on the big picture. Roles are switched frequently.
Even though it might seem a little contradictory but by doing this
you actually increase efficiency: software products can be produced
in less time, with higher quality.
3
Chances for defects decrease,
complexity minimizes, maintainability eases, creativity blossoms
not to mention it also emphasizes teamwork. Pair programming is
especially efficient practice in introducing new team members to
the codebase. This kind of intense pairing might not suit everyone
and pairing persons with drastically different skill levels might
cause some frustration. Its not pair programming if one person
is typing and the other person just sits there quietly without
contributing. Pairing includes active two-way communication.
Nevertheless at least try it out every once in a while and see what is
the outcome. For one sprint each team member pairs with another
one for a couple of hours a day.
It is definitely worthwhile to organize in-house coding dojos where
coders get together to work on some pre-agreed programming
challenges. Point is to have fun and improve skills together. Practice
makes perfect and practising together with peers intensifies the
level of learning.
No code lasts untouched for a lifetime. Adapting to change applies
specially harshly to coding. The code you write today might become
futile tomorrow. Its only a matter of time when it changes but it
definitely will change. Thats why you have to support constant
refactoring and make sure refactoring the codebase is as easy
as possible. All code is easy to change and changing one thing
doesnt break everything. There is no chain reaction and codebase
is not a house of cards. Otherwise you tremendously slow down
development time and fixing defects takes even longer. Automated
tests (at minimum this means unit, integration and acceptance
tests) is your safety net that allows you to quickly realize the affects
of those changes.
All code is not created equal. If you spend a lot of your time
3 [Williams, L., Kessler, R. R., Cunningham, W., & Jeffries, R. [2000]. Strengthening
the Case for Pair-Programming. IEEE Software. Volume 17, Issue 4]
161
F
R
E
E

E
X
C
E
R
P
T
perfecting code that has minimum effect on the functionality and
value regarding the end user then you are simply wasting your
effort. Do the bare minimum that works then stop and move on
to more important things. Just like with features different parts of
the code have different priorities. As long as it gets the job done
each line doesnt have to be perfect. Put maximum effort where
the value and payout is high. Code that has the severest risk in
failure deserves the highest attention. Having a defect or design
failure is much more damaging there than in some minor test
code. Therefore acknowledge the effects and value of your work
and concentrate on simplicity. It can be tough to keep everything
simple under complicated situations, each and everyone of us need
to be reminded about this from time to time. Some teams even have
posters with slogans (team rules, values and recommendations) on
their Scrum Walls as reminders and thats definitely something to
try out.
Test Driven Development is (TDD)
4
is a technique where developer
starts with a failing test and then produces the bare minimum
amount of code for the test to pass in order to provide the required
functionality. This way tests work as requirements specifications.
This is done to ensure testing the right things and writing as
little code as possible, because the more code you write the more
complexity you create and the probability of defects increase. As
a bottom line functionality of the tests are not changed. You are
only allowed to change tests in minor refactoring such as in order
to improve readability. Instead you always add new tests (unless
those become invalid) because otherwise it is too easy to loose
focus what the original idea was, not to mention this way it is easy
to trace steps back to the very first requirement. You only change or
remove tests if the requirements change.
TDD is hard work and it may take even years to fully interiorize
because it requires a totally different approach than most
developers are accustomed to. Instead of testing after you actually
test before coding. Encourage TDD but dont shove it down to
developers throats because it can backfire. Its a powerful tool but
with inexperienced programmers the outcome might not be good.
In worst cases you might even deteriorate your system architecture
if developers lack focus on the big picture. Its a challenge even for
experienced coders unless you constantly visualise the design. Draw
4 [Beck, K. (2002). Test Driven Development: By Example. Addison-Wesley
Professional]
167
F
R
E
E

E
X
C
E
R
P
T
CHAPTER 9:
Non-Development Teams
Working with software development team is a pretty straightforward
process when you have an unambiguous product. Find out what
features are needed, write those features into workable sized
user stories and then break those into a sprint plan together
with the team. After each sprint demo the completed features to
stakeholders and consider what you could do better to maximize
value in the next sprint. Repeat until you are done.
But what about when you are not building a product? How should
teams such as system administrators that only function serving
other teams plan their work? There is no point in having sprint
planning if you are not aware of the deliverables before-hand so that
you can actually plan work for the sprint. But even if you dont have
sprints you should have short cycles. What you can do is to measure
the capacity that the team can deliver during a given period (a week
or two). How many items can team complete in a week and how
long does it take for one item to be completed? Measure the cycle
time from sprout of an item to acceptance or deployment. Item can
be anything from a few hours task to a few days work. Plan when
there is something to plan for. If you have an item that takes weeks
then you definitely have something to plan for.
Apart from the planning, the same set of team practices apply also
for non-development teams. In all cases limit the work in progress
and visualise ongoing work. Get a taskboard for the team firstly to
organize their work and secondly give transparency for outsiders.
Team members synchronize their work daily. One team member
participates in the company Scrum of Scrums meeting to inform
other teams what the team is working with and ask if any team
needs any help.
Development teams are always obliged to inform immediately when
they are aware that they need support to avoid situations where
critical support is needed today for something that was already
known a month ago. Hold public demos to present the achievements
of the team at least once a month. After each cycle look back and

Scaling Excellence v0.1 FREE

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scaling Excellence v0.1 FREE

Uploaded by

Copyright:

Available Formats

SCALING

Follow-up & improve

Follow-up & improve

You might also like