Rollout Secrets
When you’re rolling out agile to a team, your rollouts will be smoother if you get the team to buy-in, keep the focus of your rollout small, and have team members dedicated to one team:
+ Buy In
The way most leaders try and get buy in is wrong. They go on and on about the virtues of agile, or they just dictate that agile is going to happen. The most effective way to get buy in is to ask questions of the team members. Ask them what kind of future they would like to see for their team, then ask them why they haven’t created that future yet. Listen and synthesize their answers, because those answers will tell you exactly where to focus energy in the agile rollout. When teams hear how agile helps their goals, they see the value immediately.
Pro tip: I like to do 1:1 interviews. Not only do I get richer information, I also can gauge the work load of the team. If the team is too busy to do the 1:1 interviews, then they definitely need work adjustments in order to absorb agile into their ecosystem.
+ Keep It Small
Sometimes organizations want to have everyone in their group go agile, wanting to roll out the changes to their whole enterprise, even if it contains hundreds of individuals. Keep the agile rollout sane by keeping the numbers small. After working with hundreds of teams (no small feat!), I’ve found that rolling out agile works best when you keep your rollout efforts focused on two to three teams. Beyond that, you enter into mass confusion which becomes infectious across the organization, and that confusion will slow you down. The only exception is if you have a team of coaches rolling out the changes, then multiply two to three by the number of coaches. Also, keep your team size in the single digits (under ten people), that includes QA!
Pro tip: Sometimes you can’t keep the team size small. I once worked with a group of 30+ people, with only one very busy product owner (he was assigned the product owner role on top of his day job). Breaking up the large group would have meant the product owner would have been stuck in too many meetings. Getting another product owner was not an option, so we had to make it work. This meant we drastically changed the rules of the game. We held huge meetings - the daily took over 30 minutes, but we clearly articulated the order for each work stream, and they would multi-task until the team before them was up, and then they would get ready. Obviously there was a lot of waste, however, because we got out ahead of it, and explained the constraints, the team was able to adapt and stick to the principles behind agility. This vision and principle based set up allowed that team to deliver in one half the time large consulting firms said they should have delivered.
+ Dedicated Team Members
Most organizations moving to agile are used to having their people change hats all of the time, so it is not uncommon that they set up an “agile” team that has developers/team members dedicated only 50% of the time to it, or they have multiple people fulfilling the same role. :(
If you can’t get 100% commitment to a team, the organization will never get the massive gains that comes from moving to agility. I’ve worked with nondedicated team members and their commitment to the team could never be counted on, because the other groups they supported would run into issues that they needed to support. One solution to this is to ask if the other project work could be consolidated into the team backlog, and prioritized by one product owner.
If you have multiple individuals fulfilling one role, it often confuses the team - they don’t know who to go to. Also, it is not clear what happens one they disagree, and both think their item is #1? Who will break the tie? Who is the decider? Have the individuals discuss and bring their solution to the team. I’ve often seen in situations like these (its usually product owners who have multiple people assigned to one team), that the individuals realize that one person is a product owner, and the other the product manager, and it helps rebalance the work load between them.
If you are blocked from any of these items, escalate! Bring this issue to the attention of the transformation champion, because this is one of the biggest blockers to an agile team rollout, let them resolve the issue, accept it, own changing it, or mitigate the risk that comes from it.
Roles
Two things that I see derail a team agile rollout: assigning an agile role to someone who already has a “day job,” or assigning someone to a role and having them support an unsustainable amount of teams. If these issues face your team, you can help them by bringing them all together and having a quick session to discuss the responsibilities your team needs to fill.
+ Read More
Create a grid and list out all of the responsibilities by role. You can reference The Scrum Guide or Agile Teams in SAFe to help you populate the grid. Have a discussion about
1. Who “traditionally” delivers the accountabilities
2. Constraints the team faces in having that role deliver on the accountabilities
3. How your team will deliver the accountabilities
Then, have the team self select on what they will do and who will make sure it happens. Below is a snippet of a grid I use based off of The Scrum Guide.
Resources
There are many great teachers in the world of agile team development. Here are some of my favorite
+ Podcasts
The Scrum Master Toolbox Every day, Vasco Duarte brings you insightful interviews with Scrum experts, and they tackle the real challenges of today’s workplace, like how “in order to be able to help others through a change process, we need to be able to change ourselves.”
Agile Atelier Rahul Bhattacharya brings longer form interviews where luminaries from the Agile world talk about different topics in the agile world.
+ Youtube Channels
Development That Pays - Gary Straughan brings the world well produced engaging videos that teach teams Scrum, Kanban, and other agile concepts.
Lyssa Adkins - Author of Coaching Agile Teams, Lyssa gives you short, to the point coaching that will help you and your team get useful concepts (like the high performing tree).
Henrik Kniberg’s Product Ownership In A Nutshell - This video is a classic, so if you haven’t seen it yet, get ready to be inspired.
+ Blogs
Esther Derby and Diane Larsen both have blogs full of inspiration to take your team’s collaboration to the next level.