Understanding the grey area between your team’s past, present, and future in a time of agile transformation.
We are your new agile team. We’ve attended the training, read the books and blog posts, listened to the podcasts. We get what Agile is. We understand the power of agile. We are bought in. That isn’t the reason we are frustrated.
We’re frustrated, because we haven’t found that ideal state just yet. And because, when we’re playing a game of inches, we keep being told that we should be miles down the road.
This is the refrain I hear from people in my organization struggling with our transition to agile. They’re tired of being told about the utopia. They’re tired of having their questions answered with more questions. They just want to know how can I make tomorrow 1% better, and they’re not getting any answers.
I think there are a few things that scrum masters and agilists can do to address this discontent.
- Stop assuming we hate agile
- Stop assuming we don’t know how it works
- Practice what you preach - focus on small, incremental change
- Walk a mile, get in the trench, carry the load
I think it’s very easy to assume that when a team member has input on the agile process that they are basing their critique on a ‘broken’ process they’ve lived in for years.
While I think that is probably a valid assumption, especially for scrum masters who have their own history with their company, it’s not especially helpful. Even though the old system might be all your new team knows, it doesn’t mean they don’t understand the benefits of agile, or that they can’t be bought in.
I challenge scrum masters and agilists to change their perspective, and assume that their team is eager and excited about the possibilities of agile. You don’t need to tell them about the current system is broken to convince them.
What you do need to do is help shepherd them from the old world to the new.
More than Capable
One of the key benefits of Scrum is that it is incredibly accessible in its concepts. The scrum guide is just a few pages long, and it’s core guidelines are short and simple.
Anyone on your agile team should be able to pick up the core concepts very quickly. Focus on coaching early to lay the foundation of understanding, then stop referring directly back to the Scrum Guide.
Instead of re-iterating the core tenants of agile, focus on interpreting these guidelines for your team and their unique situation. You can remind them that we are following a guide, but don’t just quote the Scrum Guide like scripture. We get it.
An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
We understand the vision. We understand the goal. Now, help us build an increment.
That is the request from your agile team. They understand the destination, but they’re trying to take their first step. Stop telling them how it should be and start helping them get there.
Think back on your experience managing people and teams. Think less about the structure of agile, and more about how you can get people to work together for a common goal. How you can free them of their restraints or roadblocks to completing their incremental goals.
Focus on the next sprint. Keep track of what you did, and the results of your change. Keep your sprint changes small and targeted. Just like your team is building towards an empirical, demonstrable increment, so should you.
I like the concept of the Scrum Master facilitating scrum-related increments for team improvement. Hold yourself and your team accountable with your own simplified Kanban that tracks progress sprint-to-sprint.
|2||Assign names to tasks.|
|3||Demo to UX on Tuesdays.|
Allow your team to see how much they have improved, and highlight repeated issues that you are struggling to resolve.
In the end, the goal is to make progress, one small step at a time.
Walk a Mile
Put yourself in your team’s shoes. Think about the role of a developer. Think about their management structure, their goals, their focus as a practitioner. Do the same for testers, user experience, and the rest of your team. Why might they be faltering in the context of your squad.
This is crucial to understanding the frustration you might be seeing on your team. You’ll never be able to help them if you don’t understand the tension they feel in their role when adopting a new methodology.
You might also be expected to contribute in a concrete way. When your team is focused on delivering they might forget to work on improving their agile practice. They might forget to put a story on the board, or add a distraction.
I think the expectation of the scrum master is that you need to step up and fill that vacuum. Not by just writing up tasks for people, but by helping them see their gaps. By holding people accountable. And, most importantly, by helping them reflect on their progress and continue making incremental improvements.
So just make sure, if you can be committed to your team and help them pick up the slack - do it. If that’s something you can’t do for whatever reason, do everything you can to give them the tools to do it themselves. This could be something as simple as a pile of post its and markers easily available or a team whiteboard to promote collaboration. Just make it happen.
The truth is, it’s not going to be easy. That’s another thing you have to always keep in mind. You’re doing a challenging but admirable task.
You’re not always going to know the right thing to do, but if you focus on what you can accomplish in the next day or week - and you are honest with your team about that incremental change, you’ll be better situated to make a real difference.