People & Process Thoughts

When is a Sprint not a Sprint?

One of the nicest aspects of building Gemini is that we get to work on all sorts of cool consulting gigs with great customers. Many of these are with the in-house Agile teams and the more we work with teams in different organizations the more we learn that Agile is not a one-size-fits-all methodology.

A classic example of this is the Sprint that was not a Sprint and how it evolved an even more Agile approach to development.

Classic Agile says:

1. Sit down with the business to define what their requirements are.
2. Turn these requirements into stories (you can start with an Epic if you like, but that's just a mega story IMHO).
3. Identify the tasks that make up each story and their dependencies.
4. Plan and prioritize the work, breaking it into bite-sized chunks with a piece of working software as a deliverable for each Story.
5. Start building, testing etc.
6. Show the business what you built and get their feedback.
7. If they like it deploy it, if not load the feedback into the next cycle of work.
8. Start over.

You can have variations and finesse this list any way you like. Some teams start from step 1 again, some teams are recipients of what happens in step 1 and only get involved at step 2. Some have steps 2.1, 2.2 and 2.3, which may or may not involve external 3rd parties… The differences are endless. Nobody is asking for permission to vary from a strict standard, they just do the things that work in their organization because every organization is an abstract. The point is that from an efficiency standpoint nothing should come between points 5 and 6. If something does come between development and delivery then Agile says you should welcome it, or to quote the Agile Manifesto:

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

As stated, this makes little sense. It might have good intentions behind it but how can one 'harness change', it's not like change is electricity? Change is nearly always disruptive and costly, so quite frankly, in many of our real world, abstract Agile teams, it's as welcome as a chocolate fireguard!

The missing piece of the Agile manifesto is what to do when change is so disruptive as to render the Story in the Sprint unworkable. What if the change renders the entire Sprint redundant halfway through?

This is the situation faced by real teams in the real world and it is unavoidable in one particular case because the Sprint has to be planned in advance (whether an Agile purist likes it or not), so it exists at a structural level with a load of financial and resourcing detail resting on its successful completion. But the Sprint might yet fail in its sole purpose, to deliver working software (and sometimes does). Does the business shrug its shoulders at the resulting inefficiency and dedicate time and executive resources to 'fix' the issues? No. This is the REAL world.

There must be 10 ways this problem can be solved but it is not the purpose of this blog to look for alternative solutions to the one in place, which is to treat all requirements as potential, qualified work but not to run a Sprint in the traditional sense. Each 'Sprint' is more like a single Use Case, scoped out to be a Story. There are consequences of this, such as the near impossibility of calculating Velocity, since consistent Sprint lengths must now be abandoned in this pragmatic reality as different Use Cases/Stories require different levels of effort and consistent time intervals can only be obtained by combining Stories in a Sprint where some of them are very quick to deliver.

There are benefits - in most cases the Sprint is so short and focused it is impossible to have a disruptive change between development and delivery (which is the goal here). A Sprint can start and end on the same day, sometimes only involving one or two people, while other team members get on with planning the next. Another positive side effect is that the business is now very much more involved because of the compressed timeframe between notification that work on their deliverable is beginning and the point in time when they are expected to perform UAT. Their development processes are no longer about throwing work over the wall to the delivery team and coming back two weeks later to kick the tyres on the stuff they built. That said, the business complains that a resourcing problem has now shifted their way since they cannot plan to have the right users available at regular slots and their work is just not suited to Agile. There are pros and cons everywhere.

Are you still Agile if you don't have standard Sprint lengths? Would you still be Agile if the team was so involved in the work they were doing and could usually get through it so fast that a Retrospective was nearly always pointless? Are you Agile if you don't have a Standup every day, or the business folk refuse to work with you on a daily basis because they're busy, out of the office, not co-located? Yes, of course you are. Agile is a state of mind and if the methodology wasn't flexible enough to allow its rules to be broken to maintain its principles then it would be a shallow and useless tool. It isn't, so innovate away, just deliver working software as your primary goal and give your users what they want, not just what they asked for!