Life, Liberty, and the Pursuit of Agility

I have noticed some Scrum teams approaching the work of a Sprint/iteration as a “mini-waterfall”.  The work is thought of as having a progression just like a typical waterfall:

requirements gathering- -> analysis- -> design- -> coding- -> testing- -> promotion to staging… etc.

or something like that, but instead of spanning a year or so, it is applied to the work of a single 2 week iteration. 

Dividing Work up by role seems logical
And of course, the work is divided among the team member to the person who fits the role of the phase – a business analyst doing the requirements & analysis, an architect doing the design, and etc.    This model isn’t unusual – I’ve seen it used with IID (iterative and incremental development) and Spiral methodologies.  I guess old habits are hard to break, and a lot of folks have gotten very comfortable thinking and working in this way.  Maybe it seems like the most logical, reasonable,  and direct way to think about things.  But there are problems with this, and they are similar to the problems with the traditional waterfall. 

But there are problems
One problem is that this disregards the value we gain from the collective genius of a team working in a collaborative manner.   In the Mini-Waterfall we gather a team of bright and capable people, and then divide up the work in such a way that there is very little chance for effective collaboration.  Granted, if we are working in an Agile environment with a co-located team we have a good chance of overcoming some of the problems with the traditional Waterfall, but we are still missing out on some of the most valuable benefits for Agility. 

When a well formed and performing team works together to  investigate, discuss, and work through a problem together they will have a better chance of uncovering a great solution than if they work separately, communicating only through documents and “meetings”.  It’s my observation that working separately and only periodically coming together as a team makes it hard to benefit from the synergy of a co-located and closely working team.   When all the minds of the team are focusing on the same thing at the same time, and are communicating openly and without fear, the progress of the team is enhanced.  It can be argued that thinking is a very private thing, and that the distraction of working closely with others can hamper our own ability to “work through our thoughts”, and I’ll be the first to agree.  So I am not suggesting that we work exclusively as a team – we need both time to ourselves as well as time with our team members.   But I am suggesting that we must make a concentrated effort to do as much work as possible in collaboration with our team.

Using a mini-waterfall can lead to an Agile backslide
Another common issue of a mini-waterfall is that workers “down the waterfall” are waiting on the deliverable of another team member up-stream.   To keep everyone busy and productive starts to smell like micro-managing.  People start thinking that its reasonable to have Sprints overlap, with testers working into the next Sprint to finish up the work of the previous Sprint so that coders can start in on new work and the testers aren’t idle during the beginning of the Sprint (or vice versa depending on how you approach testing).   I have seen this proposed and used in a few cases without good results.

There are other ways to work, but it is hard to get some people to even consider them
I don’t see the work of the individual team members as being “solo” work.  Almost any task a team member is going to tackle can be done as a team, or with two or more people working together – and ideally with the whole team involved in some way or another. 

Let’s look at a very limited example that involves 3 people:  Mary – the coder, Wilbur – the tester, and Arty – the “product owner” or customer proxy.  We have a story with coding tasks and testing tasks.  The code involves adding behavior to a business object, and the tests will be done with FIT or some similar tool.  It would be helpful for the coder (Mary) to know what the UA or system tests are going to be since the UA/System/Story tests define how we are going to know that the code works – these tests are being the definition of the new functionality being added.   On the other hand, it would be helpful for the tester (Wilbur) to know what services the code is going to make available and the signatures of that code so he can write his tests.  And both Mary and Wilbur need information and direction from the customer (Arty).

So, in the mini-waterfall it could look like this (or some variation):

Arty documents requirements -> Mary codes the functionality -> Wilbur tests the functionality

In a more collaborative approach we would have:

Arty, Mary, and Wilbur discuss and write tests that define the functionality -> Mary and Wilbur work together to code the functionality, continuously running the story tests and checking with Arty along the way whenever they have a question. 

At any time during the day they could be exploring ideas either in code, in tests, or in discussion and white-boarding.  Of course, this is just a very simple example.  In real life it is possible that much of the coding will be very complex and won’t require any involvement from Wilbur.  During that part of the work, Mary would be pairing up with another developer and Wilbur will be refining and expanding on the tests previously created.  Still, throughout the process Mary and Wilbur will be in close contact and consulting with each other continuously as any questions come up.  The understanding by the team of the problem and the solution grows together.

The end goal is to find better solutions by everyone working as closely together as possible with a focus on one or two stories at a time if possible, and cross-pollinating continuously.