Doing Agile, Being Agile
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).
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.
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?
If you don't know the metrics that you want to track then you won't be able to collect relevant data throughout the experiment in order to assess your success or failure in retrospective. When conducting an experiment it's imperative that we maintain an empirical mindset. If you don't know why you're trying an experiment then there's probably no reason for you to start it. An experiment is only an experiment if there is a hypothesis that one is proving. Once you have a hypothesis, it should be easy to determine how you are going to recognise if it is true.
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?
The 'paperwork' of an experiment is the easy bit, the implementation is when you need to think about the practicalities of it. It's great to think about changing things, but unless you can put it into practice you're just dreaming. Maybe you need to form a shadow team that includes some members from elsewhere in the business or create a new virtual machine or buy some more data centre resource that you need to get funding for. Don't try starting an experiment unless you can get your hands on everything you need; if you can't then you've disproven your hypothesis before you've started.
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.
No comments :
Post a Comment