Building Better Software

“Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used.”

– Jim Highsmith, Agile Project Management: Creating Innovative Products (2nd ed.)

The board game Othello has the slogan, “A minute to learn, a lifetime to master.” This applies really well to a team that’s learning Scrum. The basic practices and mechanics of Scrum are straightforward, and not difficult to adopt. This is why many teams use Scrum as a starting point for going agile.

The basic pattern for a Scrum project is simple, which makes it very attractive for teams who want to go agile. And if that were all it took to adopt Scum effectively, we’d all be running great agile teams! But many teams find that they run into trouble with their Scrum adoption, and usually end up with what feels like an “empty” implementation. We explore this in our new talk, Scrum and Self-Organizing Teams: Openness, Courage, Pigs, and Chickens [pdf].

For a Scrum team to become effective, they need to do more than just follow the basic Scrum pattern. Effective Scrum teams are self-organizing, as Ken Schwaber explains (note the phrase that we emphasized):

For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.

– Ken Schwaber, Agile Project Management with Scrum

The goal of this talk is to help teams “get Scrum” by building on the practices and patterns of Scrum, and through those practices show the ideas behind the principles of collective commitment and self-organization.

In Agile Project Management with Scrum, Ken Schwaber introduced five Scrum values: courage, commitment, respect, focus, and openness. Understanding these values is an important key to understanding self-organizing teams.

• Each person is committed to the project’s goals. That level of commitment can be achieved when the team has the authority to make decisions in order to meet those goals, and everyone has a say in how the project is planned and executed. For example, sometimes a requirements document isn’t perfect. To make the project successful, a team might have to ignore a documented requirement in order to deliver a product that’s much more valuable. This is only possible once they’re given the authority to make that decision.
• Team members respect each other. When team members have mutual respect, they’re able to trust each other to do a good job with the work they’ve taken on. But that respect doesn’t always come easily to programmers and other technical people. Many programmers, especially highly skilled ones, often base their respect purely on technical ability. This can be a barrier to effective Scrum adoption. If a programmer doesn’t respect the product owner, he won’t listen to that product owner when they talk about the goals of the project.
• Everyone is focused on the work. When a Scrum team member is working on a sprint, that’s his only job for the duration of the sprint. He is free to do whatever work is needed to complete the iteration backlog, and handle any changes that are made to that backlog during the sprint. When every team member is focused on the sprint goals and given the freedom to do whatever work is needed to meet those goals, the whole team is able to organize itself and easily redirect whenever a change is needed.
• Openness. When you’re working on a Scrum team, everyone else on the team should always be aware of what you’re working on and how it moves the project towards its current goals. Many of the Scrum practices are aimed at encouraging openness among the team members. Task boards, for example, allow everyone to see all of the work being done by each team member, and how much work is left to do. Burn-down charts let each person gauge for themselves how quickly the sprint is meeting its iteration goals. The Daily Scrum, when done effectively, is a almost pure exercise in openness, because each person lays bare their tasks, challenges, and progress for the whole team to see. All of these things can help the team to create an atmosphere of mutual support and encouragement.
• Team members have the courage to stand up for the project. When you choose openness over opaqueness, you make the team stronger rather than making yourself stronger at the expense of the team. It takes courage to do that, but when you do you end up with a better product and a better work environment. Scrum teams have the courage to live by values and principles that benefit the project. It takes courage to ward off the constant pushback from a company whose values clash with the Scrum and agile values. This requires vigilance on the part of every team member, especially the Scrum Master. But it also requires each person to be willing to trust that delivering valuable software will help them overcome resistance to these values. This requires courage too, especially when it comes time to sit down for a review with the boss. It takes courage to say to yourself, “Helping this team produce valuable software is more important to me that how the company sees my own personal contribution.”

Methodologies have built-in values

Every company has its own culture that includes specific values. For example, some companies value separation of duties, where each person has their specific role to play, and is protected from having to be accountable for things that they can’t easily influence or control. Other companies value transparency, where information is shared freely and even low-level employees can influence management decisions. Neither of these is the “right” way to run a company. Every individual company has a culture that evolves over time, based on the way it’s managed and the decisions that are made.

Every methodology has values built into it. Specific agile principles are often tied to (or implemented by) individual practices, and that those practices are an effective way for a team to bring each principle to the project. A team in a company that reserves decision-making for managers only will find it difficult to truly commit to projects. The same goes for any value or principle: if they clash with the company’s values, it presents a barrier to adoption.

But in a company where the culture matches the agile values and principles, an agile team will be much more successful than a command-and-control team. (This is one of the sources of the “astonishing results” that some agile teams report.)

You might be surprised at just how well the agile values and principles match your company’s culture. A good first step in introducing agile to your company is to talk about the values, and how they might impact your company’s culture. If you find that your agile adoption runs into trouble, finding the mismatch between agile values and company culture can help you smooth out the transition (or at least help you feel better by understanding why things went wrong).

So how would you build courage on a team? How would you get a team to believe in themselves, and believe that Scrum will not only help them build more valuable software, but that they company will see the value in their new methodology?