Letting go of Agile Obsessions
This is the last of the 3 part series on Agile Reflection.
Throughout our Agile journey we come across things that work well. As we progress, we find some of these things work really well. As a result, we convince ourselves there is no better way to do things. The problem with that thinking is that we haven’t applied our theory to all situations, so we shouldn’t make such an assumption. But we develop these Agile Obsessions and sometimes they can cloud our judgement.
I too developed these Agile Obsessions and I had to force myself to let go of them.
Here are just a few:
1. The daily standup should always incorporate the 3 questions
2. Estimation is mandatory
3. When in doubt, always go back to the team
Let’s examine each one of these in detail.
Having the team answer the 3 questions is a very good way of applying the daily standup. But this can get stale. And in some cases it can get monotonous especially in situations where the team isn’t progressing very fast. Another option is to take the Kanban approach and focus on the board, starting with the right-most column and working towards to the left. It kinda goes against the Agile mantra “Individuals and interactions over processes and tools” but it can re-invigorate your daily standups. Furthermore, there’s no reason why you can’t go back to the 3 questions later on.
Estimations can be really helpful when planning a release or an iteration. But in some cases the return on time invested (ROTI) can be quite small. Whether you’re doing affinity estimating, poker planning, or t-shirt sizes, the practice of estimating is not an exact science and it never will be. The #noestimates movement has become quite popular. I was against it at first but I was finding that some portion of project work is absolutely necessary (whether you want to do it or not). So why waste time estimating when you could be spending that time getting the work done.
For the most part, going back to the team is a great way to keep everyone engaged and hear differing opinions. There are many other benefits but I won’t get into all of them. Sometimes, uncomfortable situations arise that may be better dealt with outside of the team. For instance, you may have a team member that just isn’t a good fit and never will be. You could try to engage the team and get them to make a decision (in terms of termination). But you may be putting them in a awkward position. Chances are they’ve never been asked to determine someone’s fate and nor do they want that responsibility. Also, they have to work the individual under scrutiny while pretending they’re not privy to the private conversations. So in these special circumstances it may be prudent for the Scrum Master or Product Owner to make the decision and move forward.
Letting go isn’t easy, but it’s important to read the situation. If a process isn’t working or if people are telling you what you don’t want to hear, maybe it’s time to make a change. Just because something worked really well in the past doesn’t mean it will continue to work well for every situation in the present and future.
Don’t just do Agile.