Five Common Frustrations with Agile
It is a well-documented fact that I love Agile. I blog about it, write books about it, make my kids do their chores in an Agile way… But the realities of an Agile implementation are often full of struggles and angst.
In this blog, we will address the 5 Common Frustrations of Agile teams with some tips on how to avoid.
Great Idea Syndrome or Critical Client Request
These are the ideas that come up, usually from the executive team, that can disrupt a sprint in progress. What can you do?
- Have the Product Owner be the ‘interceptor’ and immediately begin flushing out requirements without involving the developers.
- Be very transparent with the Executives about the current work in progress and its priority. Sometimes that will diffuse the urgency of the new request.
- If it keeps happening, create a Kanban team (or just identify a single developer) that doesn’t have commitments in the current sprint that can take the one-off requests without bothering the dedicated developers.
Commitments aren’t honored
The sprint comes to an end and tickets/tasks/stories just roll to the next sprint. This is often accompanied by loads of excuses but it is demoralizing for the team and devalues the entire Agile process. What can you do?
- Work on the definition of done. Does “done” mean tested and ready to deploy? (It should). If so, you might not be leaving enough time for QA so you might have to back up the ‘code complete’ timeline.
- Remove distractions and disruptions. If the team is getting hit with new work, then that needs to be removed (see above).
- Make sure the team understands and agrees to what ‘commitment’ means. This might start with a working agreement. Often, they aren’t aware that making a commitment means you will get it done. If they think it is okay for a story or task to roll to the next sprint, then something is missing in the interpretation of Agile and its commitments.
- Check your estimating. One of the biggest problems associated with missing sprint commitments is the underestimation of how long it will take to finish a story. This is very common with Scrum teams so it is just something you work to continuously improve. Some sprints will be better than others, but taking the time to learn from and refine estimation problems will definitely help in making future commitments.
Problem Team Members
Sometimes a bully or a non-Agile-person is put on a scrum team and they are very destructive to the team dynamic. What can you do?
- Let the team handle it. The ideal situation is for the team member’s bad behavior to be called out in a Retrospective. The pressure applied by the team can be far more powerful than a ‘management discussion.’
- The manager has to manage. Personnel issues that cannot be worked out within the team must be dealt with by management. That is why we have management. The manager of the team has to be willing to have an honest and developmental conversation with the person about how their behavior is negatively impacting the team and they should agree on the proactive steps that the employee will take to resolve it.
- Find the team member a new role. Let’s be honest, there are some people who are not a good fit for Scrum teams (more on this below). Some people just aren’t team players. If they can’t recognize the value of actively participating on a high functioning team, then move them out. Perhaps they can be an individual contributor in the organization or perhaps they need to find a role outside the company. Either way, the team should not be forced to suffer endlessly with a team member who will never see the light.
Interruption-driven (emergency-focused) Team Members mess up team commitments
Have you ever worked with someone who seems like they are actually looking for a crisis to jump in and solve? These people are hard to work with on Scrum teams. What can you do?
- Move them to a Kanban team – there are just some people who are hard-wired to solve an immediate crisis. They like to ‘fight fires’ and working on committed development work for several days just isn’t appealing to them. And that’s okay. But not on a Scrum team. Move these folks into a Kanban team where they can jump in and solve the hottest priority item that comes up. This will likely be a great service to the Scrum team because then those fires don’t disrupt the sprinted work in progress.
- Don’t let them commit. If you can’t remove them from the team altogether, then don’t let them make commitments because they aren’t going to honor them anyway, despite their best intentions. Have them serve as architects/design consultants for the developers who do have commitments and they can help, as they have time, mentor and guide less senior developers – when they aren’t actively putting out a fire.
- Find a way to recognize them. These people like to be seen as the ‘hero’ who swoops in and saves the day. Different people are motivated in different ways, so it is worth taking a moment to recognize the efforts of these folks. It really means a lot to them to be seen as valuable.
Day-to-Day / Maintenance /Break-fix work is getting put onto the Scrum team
This is a real world problem. While we are working on a great new feature, the business is still running and our current clients are having problems or bumping into some problematic code. What can you do?
- Separate teams. The cleanest way to solve this problem is to create two teams. The scrum team works on commitments to be delivered within the timeline of a sprint. A Kanban team takes the support tickets and works them in priority order.
- Separate individual. See the interruption-driven team member as described above. You can have a person like this remain on the team and just not take on any commitments. They can work the support tickets as they come in, but still participate in the Scrum ceremonies and feel like they are part of the team.
- Rotating individual. Sometimes the ongoing pace of participating on a scrum team can be a little exhausting. It might be a nice variety to have different people own the support role for a sprint or two.
- Do not spread the support work across the team. It is important to have a specific individual assigned to take the maintenance or support work. Do not allocate 10-20% of each developer’s time for support tickets. That almost never works.
Agile is wonderful but it doesn’t solve all of our problems – there is no magic pill. Hopefully these tips and tricks for real life are helpful. Like all relationships and processes, your Agile implementation will have to be cared for and tweaked as your company and your people grow. There is always a new challenge that will come along and Agile will provide us with the tools and principles to handle it with ease.