I changed jobs a few months ago. I
moved from a company that was invested in the agile development
philosophy and scrum practices to a smaller company that was just
starting to build its development team from a team of one to a team
of five. Of the five, I am the only one with a significant amount of
experience working in a truly agile, highly successful, team-based
environment. We've been trying to transition to a similar type of
environment at my new job for a few months now with varying degrees
of success.
I thought I would share my observations
and experiences on the successes and challenges along the way. In
many cases, there are multiple layers to each success and challenge
that we've encountered. I will only hit on the highlights in this
post.
Successes
Building a definition of done that
promotes openness and collaboration
First off, let me say that our
definition of done is very fluid. We have an ideal definition of done
and we have our current definition of done: the ideal definition of
done is where we want to be; a definition that incorporates all of
those things that we'd like to adopt as our team continues to mature
and evolve; our current definition is where we are at today.
Our current definition of done includes
things such as story point estimation, task planning, implementation,
and various stages of testing and deployments. The part I want to
focus on here are the early stages. It is in the story point
estimation and task planning stages that lay the foundation for a
cohesive and high performing team.
Story point estimation
One of the first stages a story goes
through after it's been added to the backlog is story point
estimation. Our only prerequisite for pointing a story is for the
story to be clearly written with “good enough” acceptance
criteria. We usually try to get through a 6-8 stories during story
point estimations: not so many that we're sitting in a meeting room
for an hour, but enough for the product owner to be able to groom the
backlog.
We have adopted planning poker for our
estimation sessions; the choice for planning poker is key as it
promotes brief discussions that bring to light differing points of
view when there isn't consensus. These discussions are meant to be
very brief: the owner of the largest estimate explains why he/she
thinks the story deserves the higher point value; the owner of the
smallest estimate then explains his/her reasoning for the lower point
value. Taking each persons' explanation into consideration, the team
then re-estimates the story until arriving at a consensus. In those
cases where we've played a few rounds of planning poker on the same
story and still cannot reach consensus, we table the story and come
back to it later, so the estimation session doesn't grind to a halt;
this is usually an indicator that the story may need to be refined
further or the team needs to get more clarity on the story from the
product owner. In my experience, the situation where the team cannot
reach consensus is very rare.
At the end of the story point
estimation, the team has a pretty good idea what is being requested
and has had a few (quick) discussions that has everyone on the same
page and will help move the story into the task planning stage.
Task Planning
The task planning stage comes after a
story has a story point estimate associated with it. We usually try
to keep these planning sessions scoped to one story at a time to
avoid having too much work in progress at once. The task planning
stage requires the team to come together again to discuss the story;
this time at a much more granular level. The goal of this meeting is
to have a road map of the individual development/coding tasks and
test cases that need to be completed to meet the story's acceptance
criteria.
It is crucial to keep the task planning
meetings as concise as possible. Not only are you taking time away
from value-adding activities (i.e. coding and testing), but the
productivity of a task planning meeting is inversely proportional to
the length of the meeting: the longer the meeting goes, the more
fatigued/distracted people will become, so each team member taking
the time to review the story and do some initial preparation prior to
the meeting is crucial to get in and out of the task planning as
quickly as possible while still capturing the necessary artifacts.
In our case, task planning usually
starts with one person (not always the same person) discussing what
he/she found in their prep work. Ideally, this person would have a
good start on specific implementation items that need to be done in
order for the story to be completed. In our case, this usually works
best when discussed in conjunction with a simple whiteboard drawing
to illustrate how the different classes and/or components work
together. This initial whiteboard drawing helps to drive the rest of
the meeting: specific coding tasks result from the whiteboard; other
team members will usually have ideas and input to make the design
better get incorporated into the development tasks; and eventually
identifying the acceptance tests that will prove the story is
complete.
Besides having a set of granular,
clearly defined set of tasks and test cases that need to be done, the
task planning also results in the entire team having a walking around
knowledge of how a piece of functionality works. In the best cases,
the time spent to go through the formal task planning stage pays off
multiple times over; the actual coding and implementation becomes a
formality and is more of an assembly line process and usually goes
pretty quickly (especially when multiple team members can work on
tasks in parallel) since you don't have all of the trial and error
that can sometimes result when you're working in isolation (e.g.
start hacking out a solution that you think will work, get about 4
hours into it before realizing a show stopper in your design,
starting over, and doing this a few more times before finally
arriving at code that is ready for testing).
Arguments get made about the task
planning session of having the overhead of burning additional man
hours since the whole team is involved as opposed to one person
working on the story. However, if you weigh those additional man
hours against the overhead of going down a few paths before
eventually arriving at a solution, the amount of time spent working
on the implementation of a story is pretty much the same if not
reduced since there isn't all the churn of
start-stop-reassess-the-problem-start-over cycle. Couple this with
the knowledge sharing and collaboration that took place in the task
planning session, and you're coming out ahead in the long run because
you have a more cohesive solution that anyone on the team will be
able to maintain once it has been released into production. For
example, with the increased collaboration and knowledge sharing you
don't have knowledge silos where Joe becomes the printer module guy
and any problem that comes up has to wait until Joe gets back from
vacation next week (i.e. you start to get more organization agility
because now the organization is not held captive to any one person in
a particular area of the application).
In my experience, the variance
associated with software development gets greatly reduced when doing
team-based task planning. Since the whole team had a hand in coming
up with the design, the collaboration coupled with the removal of
this variance often times results in the whole team being able to
swarm a story and get it finished that much faster. The swarming in
this case does not suffer from the overhead of bringing an additional
person the coding aspect because everyone has a detailed
understanding of the story, the story's history, and its associated
development tasks and test cases.
More to come...
This post turned out to be a lot longer
than I originally thought it would, so I'm going to turn this into a
multiple parts. In future posts, I'll write about some more of our
successes and challenges. In the meantime, I'd be curious to hear
what others may have to say and would enjoy hearing about some of
your experiences.
