So it’s a new year and with a deep breath, I thought I’d take a moment to take stock. In particular, I’ve been thinking about the current state of Agility in our industry, and where we’re going in 2013.
Over the last 2 years, we’ve seen Agile practices spread like wildfire. The buzzword of the moment, everyone discovered that without some claim to Agile competence, one’s prospects became limited. The term “Agile” is so broadly sweeping, so open to interpretation and so comparatively youthful, that inevitably we’ve seen an overwhelming acceptance of what some would claim to be Agile, but differs greatly from even the loosest definition of the word. Status quo, traditional software delivery management, with some nice Agile lipstick.
I think this stems from the popularity of the movement, it’s (now) mainstream status, and a need for existing industry stakeholders to maintain relevance.
I’ve written before about the concept of the “Agile PM”. I’m from a PM background, and I’d hope to have conveyed my belief that whilst there’s a very important role for “us” to play, it ought to be more about using project experience to better embrace agility, rather than find ways to square-peg Agile terms into waterfall.
The (soon to be released) PMBOK V5 is said to contain much greater Agile content, edited by Mike Griffiths. Mike’s blog is one of my all time favourites, and I’m sure he’s done his best to get it right. The current PMI website section on Agile has some worrying stuff though. Article titles like “Agility in Fixed-Price Projects” and “Using the Wall Gantt to Track Tasks in an Agile Environment”? Any wonder some long term Agilists are jaded.
And so to 2013, and what lies ahead.
To me, the above demonstrates that Agile has been wrongly cast as a set of procedures. We have stand-ups, we run sprints, we have no doco – we are Agile! It’s a problem when just a small scratch of the surface reveals guardedness, veiled work, a lack of genuine introspection. Truly Agile teams demonstrate all these traits, as a set of behaviours; behaviours that are far more important than a task board or user story adoption.
I am hopeful then that there’s truth in the idea that culture will be the next big thing in software development. The Agile movement (like most movements) will suffer corruption (deep eh!), but if we cling to team culture development through the seeking of Agile behaviours, then there’s a chance.
I’ve revisited the Core Protocols over the Christmas/New Year break and it’s been great to divorce my thoughts about planning and processes from how teams conduct themselves and their commitment to one another. If you are not familiar with the Core Protocols, they’re a set of structured team interactions developed by Jim and Michele McCarthy, through their study of high performance teams. They’ve documented their ideas in a free book “Software for your head”. It’s a difficult read, but its principles are fantastic.
The Core Protocols demand that every team member makes certain commitments such as:
- To engage wholly when in within the team workspace or alternatively (check in), let everyone know that you are not presently capable of that (check out).
- To bring their feelings to the team, sharing them openly and considering their impact (thinking and feeling)
- To always ask for help, leaving the ego at the door
- To observe and trust in the freedom and feelings of other team members
It’s a bit hard to envisage all teams buying into the Core Protocols (there are eleven), especially without attending one of Jim and Michele’s “bootcamps”. The lesson is that they don’t touch on workflows or development techniques. They focus solely on the way that teams interact, and central to success is total honesty an total trust.
…..and that’s where I think we’re going. If we’re going to progress, we’ll move from focusing on the functional aspects of Scrum or Kanban or whatever (the things we now do automatically), and move to a focus on the way we behave and interact. A commitment to developing an Agile Culture.