But we are “Agile”

I’ve heard that phrase many, many times.  Usually it’s used to justify not following the current processes, like mashing sizing and grooming together instead of having separate meetings, or making changes to a story after it’s partially (or fully) developed.

Developer:  The change you are asking for will require re-doing most of the development already done this sprint.  We’ll need a new story for this that we can work on in the next sprint

Product Owner (or any business lead):  But we’re agile, we should be able to make this change now.  You are already working in that part of the code…

It seems like being “Agile” is synonymous with not having to follow a defined process to some people.  In my opinion, this couldn’t be farther from the truth.  Agile works best when you strictly follow your process. Always, no exceptions, ever.  I think that’s worth repeating: Agile works best when you strictly follow your process. Always, no exceptions, ever.


Notice that it says your process. I’m not suggesting to follow some process in a book somewhere.  Follow the process Your Team created.  Assuming your team is following agile practices, the team has developed a very good process that works best for them, and is constantly reviewing and making improvements. If the business goes around the process, then the team is being robbed of the opportunity to improve it.

If having separate grooming and sizing meetings is too slow – isn’t it too slow for all of the other stories? If changes are needed after development is started, wouldn’t it be better to figure out why we have these late changes and how to avoid them?

It’s better to bring up the cases where the process is not working well and fix it for all stories/projects, not just the special ones.  If the process isn’t fixed, you’ll have to keep going around it every time you have tight timelines (or whatever the reason for breaking the process).

Agile works because it makes it very obvious when part of the process isn’t working well.  Everything is done in very short cycles – grooming, sizing, sprint planning, and retrospectives all happen every single sprint (if you are doing it “right”).  If it doesn’t work well, it doesn’t work well all the time.  People get tired of the process failing and will find a solution quickly.  If the pain is alleviated by not using the process, there is no motivation to fix it, so it stays broken.

My suggestion:

Follow YOUR process religiously.  If it doesn’t work well for something, fix the process, don’t avoid it.

Then, when this same type of issue happens again – your process will handle it. Sure, it might take a couple iterations to find a process that works, but you’ll be on the way to success.


Book Review: The Five Dysfunctions of a Team

I was recently given a copy of this book (The Five Dysfunctions of a Team by Patric Lencioni) by a co-worker. It is a pretty easy read. The majority of the book is a narrative/story about “Kathryn” taking over as CEO of a company with a very dysfunctional senior leadership team. She walks her new team through their dysfunctions and points out ways to deal with them.

The 5 dysfunctions talked about in the book are: Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability and Inattention to Results.
Reading through the examples displayed by the team described in the book, I could certainly see some of them in the teams I work with and have worked with in the past. “Kathryn” gives clear guidance on how to deal with these dysfunctions.

The last chapter or so steps out of the story and gives clear definitions, examples and suggestions for solutions to the various issues. It does not make the assumption that all teams are the same, but gives several different techniques to help overcome each of the dysfunctions, and points out that they are all inter-related. You rarely have only 1 of the dysfunctions, but instead have many or all but at different levels of dysfunction.

Given the relatively easy read and the quality of the information, I would recommend this to anyone who leads a team. It’s equally good if you are just part of a team and not leading it, so you can work toward avoiding the dysfunctions at least as 1 member of the team.

Is it bigger than a breadbox?

In the waterfall method of project management, we are asked to estimate how long a large piece of functionality will take to complete.  Then, all of those parts are added up to get a timeline of when things will be done, and we’re off.

As humans we can estimate how long a small, simple task will take relatively accurately.  When that task becomes larger, and/or more complex, we rapidly get worse at estimation.

Agile methodologies ask us to break the tasks down into smaller bite-sized pieces, which allows us to more accurately estimate how long a task will take.  If this is true, then why do people still do relative sizing in agile projects where the tasks are broken down appropriately?


Where both of these systems fail is when you take into account who is doing the work.  We all know that each developer works at a different speed.  There is often a strong correlation between the speed at which a developer can complete a task and their experience level (though, there are certainly times when this is not true).

So, now let’s imagine that we have a team of 5 developers and a rather large project we want to complete.  When we go to estimate, who’s estimate do we take?  Do we go with the lowest estimate, the highest, an average?  Do we divide the work up among the developers and get them to estimate the work they are assigned and hope we divided fairly evenly?  What about vacations, sick time, or someone leaving the company?

Relative sizing to the rescue!

Ok.  So, like anything this is not a panacea.  It works, but it takes effort and commitment to make it work.  Let’s start with a definition of relative sizing.

Relative sizing is simply the process of looking at the stories and determining how big a task is in comparison to other tasks.  The nice thing is most people will agree that task a is smaller than task b most of the time.

When doing relative sizing, most teams pick some series of numbers to assign to the sizes (we used powers of 2, others do prime numbers).  When picking numbers, I suggest not using 1,2,3,4… since this is too fine grained (you want some wiggle room).

Now that you have a scale, each team member can give estimates on tasks using these numbers.  When there is a discrepancy between team members, use that as an opportunity to discuss why there are differences.

Sometimes the difference is because the task is unclear, and this gives you an opportunity to clear up any possible misunderstandings.  Sometimes one developer knows something the others don’t and he/she gives a very different estimate.  This is a good learning opportunity.  Sometimes you will have very small discrepancies, like one developer estimates a 2 and the other a 4, there may not be any differences in understanding, just one thought it was bigger than the other, in that case we typically went with the larger estimate, though you can make your own rules.

You may be wondering how assigning tasks points is going to help you determine when a project will get done. Good! Because I haven’t shared that yet.

After you have points assigned to your cards you will need to plan out a couple of iterations (a defined period of time to do work, often 2 weeks).  Ask the developers how much they think they can do in this iteration and only put in the tasks they think they can accomplish.  After a couple of iterations, you can add up the total points the team completed and take the average.  That will be their velocity.

