Chapter 10

Wrapping Up

We're at the end of our “Leading Agile Teams” journey. You started out seeing how important it is to have strong agile teams. This is especially true if you're just starting agile in your organization. The first team will be your crucial change agents. Hopefully they'll spread the word about the benefits of agile. They will talk about their work in the lunchroom and spread agile by “contagion.”

You've seen how an agile organization splits their groups into cross-functional self-organized teams. These teams are critical for creating an agile mindset. Some of the most valuable changes will come by having a cross-functional team in a shared workspace.

Each agile team should have a customer representative. In Scrum, this is typically called the product owner. This role is responsible for creating and maintaining the product backlog. They'll gather up the work and split it into user stories.

When the product owner has enough user stories, the team will start developing the product. The product owner will work with the team to get a relative estimate of effort for each story. Then they'll rank the list so that the team knows the highest-value items.

At the beginning of each sprint the development team will split the stories into Post-it notes. Each one of these notes will represent one day of work. Then they'll place the notes on a task board. The task board is a key information radiator. It will communicate how much of the work is planned, in progress, or done.

Each team will deliver in a two-week, timeboxed iteration. In Scrum these are called “sprints.” At the end of each sprint the team will have a shippable product. This is much different from a milestone or phase. It should be a functioning product.

This product should be demonstrated at the end of each sprint. The product owner is usually the best person on the team to give the demonstration. They have the closest connection to the customer. It also helps keep the product owner plugged into the team from the sprint. The public demonstration will help the team gain insights into the mind of the customer. The customer can apply these changes in close collaboration with the rest of the team.

At the end of the demonstration the team should hold a sprint retrospective. This activity is about optimizing the process. It's the team getting better at being agile.

By now all of these topics should only serve as a reminder. If you are hearing any of this information for the first time please go back through the table of contents and check out each of the related chapters.

Putting The Bell On The Cat

By now you should have a better understanding of agile processes and practices. That brings us back to where we started. How to put the bell on the cat? This book gave you a broad overview of the ideal way to transform your organization. There were quite a few “pro tips” that gave you an idea of how to put these concepts into practice.

Leading your team to greater agility means that you need to know when to push and when to compromise. There are quite a few places where you should stay as close as possible to the ideal. Try to ensure that the team has a shared workspace. Always push the team to self-organize. Make sure that the team has a dedicated product owner. Without this foundation it seems unlikely that your transformation will succeed.

Other areas are more flexible. It's not ideal to share a ScrumMaster across several teams, but it can be done. You can still be an agile team if some of your developers are offsite. It just presents a lot more challenges. Finally you can create some traditional project artifacts. Upper-level managers can get a Gantt chart and milestones. It just might take a little creative thinking.

Each of these as a single challenge shouldn't be too difficult to overcome. If you have to deal with them all at once it might be too much for your new agile effort.

When you're an agile team, try to be a “happy warrior.” In general, organizations don't like to change. Change usually means job losses and frustration. They're much more likely to get onboard when the change comes from an upbeat person. If you get frustrated or overwhelmed, it will come through in your efforts. You'll be an obstacle to your own change efforts. Try to smile and have a good sense of humor. This is a significant change. If you are happy, people will be more likely to see this as a friendly change.

Trying to stay upbeat is not easy. Change efforts are time consuming. Don't be surprised if you find yourself in the same meeting with the same people saying the same thing over and over. Leading an agile team takes a lot of patience. There are a few common challenges that you're likely to run into as part of your overall change effort.

One of the first challenges you'll run into is that people do not usually understand the role of the ScrumMaster. This role is very different from what you find in many organizations. Most managers have authority over the development team. The ScrumMaster is a new role. They are a combination of a trainer, coach, and administrator. Make sure that you repeat this consistently and often. You might be several months into your transformation effort and still have people going to the ScrumMaster to help “push” the team.

It is very common for organizations to misread the levels of authority on the team. The true roles of authority on the team are the developers and the product owner.

Another challenge is that people will generally not understand project iterations. Project milestones are pretty deeply ingrained in product delivery. Most people still think of work as divisible by time. When you have a month-long project you should be one-quarter finished by the first week and halfway finished by the second week and so on. The idea that you can start building the whole thing and then improve it over time is still pretty foreign to most organizations.

Use your team's demonstrations to clarify what it means to deliver in project iterations. Most teams have an easier time understanding iterations once they see a few of them displayed.

This leads to the final common challenge. Often the team will not get the point of the product demonstrations. Remember that the demonstrations are designed to make sure that the product owner and the customer share the same understanding about the product. When they're starting out, most teams use the demonstration to celebrate the work. They want to show the customer how much they've accomplished.

When you're leading the team, try to make sure that the product demonstrations are performed correctly. If you use them to celebrate the work it won't take long for the customers to stop attending. It's very important to have the product owner drive this event.

The key difference between a leader and a manager is the ability to get people to come around to your way of thinking. I hope this book has helped you understand what it means to be “agile.” Hopefully you now have a vision for your agile team. We have covered the key places that will likely cause you trouble when convincing others to change. Now all it takes is your knowledge, patience, and upbeat persistence. I wish you the best success in leading your agile team.