I read this interesting post on Agile Antipatterns. This is the second part of my take on these antipatterns. Here is the first part.
5. Scrum Master Avoids Conflict and Doesn’t Like to be Challenged
If it is a behavioural trait of an individual (avoiding conflicts/taking offence) one can only train the person and hope for expected behaviour.
However, there are instances when well-intended Scrum masters face conflict. Typically, when there is conflict between Process and Delivery. Desired delivery is important for business. What should Scrum Master do? Should allow delivery needs to override process needs?
Way out: I have seen delivery needs override process needs all the time. This might help the business in short run but will harm in long run. While a Scrum master might allow process to take lower precedence, he should find a mechanism which will discourage this behaviour. See next point.
6. Sprint Backlog Being Regularly Changed Mid-Sprint
In an ideal world, Sprint backlog is written in stone or written in mud which is drying very fast. However, Backlog change happens all the time in the world we mortals live in. In my experience, it generally happens under two circumstances –
- Product Owner/Stakeholders have been lazy and careless, and they have done wrong prioritization of stories. Or missed them altogether.
- Something in the market/situation has genuinely changed, and hence backlog change.
In either case, chances are that backlog has to be changed. What is the way out?
Way out: Backlog change throws many things off gear in dev team. It’s very frustrating. On the other hand, the mantra of agile methodology is to ‘Embrace Change’. How can one run away from it? We embrace change across Sprints, not within. One way to instil discipline with Product Owner/stakeholders is to establish a cost for this behaviour. In one of the teams we introduced ‘Cost Token’ mechanism. When such changes are pushed, we estimate the additional cost (in our case in story points). Team accepts the change, only if Product Owner accepts the additional Cost Tokens. Cost Tokens essentially was an email telling how many Cost Tokens this change costs with reason, and Product Owner must accept and agree (this system was used within team as well for various other bad practices). It started encouraging Product Owner to be more responsible and careful while requesting a backlog change. Nobody wanted cost tokens in their name. Here, a neutral scrum master plays a key role.
7. Retrospectives Don’t Fulfil Continuous Improvement Objectives
Retrospective should lead to tangible and actionable outcomes. Outcomes that are specific, actionable and measurable. However, retrospectives generally turn out to be either fights until dinner or namesake activity over a cup of tea.
Way out: I found Cost Tokens helped us a lot in retrospectives. Since Cost Tokens are created when the issue occurs, details of the issue are captured with full context. Thus, the discussions and outcomes were very objective. Cost Tokens are just a tool. Scrum Masters conducting Retrospectives earnestly is very critical with specific issues/+ves in hand.
8. Events Not Being Done or Being Done Erratically
I, personally believe, of the 5 events, Sprint Planning and Daily Sprint are critically important. While Sprint Planning set’s the direction for the Sprint, Daily Sprint ensures that the team is on the right direction.
Way Out: If there can be any ‘No Compromise Practice’, then that has to be conducting events and participation. One may feel tempted to skip daily sprint for smaller teams, that temptation must be avoided. If there is nothing to discuss, finish the meeting in one minute, but meet for sure. Similarly, when Sprint planning takes place, it should take place in all seriousness and with complete participation from Product Owner. It is Scrum Master’s responsibility to ensure that these events happen and the team participates.
These antipatterns can occur for varieties of reasons – genuine mistakes, tight deadlines, work pressure, lack of know-how or systemic problems. Keep a close eye on these as you progress in your agile journey. If not all of them, if you are not able to get rid of most of them, then probably Agile is not for your business.
so{M}usings 