Over the last few years I have heard a lot of people use two words more and more often together; ‘Pragmatic Agile’.
One of the most abused words in software development is the word ‘Agile’, the second most abused word is ‘pragmatic’, couple these together and you have a train crash ‘pragmatic Agile’ (this even trumps ‘Lean’ Six Sigma).
Often I see individuals or teams who apply ‘pragmatic’ views to Agile using it to justify their own reasons to hack the bits out they don’t like, often using a ‘pragmatic’ approach to leverage in traditional waterfall bits (upfront design, etc…)
Every time I’ve heard some one talk about pragmatic Agile its more often than not to justify the failures in their Agile model. It’s a great strap-line, particularly when you are trying to convince a business to go on an Agile transformation journey (a simple way to silence the skeptics in the room). Be weary of statements such as ‘we don’t do Sprint planning as we’ve taken a pragmatic view that we don’t need to breakdown our releases’, etc…
Selling Agile concepts is difficult; you are telling people that the way they have been delivering software is not perfect, this is a difficult pill to swallow. So all too often when going through the early stages of a transformation you will find that the ‘compromise’ is that the business won’t have to abandon certain ‘comfortable’ current practices (poor practices or not). You will find that some of the ‘pragmatic’ historic bad processes / practices have been merged together with the newly introduced Agile processes / practices (because everyone cannot see the problems with the existing process / practices as they we’re comfortable with them).
All to often a business will pick up on the Agile ‘buzz’ terminology and overlay it on top of their current delivery model.
A good example here at was a previous employer that believed the team had to produce a Sprint plan which consisted of all of Sprints being defined and backlog assigned before work began. Sprint planning is not a mechanism of defining all of the Sprints with the backlog distributed across the Sprints from beginning to end of the entire delivery life-cycle. Sprint plans will last only the duration of 1 or 2 Sprints (2 – 4 weeks) and are for the team to track how they are progressing within this small time-boxed window. Trying to create a Sprint plan that is from beginning to end of the entire delivery is waterfall, as you are planning every piece of work upfront and just putting ‘Sprints’ on top without getting any benefit from having Sprint plans. Why do we still have gantt chart end-to-end plans still? Because it was a comfortable process from the traditional model!
This is a recipe for disaster when adopting Agile; as it will appear that Agile is too blame when an existing pre-Agile ‘bad’ practices / processes fails (which it always was always going to do, but not the skeptics, they have an excuse that it as an Agile failing).
How do you quickly identify if your Agile model is struggling due to ‘pragmatism’ being applied? The moment you hear teams or management making up excuses and blaming it on Agile (EDD = Excuse Driven Development).
Is applying genuine pragmatism to Agile a bad thing? No, as long as it doesn’t become an excuse for not being genuinely Agile and if you find yourself sacrificing too many of the Agile principles or beliefs, ask the honest question, ‘do we really, really want to do this?’. Pragmatic Agile is when you take the best bits of one Agile methodology (i.e. continuous integration, pair programming, etc… from XP) and apply those practices to another Agile methodology (i.e. Scrum).