Andrew on Agile

During my ScrumMaster certification, Mike Cohn recommended that the size of a cross functional scrum team should be between 5 and 9.  In a recent exercise, we tried splitting a scrum team three ways – 5-6 people in each team - for the next release.

At the end of last year I counted 16 people in a scrum.  For most of the release the team size averaged 12, consisting of a mix of product managers, QA, front-end engineers, software engineers and the ScrumMaster.  16?  It never meant to get that big, but with an addition here and an addition there, it did.  It was too big.

The scrums were starting to take too long, there were too many stories in the sprint for one team to truly keep track and impediments were flying around everywhere.  Risk was starting to creep into each sprint and eventually the release.

I put it to the team that they should split in half for the next release and while some members were ok, others really objected to the idea.  They felt it would generate unnecessary tension between a team that had grown strong together.

Due to the type of work within the first sprint in that next release the team worked as one again, but agreed tentatively to an unequal split (1/3 to 2/3) for the following two (and final) sprints.  It was ok, both teams had a couple of issues mainly down to the fact that they were building three applications which all needed to communicate with one another, but the smaller team certainly preferred being small.

So now they’ve split into 3.

It’s brilliant.  The teams are made up of 1-2 QA, 2-3 Engineers and a Product Manager.  The teams were encouraged to go through the agile scrum motions how they saw fit.  The smaller size enabled intense collaboration during a short planning phase, resulting comprehensive stories.  Poker and sprint planning was a breeze, less big personalities to get in the way of proceedings, and it was so much easier to keep on top of the progress during the sprint.  The software’s of high quality.  It’s done.  It contains a good level of tests and the quality of the code is great.

Now that risk is greatly reduced.  In the sprints before if something started to go wrong it could have affected the whole team.  All members would get distracted by the issue and if it didn’t get resolved and the goal compromised, the team would be left demoralised by all the drama such failed sprints bring.  Oh yeah, and the team members love it.

So if it was going good, then the team gets bigger and you start to have problems, or if you’re trying things for the first time and some members aren’t engaging, break it down.

I’ve been having a series of conversations lately with one of my engineers about learning on the job.   By this I mean that technological problems get figured out during a sprint.  These problems usually arise from implementing technologies that aren’t so well known by the engineering team.  A recent example for us would be finding solutions for complex queries with Fluent NHibernate.  The conversations were sparked by recent events during our last release where a sprint goal was compromised by the introduction of a new Domain Driven Design (DDD) architecture, and the previously mentioned object relational mapper (ORM), Fluent NHibernate.

The engineer’s argument for learning on the job centres on the satisfaction gained by solving technical challenges presented by new technological ideas.  As a manager, engineer’s job satisfaction is very important to me.  In an unsettled economic climate such as the one we’ve just been (and perhaps still are going) through, it becomes even more important to use everything available to keep morale high.  Our favourable stance to adopting new technologies over the past couple of years – we built a production app in .Net MVC right through its preview stages, releasing the app as MVC was released – has kept the engineers interested in their jobs.   That being said, introducing a new technology is accompanied by risk, risk that can turn into a high cost.  Learning on the job during the sprint is risky because it can create impediments that are very difficult to remove.

In order to find the right balance it is important that all the engineers know what they’re doing throughout the sprint.  If a sticking point arises, e.g. a situation where you notice an engineer stuck with their head down for hours on end, a couple of scrums pass where they say they’ve got 1 or 2 hours left and they’ll be finished that day but they never do, then you know you have a problem.  Sometimes this can be solved by pairing, but probably it’s a sign the team hasn’t done enough homework.

We just halted the introduction of a messaging technology into the next release and are mid way through a two week planning phase.  The aim is to take a small sideways step in order to make sure the engineers are technically up to speed with what’s going into it. 

The focus of the first planning week has been on story generation, next week we’ll be exploring those stories further to find potential engineering sticking points. When they are found the whole engineering team will come together to investigate the solution.  This object of this exercise is not to create solutions for all our potential problems up front, as any changes to the backlog during the release could render this a waste of time, but to use the potential problems as case studies to ensure the engineers have enough knowledge about the technologies we have introduced before embarking on the sprints.

This is not something we will do between every release.  A series of weekly, hour long sessions to contextually spike the implementation of the messaging technology using a current production app will get underway as soon as the release starts.  We will only introduce it across our range of production apps when the team feels ready.

This is what I consider learning on the job.  There will inevitably be some learning during the sprint, but the aim should be to control that as much as possible.

We had just finished the first stage of a green field application and missed our sprint goals.  Damn!  When we first saw a problem, should we have pulled some work out of the sprint?

 This is not something anyone should be afraid of doing.

Let’s look at what happened.

The competent team had worked together for 18 months on various projects.  A new style of architecture was to be introduced to improve testability and in preparation for this shift we had invested in several internal group educational sessions, as well as some good debates during sprints.  At the start of the sprint we didn’t commit to as much work as we had capacity to do, however we were pretty close.

After 4 days we hadn’t delivered anything to test.  Complications with the precise approach to the new architecture were holding up the project.  At the end of the 5^th day we still had nothing into QA, so we held a 2^nd daily scrum.  We agreed if we finished engineering a couple of  stories so testing could start by the end of the next day, the engineers would finish the rest of their work during the week and time could be made up by engineers pair testing with QA.  A little ‘waterfalacy’ but it was only 1 sprint so never mind!

Can you guess what happened?  We didn’t meet the sprint goals and were left with about 40 hours worth of work.

I’ve been in several sprints like this where for various reasons the goals haven’t been met.  The end of the sprint is unbearable.  The team gets micro managed; frustration grows and turns into panic – a desperate rush to get things done during the last couple of days – then there’s the realisation at the 11th hour of failure. 

Failure!

I don’t like that word, nor does the team who’ve worked so hard to try to reach their goals.  The effect it has on morale is a real pain to manage and it doesn’t encourage better quality work.  To avoid ‘failure’, teams cut corners and in my experience the tests – so important in modern-day software engineering – go first.

So what should we have done? 

The real focus should have been right at the beginning in sprint planning.  The potential unknowns associated with incorporating a new technical design into a green field project should have been taken into consideration by the team when confirming their commitment.  It’s easy to say in hindsight, but the team should have committed to less in the first place.

That said, if the team are confident that their commitment is achievable, as they were in this instance, and you find yourself in the same place as us, you have three options.  The first is to carry on building, accepting the risk of digging yourself a deeper hole.  The second: abort the sprint.  The third is to pull some stories from the sprint with the approval of the stakeholders.

We know the first option is a BIG risk as you may well end up compromising the quality of your product.  The second, I don’t think the situation was serious enough for an abnormal termination.  I prefer the third option of redressing the expectations and pulling something out of the sprint.  I just think it’s more practical.  There is no need for all the drama the other two options create and the sooner the stakeholders are informed of any problems the better.

I don’t think this solution is right for every situation.  What’s the point of having a goal if you can just move the goal posts when you feel like it?  But sometimes, such as the example Mike Cohn alluded to during my ScrumMaster certification where you have a team new to scrum who are finding their velocity, or this situation where there was a good reason for changing the architecture, then I think it’s the best solution as long as everyone agrees.