Agile: rules are there to be broken
Let's say you have a good grasp of the basics of Agile and your scrum team seems to be working well. Then one day, you have a terrible sprint planning session: after a long argument, you just can't agree on how to split your stories.
So, you do what any responsible scrum master would do: you go back to the Scrum Guide. Only, there's no clear answer to your problem there, or in any textbook. So, you do the next thing that any reasonable scrum master does: you Google it.
From the frying pan, into the fire
Unfortunately, when you look up anything to do with Agile online, you’re likely to be bombarded with all sorts of contradicting arguments, with fierce supporters on either side. So, what are you supposed to do?
Agile methods are often made to fit specific situations. As a result, it can be impossible to follow some rules without breaking others.
It's difficult enough to make a decision based on the intricacies of Agile methodologies as they are prescribed, but the dogma surrounding them can make finding a solution frustrating to the point of exasperation.
You’re told you must create something potentially shippable in every sprint, yet continuous delivery advises you to create a walking skeleton first, which could feasibly take up your whole first sprint.
Oh, and good luck trying to make every story meet the INVEST criteria if you’re working with legacy systems! Alas, the world just isn’t simple enough for a ‘one size fits all’ approach.
Agile methods have grown organically over time and are often made to fit specific situations. As a result, it can be impossible to follow some rules without breaking others.
Throw away the rule book
Anyone who says that you ‘must’ or ‘can’t’ do something under any circumstance has either misread or (shamefully) never read the Agile Manifesto. The manifesto gives you a clear direction: to value individuals and interactions over processes and tools.
Scrum, Kanban, XP, SAFe and other frameworks are all processes. While they’re useful, they’re not as important as a happy and collaborative team. Being too stubborn and inflexible about process (or anything) can prevent you from taking full advantage of Agile or, even worse, can seriously discourage people from Agile in the first place.
So why is dogmatism so common in the world of Agile?
It’s all about how we learn.
Learn the rules well, so you can break them properly
Alastair Cockburn introduced the concept of Shu-Ha-Ri to the world of software development. It isn't the only model that describes learning, but it is about as simple as you can get without losing anything important.
It summarises learning in three stages:
‘Shu’: Obey – the student trusts his or her teacher and follows their rules exactly.
‘Ha’: Digress – the student begins to experiment.
‘Ri’: Separate – the student becomes a master and understands when the rules don’t apply.
The key to succeeding in Shu is accepting that you will probably disagree with some of the rules you are following, but you should avoid changing them until you have enough knowledge to do so effectively. Just don’t accept them as universal truth.
By only following one approach, you can get stuck in the Shu phase: you want there to be one right answer because this makes it feel as though you're 'doing things right'. But, sooner or later, you’ll face problems that following the rules won't help you with.
So, how do you find solutions?
First of all, look to your team for solutions before hitting the books, and aim for compromise in your meetings. Take advantage of the expertise of your colleagues, but always approach solutions with a critical mindset.
Don’t be afraid to experiment and get more confident with throwing away things that aren’t working.
If you’re not sure of something that someone has suggested, go back to the 12 agile principles and ask yourself, “Does what we’re trying to do contradict one of the principles?” If the answer is yes, maybe you need a rethink. But don’t be afraid to experiment and get more confident with throwing away things that aren’t working – be aware of the sunk cost fallacy.
Then finally, take the path of least resistance to your goals – even if you feel like it isn’t perfect. The key to successfully transitioning to the Ri phase is accepting that “perfect is the enemy of good”.
Accepting ‘good enough’ solutions will not only make your life easier, but also free up your precious time to concentrate on more complex tasks. Agile software development succeeds through creating a culture of collaboration; by validating good ideas from others, your own ideas are more likely to be accepted.
The rewards that come from finding a new and innovative way to solve a problem as part of a highly collaborative team, far outstrip any pride gained from the sense of being an Agile perfectionist.
So, not only is it OK to break the rules, it’s inevitable that you will. And you should feel good about it.