I have two strong views about agile.
The first view is that agile is something that you are, not something that you do. It’s a practice not a process. If that sounds a bit Zen, then that’s because that’s what agile is. Being world class at agile means a lifetime of practice and reflection and discipline. The agile manifesto is koan-like in apparent simplicity that can reshape everything around it.
The second view is that you only learn how agile works through delivering a real product. The most a training course can ever teach you is what ceremonies other people use. Until you’ve understood a user need, defined the first useful step you can take to meeting it, resisted writing the plan for the rest of it and delivered a series of iterative improvements then you can’t innately understand an agile approach.
A lot of the public sector approaches agile as a process rather than a practice, as though it’s another project management methodology of the sort that routinely comes around every few years. We go on the course, learn a few interesting factoids and freshly mangled verbs to sprinkle into presentations, and return.
In this model giving agile a go becomes like signing up for a gym membership in January: we think we should do it, we believe it might have something to offer but at that point in mid-February when it’s dark and cold and our knees hurt we revert to our previous approach; even though we tell ourselves that it’s just for one weekend, or just to get an awkward project through a difficult period.
If I’m even close to correct in my two views, then you can’t add agile into your already structured reality and expect it to filter through the gaps. It’s more than that.
Recent Comments