Fragile
(I wrote this in April ‘07 but for some reason didn’t post it. It’s become topical again, for me, so I’m posting these 10-month old thoughts unedited.)
Now it’s over, the truth can be told … we abandoned agile and went …. err …. fragile.
It was a fixed deadline that did it. With 3 sprints (6 weeks) to go before our app, or at least a few key features of it, was due to see light of day, everything seemed fairly straightforward. A couple of tweaks to existing functionality, a bit of UI facelift, and some load testing / app profiling, it didn’t seem too hard.
What happened though, was that the closer we got to to deadline, the bigger the divergence was between what we planned in sprint planning and what we did during the sprint. The last sprint in particular got really chaotic, that’s where we abandoned planned tasks and user stories, ignored scrumworks, and just did what we knew had to be done to get everything ready.
Now scrum as a methodology has worked pretty well for us so far, so what went wrong ? A couple of things I think.
First off, various team members spent more time than expected on supporting the legacy applications. One in particular had unique skills and specific sprint tasks (server setup) on which other team members depended. Since those tasks weren’t getting done, the other team members had to adapt and achieve their goals (load test on a cluster that resembles production) in other ways. We’ve had this problem all along, but all that’s happened is that tasks of this sort got planned, not executed, and deferred to later sprints. with the the looming fixed deadline, there was no alternative but to adapt and do our load testing / profiling on something other than a production-like cluster.
More generally, I think the inspect and adapt cycle was too long. It’s pretty much a two week cycle with a two week sprint. So at the beginning of the sprint the planning comes down to “where are we now, and what do we need to do next”. Then after the sprint we review and say, “well, did we get to where we wanted ?” and base the next sprint on that. Now, if there’s a fixed launch date, and it’s 2 days after the end of the sprint, then waiting till the end of the sprint to see if we’ve achieved our goals is waiting too long. We recognized that and just did what had to be done.
The other problem we faced was a classic project management one. We started each sprint with a fixed set of resources, a fixed amount of time and a known set of tasks that had to be completed. During the sprint however, what happened was that new tasks arose that were in business terms unavoidable (issues with the legacy app had to be addressed) but nothing else changed, no extra time to complete the sprint tasks (and sprint tasks could not be removed because of the fixed deadline), and no further resources were added.
