How Agile Failed Us

Well, actually, Agile wasn’t to blame, it’s an obviously internet search tuned headline.  We broke it, and I’ll attempt to show how:

My team is trying something different.  For a few years now, we/they have been doing Scrum.  As in all successful agile implementations, it’s been tweaked to fit our workflow and calling it Scrum now is more a habit than a true description.  And it is working for us …mostly.  We’ve just embarked on something new and I thought I’d give a bit of a description of where we’ve come from and where we’re going.  Hopefully it’ll resonate with anyone who isn’t on my team reading this – especially the bits that I now see as obviously brain-dead!

Back in the Stone Age when we started with Scrum, it kind of reminded me of having just discovered fire.

We asked questions like “What have I done since last stand-up? What will I do before next stand-up? Is there anything blocking me?”.  We would vote on the number of Story Points based on an explanation and discussion in Planning-1.  We broke our stories down into tasks in the planning-2 meeting.  We guessed at how long a task would take, carefully noting the number of hours and calculated what would fit into a sprint, adjusting according to assumed efficiency (or lack thereof) based on a magic algorithm.  But from where I’m standing today, all of that seems horrifically broken.  About the only  activity that we do the same is break our work up into sprints and measure our velocity in story points.  When we started “doing agile” it was all about being able to tell the business when we were going to release.  Of course, we got so good at it, that we changed our version control branching strategy to admit the fact that the business demands when we release (more often than just every two weeks).  So the fire started keeping us warm and we were able to taste cooked flesh, but for anything other than the very basics, we were still getting burned.

And, of course, we started working on an entirely new project.  This involved technologies with which we weren’t completely comfortable and work that didn’t fall into the same patterns.  Suddenly our estimates were way off.  Our ability to do any kind of meaningful task breakdown without the code on hand was r-educed to almost zero.  The new technologies meant our time estimations were way off too.  So during the retrospective, we would try to address these issues, one by one until we morphed Scrum into what we practise today, except for the new bit that I’m not ready to expose yet.  Of course, our inputs changed dramatically too.  We didn’t really have a release date – just an amorphous blob of work that we would need to do before we could release it.

We started doing what I refer to as ‘demo-driven development’.  Our time-based sprints were forced into fitting the next deliverable and that was the only goal.  Everything at the cost of the deliverable.  It was actually fairly motivating and not as bad as my wording of that sentence would lead you to believe.  But we never really got to perfect it.  We missed the fact that a Demo is both a fully fledged story in and of itself, and that it’s a huge integration exercise, which will derail your whole sprint if you don’t jump on it asap.

Now we have a backlog and it even has some stories in it which vaguely predict an imaginary date of when we finish.  We tell the project managers that this number will likely double and they pretend to believe us.  But the first difference is how we go about getting stories into a sprint.  Instead of sitting in ridiculously long meetings masquerading as “planning”, we groom the stories first.  And by groom, I mean we try to figure out any nasty surprises that might be lurking there.  We do this at our desks, on our own, giving a possible solution to the problem.  This usually involves a lot of hard thinking and a bit of design – always alongside the actual code and design docs!  We try to avoid designing the story completely, but get a really strong feel for it and lay it out as though other adults who are capable of abstract thought are going to pick this up and start work on it.  I know, this is a big step up from being treated like a trained monkey at the various fast food outlets or supermarkets we’ve probably all worked in at some point in our lives.

So we put an educated guess on how many story points we believe it’s worth along with some acceptance criteria to know when we’re done and then (and here’s the critical bit) we pass it along to one other developer and the test analyst for their review.  Only after they have said that the story makes sense to them is it moved into the approved state, waiting for voting in the planning meeting.

During planning, the person who was responsible for the initial grooming explains the story to the rest of the team and points out the scary bits / risks, with any team member able to chime in with their two cents.  After everyone has exhausted their desire to speak (or the scrum master politely suggests we need to move on), we vote on the story.  If there is a lot of variance, we will then get some of the outliers to defend their vote.  This comes in the form of “It’s not a (n + m) because… and not a (n – p) because…”.  We use standard scrum numbers for the points: 0, 1/2, 1, 2, 3, 5, 8, 13, etc.  We have a definition of what each number includes, which we often refer to when defending them.  3 for example, requires some design, therefore the risk goes up from a 2.  13 means everything else is to be put on hold and even then, we might not finish it in the sprint.  Your number scale will vary.

We even got pretty good at it.  We managed to start achieving our sprint goals, even finding some room to play a bit more with the technical practices, like pair-programming, TDD, etc.  And then we switch projects again.  We toiled for about a year and released the software on time – but it wasn’t exactly a sure thing.  The timing was incredibly tight and by the end of it, we were spinning our wheels just fixing bugs (the “stabilising period”).  We wouldn’t have been able to conscientiously release without that time, but the agile literature implies that if we’re doing things correctly (as we believed we were), it shouldn’t be necessary.  The software is able to be released at the end of each sprint, right?  Most of the problem there is that we were sacrificing the technical practices in lieu of the stupidly, ridiculous (even by software standards) time-frame.  The classic mistake.

But then something a little weird happened; as the business wasn’t (yet) able to tell us when the next iteration of this software was needed (“soon” isn’t a real word, you see), we embarked on a new trajectory.  We went back to the demo-driven development, but altered it slightly.  We removed the time period from the equation completely.  Our sprints would take as long as needed, but ultimately should be focussed on achieving the demo.  If it wasn’t part of the demo, it didn’t make the cut.  Except for when it did.  We discovered something fairly critical: once time is removed from software delivery, all urgency is lost and “oh, but we’re definitely going to need it” becomes a convincing enough argument to do some Yak Shaving.  And then the sprint goal just gets further and further away, meandering until the person, whose single wringable neck is on the line for actually delivering this software, gets extremely frustrated with how it isn’t being delivered and announced the timeless experiment a failure.

We got a bit lucky, as well.  During the sojourn to nowhere, the good folks in sales sold the system!  Hurray! Now the project in its current form wasn’t just optimistically scheduled – it was completely and totally, laughably impossible.  We had guestimated about 9 calendar months of work, which now needed to fit into about 3.  Suddenly the impossible was easy.  If said customer didn’t need it, it didn’t make it in.  Period.  Our potential contractual obligations were the only driver.  The schedule was still tight, but it was normal software-tight – not impossible.

Now, having discovered that time-boxed, demo-driven development doesn’t work just as effectively as non-time-boxed, we’ve done what good engineers should do when they’ve run out of a clear path forward.  We’ve gone back to first principles – but we’re trying to carry our learnings to date with us.  We are now having the formal retrospective, planning I, and planning II meetings.  Our stand-ups include what we’ve done, what we’re moving on to and what’s blocking us.  Though that information is cleverly disguised as our leadership inquiring as to what’s happening on an individual basis, which avoids the meeting devolving into a daily vertical nap.  Our planning II meeting involves a bunch more prior research and isn’t as fractured.  We no longer try to account for time using hours or magic formulae.  We have a strong focus on the technical practices suggested by XP – Continuous Integration, Pair Programming, and striving for the most difficult of all: TDD.

Of course, we’re not perfect.  We’re still lagging behind schedule and the code still comes out with a defect rate higher than that required for release after each sprint.  But I feel we are improving.  Probably.