You will notice when a team first starts out their velocity will probably fluctuate as they get used to estimating and working on the new project.  Be sure to keep an up to date feel for their velocity.  I would recommend not using all of the previous iterations for the average since you may have some anomalies especially at the beginning.

With their velocity and the stories estimated for the project, you should be able to project when a project will be complete.  And, you don’t have to go to all of the trouble of assigning out tasks to individuals!


Starting an agile project with a new team

At the first job where we were trying to do agile, none of us knew a lot about what that meant.  We didn’t break down our work into stories, therefor we didn’t estimate any stories.  We simply divided up work that needed to be done among the pairs and did pair programming and test driven development.

Then, the next job where I was doing agile, we didn’t estimate our stories using story points.  We estimated in hours, kind of.  We used a set of hours that we could pick from, it was either 1,2,4,8,16,32 or 64 hours.  This allowed us to stop fooling ourselves that we could be very accurate in estimating a task that was going to take longer than a couple of hours.  In order to determine how much a pair could accomplish in a sprint (which were one week long), we simply found 32 hours worth of work and BINGO.

In my current job, I am trying to bring more agile processes to bear.  I am in charge of a new project at work and have decided to run it in a completely agile manner.  I am the scrum master (which I have only kind of done before, mostly for myself).  The project has only one developer resource.  We have access to a QA resource as well as our user experience designer, though neither of them have any dedicated cards.

The developer on this project is a contractor who is not familiar with the code base, nor with the system that we will be integrating with.  We have not worked with him before.

Our first task was to introduce him to the project and then estimate the cards that we had created.  Rather than going with hours, I decided I wanted to use story points.  Our scale is 1,2,4,8.  Anything that is sized over an 8 needs to be broken down.

After a long estimation session, we needed to determine what work would go into our first 2 week sprint.  In an existing team this is fairly easy…just look at the average velocity and put that many points in the sprint, adjusting for any absences.  But, what do you do when you have a new team and have no idea what the velocity is?

You guess.

That’s right.  Look at the cards that you want to play and start adding things to the sprint until the team says stop.  Then, make sure your backlog is groomed well so if the team guesses wrong and can pull more work in than they thought, they can pull from the top of the backlog.

If the team doesn’t get all of the work done that they committed to in this first sprint, don’t hold it against them.  The first couple of sprints are learning sprints.  The team is learning the code base.  The team is learning the process.  The team is learning what their velocity is.

After a few sprints you can take the average velocity and start using that to plan out the work.  If your team is consistent with their estimation, and is fairly consistent in their velocity, you should be able to fairly accurately estimate when different features will be complete.


Searching for the why

I have recently started a new job.  The company is still very small, and has been operating in a very start-up mode.  When they brought me on board, they wanted to start implementing new processes.  Since I am very passionate about this, I was very excited.

I have a very agile mindset, and believe that the team should be very involved in defining the processes that they use, and have the ability to modify those processes when they are not working as well as they would like, or even working against them.

Developer Summit

One of our developers works remotely, so in order to facilitate discussion of what processes we wanted to put in place, the company flew him to the office and we had a 2 1/2 day developer summit.  We didn’t do any (or much) development during this time, but simply used the time to talk about how we wanted to work.

During our discussions, we, thankfully, agreed quite often on what we felt was the right process for us.  But, our discussions were more than just a checklist of “we should do a, b and c”.  We often talked about what we wanted to do, why we wanted to do it, and what that process or practice would allow us to accomplish.

At the end of the summit, one of the more junior developers mentioned that she really enjoyed the summit, and was happy to hear us explain why we wanted to have the processes we talked about.

Why the why?

Years ago, I realized how important explaining why was to our line of work, and I got myself into the habit of always explaining “why” when discussing something the team had not previously discussed.  I also, try to restate the why periodically just so everyone remembers why we do what we do.  It is very easy to get into the habit of doing something, and forget why you started it in the first place.

So, why is “the why” important?  Why can’t we just state that our process is x and execute on it?

I can think of 3 reasons why knowing the why is important (I am sure there are more).

1) Knowing why a process was put in place makes it easier to remember what the process is and explain it.

When a new employee starts, it easier to explain a process when you understand why the process is in place.  Also, for me, knowing why can often make it easier for me to remember the actual process, especially when it is something that is not used very often.

2) Knowing why a process was put in place makes it easier to know when to not follow the process.

I live by the rule that we control the process, and the process does not control us.  A process is there to make our lives easier and allow us to do our jobs more effectively.  Sometimes the process will get in the way and make it harder for us to do our jobs.  In those cases, we should be able to weigh the benefits and costs of not following the process for this one instance.  If we do not know why the process is in place, we will have a much more difficult time weighing the effect of skipping the process.

3) Knowing why a process was put in place makes it easier to know when that process no longer makes sense.

As I said earlier, we are in charge of the process.  Sometimes processes are put in place that make sense when they are initiated, but over time, the benefit of the process goes away, but we continue to practice it.  Knowing why a process is in place, and what benefit it brings allows us to revisit these processes, and decide if it is time to retire it.  This is why it is important to restate the why every so often.

Not just for processes

Understand the why is not just useful for processes, but also for coding standards, code techniques, design patterns, etc.  Understanding what these things are is important, but it is just as important to understand why we would want to do some of these things.  This helps keep us from applying techniques inappropriately, and helps trigger our memories to apply the technique when it makes sense.


I encourage all of us to look at what things we do and understand why we do them.  If we are doing things that no longer give us any benefit, then really think about whether we should continue doing them.

I also encourage everyone to make it a habit to state the why when talking about a new process, and restate the why occasionally, especially when new people are around, but even when it is the same people as always.