Over the last few months I’ve heard many experienced agile practitioners talk about their thoughts and feelings around agile adoption in London, and the wider world. A common theme between them all has been that there is a difference between saying that one is ‘doing’ agile, and actually being agile. Nearly everyone I’ve spoken to who has an active interest in agile practices has stories about a team treating agile like they would PRINCE2 or any other project management strategy. I’ve heard of and seen teams follow scrum to the letter, and in doing so completely miss the point of it. Agile is a verb not a noun, and it is worth reflecting upon that whenever we attempt to do something in the name of agile.I find that asking the following questions help me in deciding whether I’m doing something for the sake of doing it, or I hope that my team can learn and grow from it (successful or not).
How will we measure whether or not this is successful?
What are we hoping to achieve from this?
This is surely part of your reasoning to try out your hypothesis. Given the constraint of business that I talk about in this blog it’s likely that your aim is to either cut cost or increase profit in some shape or form. Make it a bit more specific for your implementation, such as reducing deployment overhead by giving access to team and therefore bypassing dev-ops queues.
Do we have the people are resources we need to try this?
What time frame are we allowing for results to start showing?
Give yourself plenty of time to implement and live with your experiment, but not so long that you can’t stop if you’ve realised that it isn’t working. My recommendation is to set multiple timeboxes up. Depending on the length of time that it’s going to take you to implement have at the very least a retrospective at the end, if not more along the way.
Once you’re living in the experiment as implemented check frequently that it hasn’t disproven the hypothesis. It may be that whilst living with the implementation that you can find improvements to make that you hadn’t been able to envisage during planning. Keep checking and pivoting as you need to prove you hypothesis.
At the end of the final timebox you need to decide whether or not you should keep with your new process or methodology based on whether or not you met what you were hoping to achieve using the metrics that you decided to collect.
Do you recognise these questions? I hope so. They’re pretty much mapped to SMART objectives; specific, measurable, achievable, results-focused, and time-bound. I don’t have a question for specific, as I’m asking these questions about a specific experiment and therefore the question has been answered before getting to this point. Next time your team starts talking about wanting to try something else get them to use SMART and see if your results are what you thought they would be.
Originally Posted at http://agilegeorge.blogspot.co.uk/2016/08/doing-agile-being-agile.html