I’ve worked with a large number of development teams over the last few years, all using some of Agile’s flavors to create backlogs and manage their work. I have seen very few teams who do it well. Agile is considered to be a team-driven, team-centered process, and the failure to effectively implement Agile’s core issues at the team level means that Agile’s desired benefits will not be achieved at the organizational level. Here are some of the most common problems I’ve encountered.
The groom and the plan failed
Teams are made very thin to perform the regular grooming and sprint planning activities required to maintain a consistent speed. At the beginning of a sprint, they pick up the features and “they go grooming” which means the conversation with the stakeholders is not happening. Criteria of acceptance are often absent or weak.
Using features as buckets to allocate development time
Since developers typically have to account for all of their work time as opposed to backlogs, developers have the motivation to create and retain a catch-all feature for the time being. This feature will remain open for a long time and may contain multiple stories that do not have meaningful narration or acceptance criteria. These generic traits make it very difficult for people inside or outside the team to really see what the team’s momentum or promised opportunity is.
To make epics or features too short
Each of the few teams I’ve worked with has a story to tell. The hierarchy of an agile backlog is quite flexible, so they can only skip the feature level if it doesn’t make sense for the team. Or, they need to make their features bigger. The one-on-one relationship of the story with the feature or feature with the epic only makes the backlog bigger and harder to maintain with extra work items that don’t pay any price.
Everything is a technical story
This can happen when development teams are working in isolation from business stakeholders. They write backlog on IT-Speak. Does not describe the user’s story, features, and epic business capabilities; They have a laundry list of IT jobs. It is almost impossible for a business stakeholder to understand the backlog or figure out how to test it. It is a symptom of a “tell us what you want, leave now and let us make it” mentality that weakens the agile heart.
This often happens when the demand outside the team spends too much time outside of the daily schedule. Something has to be given, and development has to move forward, so daily stand-up meetings are sacrificed. Team communication, solidarity and mutual accountability result in loss.
How can organizations that really want to get better quickly fight these bad habits? For Agile to be successful, it is not enough to send all your developers to 3-day Agile training and hire a Scrum Master. The parties need to be given enough autonomy to carry out the daily, weekly and bi-weekly processes that keep Agile working. They should be assisted by collaborative coaching that helps them identify opportunities for improvement without judgment or punishment for the mistakes they will inevitably make. Otherwise, companies hire people to provide oversight and management levels of smart teams, which really ends up being the same old thing that Agile was supposed to take away from us.