Ours is the best Agile team in the Organization that’s totally frustrated yet focussed towards sheer delivery! If that defines your professional day, go ahead and read on. I intend to explain some of the agile abuse problems, most of the enterprises face today with some pointers around tackling such situations.
So lets begin with some of the major symptoms of agile abuse:
Should I stand-up or lie-down ?
A stand-up is a daily team ceremony where each team member quickly talks about what he worked on yesterday and what he will be working on today followed by any hurdles he is facing. Often when a team is newly formed and most of the members come from a traditional project execution mind-sets, they fail to realise the importance of the preciseness of a stand-up update. So much so that they end up wasting most of the time leaving other team-mates with less or no time to provide their rather critical updates. This can be observed in teams having mix of few junior and many senior folks.In such teams often a less experienced voice goes unheard. And soon it becomes so irrelevant for others that they begin losing interest in the activity.
Ok, so lets interrupt the moment we feel its no more a standup and ask the person to carry on the discussion with a smaller audience right after the stand-up is done. Try to emphasize on how it is a waste of time for those who barely know the problem being discussed. Try to speak to other members offline if speaking upfront does not sound as a feasible option. If there is a scrum master in the team, raise the issue with her requesting for a dedicated Tech/QA huddle time anytime after the stand-up to avoid long stand-ups. You may even mention the time lost in long standup as an update in next day’s stand-up if that helps 😉
Yay, the team just got bigger, more fun is on the way!
“The customer just added a whole bunch of new features and we have borrowed resources from other projects to live up-to our commitment”, says Alan, the developer on the team. This is totally unacceptable as per Scrum guidelines that states that the optimal team size should be between 3-9. This is in order to maintain a good autonomy that in turn allows enhanced productivity. If a team grows beyond this size, it an indication of poor planning and is against Agile. Agile does not asks teams to blindly adapt to the changing or growing customer requirements without considering resource availability.
This is more of a product owner/ scrum master problem than a team members’ issue mostly driven by the organization’s budgeting strategy and orthodox minded stake holders. This does not mean you can not highlight/discuss the issue with the team or anyone for that matter. Sometimes, explaining the business stakeholders about the adverse effect of big team may help resolve the issue. You may suggest having smaller activity oriented teams for better productivity. You can consult an Agile coach to help bring the PO and business stakeholders onboard with this idea.
“I am an agile developer and I don’t document anything but code.” While documentation can be a time consuming activity, not doing it at all will only lead to less team confidence and understanding over a period of time. Even good code demands Read-me’s, inline comments and API documentations for verbosity and clarity. Zero documentation is a sign of poor cross team communication and can lead to confusion.
This is a simple one and can be addressed in many ways. Any team member can educate the rest of the team on how documentation can help in gathering historical evidence of what was concluded in past or what is the sprint goal. At the very onset, an agile team should collectively agree on what they consider important to be documented and how would they like to go about it. This may often lead to disagreements but like many other agile activities, can be concluded by vox-populi! Based on my experience working on diverse agile teams, it is important to define, revisit and refine team’s documentation strategy during the project life-cycle. If you hate to draw designs using tools, so be it. Simply have an email sent out to the team outlining the design decisions.
Its Hawaii-time for me dude! \00/
So every team has this I-dont-care-about-commitment person who plans a vacation whenever a critical feature needs to be delivered. Just because the team claims to be agile, does not mean that anyone can plan vacations as they please. Again, such problem is common in teams that has people lacking pure agile experience. They tend to disregard how the team’s commitment gets hampered by their random leave plans. Taking time off is not a crime, it just needs to be communicated to the team and accounted for during sprint planning.
If you too have such team-member try having a team retrospective meeting to reflect on what is going wrong and why the team is unable to deliver consistently. If this is not working, speak to the PO or Scrum master to consider team’s planned leaves during Sprint planning. Reiterate that agile teams collectively commit and take responsibility for its success or failure.
In general, having a regular Retrospective meeting helps the team spot all the above issues and tackle them in a collaborative manner.
Keep up the Agility ❤