A nimble climber
I managed to make time to attend a talk on Agile Development and it was a pleasant surprise to hear an Agile practitioner speaking from first hand experience, advising to tread carefully when implementing Agile (perhaps I paraphrase a little aggressively) [see http://eastanglia.bcs.org/, "Agile Development. What must go right, what can go wrong (and what you can do about it)" by Giovanni Asproni]. The presenter was not so much suggesting any difficulty with Agile, per se, but cautioning, rather, that making any change to the way people work can be challenging, and it is something that requires careful consideration. Consideration, not just of the change itself and the team that will work it, but also of how it fits into the wider business context.
So – introduce stand ups, user stories and continuous integration after careful consideration (there are many more practices, of course); don’t introduce them all at once; and don’t introduce them just because an Agile Coach says you have to. (I maybe made up the last one.)
This is great advice: no matter how important software delivery might be in a business, it is rarely the only part. It resonates with me, and perhaps others of my ilk. I like the idea of being able to be Agile, without having to – checkbox-style – implement a prescribed set of practices, yet having the flexibility to implement those that make sense.
Yet on reflection, it leaves me feeling a little lost. I’ve found that Agile works when driving a pure software delivery: the tight feedback loop Agile offers is an incredible sight to behold. (At least, it is for compsci grads like me that grew up with university professors teaching the latest Waterfall technology has to offer.)
But scaling out beyond the development phase of a project to encompass analysis, design, integration, etc., I have found Agile to be a very challenging proposition. For sure, it “works”. But it can be hard – very hard – work. In an environment where your software makes up just one system in the picture, where other system changes are not using Agile, and where your business representative perhaps sits the other side of a contract and customer project management team, the need to consider the context the project operates in goes without saying, but more guidance is desperately needed: I wonder if checkbox-style templates are actually called for.
How does Agile “butt up” against those traditional aspects of project delivery such as requirements capture, integration and acceptance testing? What does Agile have to say about subcontracted deliverables and how should Agile be used effectively in a bid scenario? What aspects are compatible, and what are not? Does, or should, Agile ever form part of a larger Waterfall-style (or Prince 2, or …) project? These are questions that take Agile far beyond pure software delivery. But Agile is being adopted by many a large corporation, and not just for software development: whether it is ideal or not, those checkbox-style prescriptive templates will come out.
So how does Agile scale out? I don’t think we know. Many of us will get tied up in the checklist bureaucracy, and some of us will get tied up inventing it. As an Agile community, we need to start talking more about how Agile interacts with the world outside, and what we want those checklists to look like. If we don’t talk about it, those that “just use” Agile might reasonably expect we’ve talked about it and solved it. Unless I’m mistaken, that is not yet the case.
