The root cause of a lot of adolescent Agile issues spur from exceptions that teams make in the values and principles in order to better accommodate conventional ways of working.
Common examples include:
- Waiving the need for a dedicated Scrum Master/Product owner in Scrum
- Creep of exceptions to the definition of done
- Removing structured points of collaboration (ie standups, retrospectives)
- Introducing dependencies external to the team
The reasons behind allowing these problem-causing exceptions are often “it is what it is” instances – “we had to do that because that’s just how our business works”, “we aren’t a typical Agile implementation” etc.
The belief that a team or business is unique and therefore unable to adhere to all of the Agile values and principles is more-often the norm. There’s nothing wrong for wanting to tailor their implementation. However, the ways in which people modify and when they choose to do so are the source of the issues.
Every business, team and service is a little bit different, so it’s not surprising working in an Agile way isn’t ever a one-size-fits-all solution. Furthermore, in this age of “scrumdamentalism” and other rigid “dark agile” methodologies, we’re seeing more and more reasons why treating the manifesto and the scrum guide as gospel could cause more harm than good.
Most experienced agilists will likely agree with your want to customise. After all, it wouldn’t be “Agile” to have a framework with a fixed means of implementation. Allowances can be a sign of a mature team and can boost team performance if done correctly.
So, how do you make exceptions to your implementation without them becoming the cause of your problems? The best thing you can arm yourself with is, in true Agile fashion, is an awareness of where you are and where you want to be.
When you take a look at skill acquisition paths like Shu-Ha-Ri and the Dreyfus model, they share similar steps.
- Start with adhering closely to rules, followed by
- Learn to adapt and apply situational awareness.
- Apply your own rules based on experience, learned behaviours and awareness.
These models reinforce tailoring is necessary for progression. The difference, however, is exceptions are applied as a result of proven experience, not on assumptions that have been informed by years of working incorrectly. In Agile, this is where the importance of empiricism comes into play and where exception-makers stumble.
We learn our way forward in Agile. Making exceptions for fear of things not working, rather than with empirical evidence that they don’t work is a regular tripping point. When this happens, not only does it show that the exceptions are fallible, but it also shows there is still a need for a more competent understanding of the Agile values overall. At this point it’s recommended to go back to the basics and see if you can apply your learnings differently.
Until the values and principles are truly internalised (such as knowing the need for empiricism and improvement through retrospection when making changes), there’s enough evidence to show the team is still not at a point where it’s ready to jump into the much tougher realms of exceptions and custom, post-agile approaches.
For example – until you understand why you estimate, there’s no need to experiment with the concept of “no estimates”. That lack of understanding will become both a pitfall and a roadblock in your recovery from an inevitable failure.
Start with the fundamentals and aim to master them. Only then have you created a safe environment to experiment and adapt with any substance. At the very least, you’ll always have those basics to fall back on.