I got a text from a mate of mine the other day that made me laugh.
It read:
<BEEP>> I hate sprint planning. I wish they’d just speak English and act like grown-ups. You don’t need << BEEP >> lollies and chocolates to have a meeting!
Now bear in mind this guy is a vastly experienced project manager and has rescued more than his fair share of large complex projects. He’s the sort of guy who runs at fires, not away from them. Right now, he’s in the middle of an inferno and in large part it’s due to an inexperienced delivery team and an ill-conceived belief that blindly following the agile playbook will deliver the desired business outcome.
Holistic View
But that simply isn’t true. Delivery isn’t about adhering to the agile framework. Nor for that matter is it about stubbornly adhering to traditional waterfall models. It’s about taking an agnostic and holistic view of the environment and of the problem being faced and applying the best approach and tools for that situation.
This is not to say that prescription is a completely bad thing. Especially when the pitfalls of delivering something another way are clearly understood. But what I am suggesting is that dogmatically following specific methods may not always be the best fit with the environment. In short, the ideal conditions for agile rarely exist. The reality is that distributed, large or cross-functional teams, outsourcing (in particular offshore) and limited availability of key stakeholders and critical resources, means that projects frequently operate in sub-optimal environments.
Optimal Agility
Now don’t get me wrong. I strongly advocate setting up projects for success from the start. But when the environment doesn’t allow for optimal agility then we need to be as effective as we can be. This means maximising the benefits of agile despite having to make compromises. After all, every individual, every team, and every organisation is unique. And because of that context matters. And that means we need to adapt and evolve our approach for each situation we face. Key to this is allowing teams to own their own processes and to modify how they attack a particular problem within the constraints of the environment in which they’re operating.
It doesn’t matter what different roles are called and whether a meeting is a stand-up or a retrospective. What does matter is whether the output from the activity is delivering value to the business. And that the team (or squad) is taking accountability for that delivery and supporting realisation of the benefits underpinning the business case.
Pragmatic Agilist
Pragmatic agilists champion agile whilst at the same time dealing sensibly and rationally with environmental constraints based on practical experience rather than theoretical considerations.
Recently I’ve witnessed a wave of dogmatic agilists and they typically share two common characteristics; they have only ever worked within an agile framework and they will compromise the agile principles as long as the framework is maintained. That resistance to flex and to adapt is itself contrary to the agile principles. Pragmatic agilists on the other hand, are most likely to have had experience of multiple frameworks and are open to modifying their delivery framework to test and implement new ideas in order to maximise value for the business.
To achieve the best outcome for the business we need to value pragmatism over agilism. That doesn’t mean we don’t value agile. It just means we value pragmatism more.
Just forget about the chocolates!