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.

Why?

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.

 

Agile Mindset

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?

Experience

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.