Chapter 2
IN THIS CHAPTER
Quantifying the benefits of scrum
Structuring the product owner role
Creating your product vision
Implementing the scrum master role
Following common practices
Work expands so as to fill the time available for its completion.
— PARKINSON’S LAW
Scrum is simple in concept yet often difficult in application. Changing 70 years’ worth of product development paradigm is challenging. Still, achieving 30 to 40 percent time-to-market increase and 30 to 70 percent cost savings are realistic. Jeff Sutherland, a co-creator of scrum, has documented 1,000 percent performance improvements by using scrum. Given that potential, it’s worthwhile to get out of your comfort zone and start dealing with the organizational dysfunctions that are holding you back.
If the number-one trend in IT is converting to scrum and associated agile engineering approaches (such as eXtreme Programming), it’s possible for your organization to make the transition. Many companies are making it and making it well. The process just takes an open mind — something that’s good for all of us. By the end of this chapter, you’ll be up and running with your project and ready to take the next scrum steps.
Two factors come into play as you convert to scrum:
It’s natural for people to resist change, and people resist to different degrees and in different ways. When people understand how the changes will benefit them directly, however, the conversion is faster and easier.
As you see in Parts 3 to 5 of this book, billion-dollar companies benefit from scrum, as do everyday folks. A colleague used scrum to plan, day by day, a recent vacation. He and his wife agreed that because scrum allowed the right combination of structure with freedom, the vacation was the best they’d ever had. (Chapter 17 provides additional examples of using scrum within a family.)
Consider Net Present Value 101: A dollar today is more valuable than a dollar six months from now. The biggest problem in organizations isn’t the efficiency of the tactical execution teams; it’s poor portfolio management. Executives fail to show the leadership necessary to make the tough prioritization calls, which results in too many projects being pushed down to a lower level of management that lacks the power to fight back. (See Chapter 13 for more on this dynamic.)
This dysfunction is masked by stretching people across multiple projects so that each business unit gets something. Getting everything done takes considerably longer, but the managers of each project are placated by binders of documents telling them how great their products are going to be when they eventually get them. This thrashing between projects comes at a real cost.
Scrum is the opposite. You focus, you produce deliverable tangible results, and then you increment forward. The product backlog (described in detail in Chapter 3) forces you to be effective before worrying about efficiency.
Your organization may be a billion-dollar company or a mom-and-pop store struggling to get a great idea to market. Maybe you’re one of a gazillion employees, and you’ve been given this one project to prove yourself. In each case, disciplined prioritization, increased efficiency, and incremental tested progress can help you survive.
Because of the prioritization within scrum, you’re working exclusively on the highest-value features. You’re not perfecting a third-tier widget instead of a high-value feature. You’re going for the meat every time. As a result, what you produce during each sprint is what’s most important, practical, and immediately desirable. In every release, you have something that the marketplace values. That’s scrum. That’s showing you the money.
Fortunately, scrum is built around delivering tested, usable results early and often. You don’t wait to see results. You see them after every sprint.
Try this approach for yourself. Ask yourself or your customer, “If we had only one month to deliver value to the marketplace, what would we build, and how?” See how taking this incremental approach brings value to the forefront?
Ever heard that? Three-year-old preschoolers aren’t the only people who say it; bosses and colleagues also demand “I want it now,” or you may even hear that inner voice within your own head saying it. Scrum makes it more possible to see immediate results. scrum projects regularly see less than a 30–40 percent time-to-market. But how?
The answer is simple: Start development early and thereby end development early. You’re creating shippable products from the start. You don’t wait for months or years for results that may have passed their technological sell-by date. You quickly plan, create, inspect, adapt, ship, and benefit. In this process, you churn out value early and continuously.
That’s not the only reason why you want to experience increased speed to market. As you create your product backlog (the project to-do list), you order and prioritize the items. In prioritization, you take two things into consideration:
Both factors get to the top of the list.
Most people don’t know what they want, at least not until they interact with it. The majority of people, companies, and organizations realize what they want only when they interact with the product or service directly. The gap is the difference between waterfall (seeing it in documents) and scrum (using it).
In your roadmap to value (see Chapter 1), you begin with a vision of what you want your product to be. This vision acts as a beacon for your team, the way that any established destination acts as a beacon. The roadmap allows for the natural progression of decision-making, from large fuzzy generalities down to small specific operationalization of that goal. The vision provides the outer boundary of what can change. If resulting product deviates from the vision, it’s a different project.
Scrum enables you to build out a successful business no matter what that business is. For example,
How these ideas would pan out in reality is yet to be determined. The good news is that you develop the most effective path of progress through the scrum framework. The process of tangible creation, inspection, and adaptation gives you the tools to create the product that’s needed.
Each item that the development team completes is tested and integrated to ensure that it works. The product owner is responsible for either accepting or rejecting each requirement as it’s completed. In other words, if something doesn’t work, it doesn’t make it out of the sprint.
Issues can come up with enterprise integration, load limits, and so on after a product makes it into production, of course. But the feedback cycle is so strong during development that as soon as a defect or process inefficiency is spotted, it can be corrected. The problem is fixed in that sprint or placed back in the product backlog to be prioritized against future work.
When people see the success and value of scrum, using it becomes easier. Employees discover that scrum improves communication and collaboration, creates esprit de corps, has a natural life cycle, develops an honest and transparent environment, and increases ownership and empowerment, all of which affects company culture in a hugely positive way.
The level of resistance to change varies from company culture to culture. The solution, as with so many things, is tangible success. (You’ll find no defense against demonstrated success!) Find what the key people need — increased profits, higher product quality, faster delivery, or improved talent retention — and show them how the scrum model delivers.
In any group of people, you’ll find the influencers — the ones with clout who can get change rolling. Maybe you’re an influencer, or maybe someone else is. Get that person on board (which may mean going to higher management), and your job will be easier.
Involvement begets commitment. You want to build a team that can move the gears of change. The key to moving the gears of change is the product owner.
The product owner’s primary job is to take care of the business side of the project. This person is responsible for maximizing product value by delivering return on investment (ROI) to the organization. The product owner is one person, not a committee, and is a full-time, dedicated member of the scrum team. This person doesn’t own the product but takes ownership of the business-side duties, representing the stakeholders and customers.
Some of the primary responsibilities of the product owner are as follows:
We’re often shocked that organizations that plan to pour millions of dollars into a project say they don’t have the resources for a dedicated product owner to ensure that the business and technical priorities align and that the product created is the product needed. Yet many of these organizations have a project manager to direct the project. Because the project manager role doesn’t exist in scrum (relevant duties are part of the three scrum roles; see Chapter 1), the money for product owners can be taken from there.
Product owners clarify, prioritize, and set an environment for focus. They ensure that the scrum team is effective. The product owner determines what requirements are pursued and when work shifts to those requirements — that is, what and when but not how or how much. How and how much is the responsibility of the development team.
Imagine that your passion is building something. In scrum, you’d be a member of the development team. For you, the product owner is a gift. This person excels in portfolio management because he or she is empowered to make decisions, clarify, prioritize, and fight to ensure that team members focus on one project at a time. Because of effective product owners, development team members are freed from distractions and can spend more of their attention on getting their jobs done.
Both the product owner and the scrum master work to create the best environment possible for the development team to do the highest-quality work it can. The product owner handles and deflects business concerns and noise, and the scrum master ensures that other organizational interruptions don’t affect the development team.
The abstraction layer created by the product owner and scrum master doesn’t mean less business noise. It means that for the most part, the development team doesn’t have to deal with the noise.
On the other hand, development team members can contact stakeholders or other team or nonteam people directly when they need clarification on something they’re working on. This model of filtering prioritization but not clarification is like the membrane of a cell that’s designed to let certain fluids travel in one direction but not the other.
The result is that the development team is protected from outside interferences but not hindered in their quest for knowledge. These boundaries are important and integral to the successful functioning of the development team.
Product owners love scrum for the following reasons:
A scrum product owner’s role is much different from a traditional project manager’s role. Imagine telling a golfer to hit the ball 400 yards and straight into the hole and also telling him that he’ll be hit with his own club if he doesn’t succeed. The traditional IT world works that way. With scrum, the golfer hits the ball, assesses the results, and adapts to achieve the goal in the best possible way given where he is, not where he should be.
Vision statements aren’t part of the scrum model, but vision statements are useful and widely adopted. Companies, not-for-profit organizations, and individuals often use vision statements.
Vision statements are so useful that we’ve made them Stage 1 in our roadmap to value (see Figure 2-1). Think of your vision statement as a destination with a beacon. You may have 100 ways to get to the destination, and it doesn’t matter which way you take; the point is to end there. With this beacon of a statement, you always know where you’re headed because you have the goal in sight. From this stable, strategic destination, you have limitless tactical flexibility.
FIGURE 2-1: The vision statement is Stage 1 of the roadmap to value.
A vision statement is
In his excellent book Crossing the Chasm (Collins Business Essentials), Geoffrey Moore recommends an effective method for creating your vision statement. We use this model often, with first-rate results.
The entire statement should be no longer than two or three sentences. Moore recommends this model:
We recommend adding this conclusion:
Here are examples of what this format looks like in real life:
The vision statement is created and owned by the product owner and is integral to the business side of the project. One mind, however, is just that: one mind. The product owner may own this statement, but she’ll surely have better luck creating and refining it by using collective intelligence. To this end, the product owner can choose to receive input from development team members, the scrum master, external or internal stakeholders, and even users themselves. What to do with input is the product owner’s choice and the product owner’s responsibility.
When product owners are open to input from others, the product owner may become aware of nuances, features, and market angles that one person alone wouldn’t think of. The product owner may be wise to take feedback and then carefully filter it through her own understanding of the project.
In The New One Minute Manager (William Morrow), Kenneth Blanchard and Spencer Johnson describe how some of the most effective managers he studied lacked the technical skills that their employees had. Oddly enough, they also had a lot of time on their hands. If they couldn’t do the job themselves, what were these managers good at?
The managers were able to clear the path so that their employees could get the work done, which is the role of the scrum master. Whereas product owner is a directing role, scrum master is an enabling role. The scrum master is responsible for the environment for success.
The scrum master’s most important trait, after deep expertise in scrum, is clout. Diplomacy, communication skills, and ability to manage up are all good qualities, but the scrum master also needs to have the respect and clout to get difficult situations resolved. Where clout comes from — expertise, longevity, charisma, association — doesn’t matter, because it works in the scrum master role.
As a servant leader, the scrum master teaches, encourages, removes tactical impediments, and most importantly, removes strategic impediments so that the tactical ones don’t reappear. As with every other role, the scrum master is best full-time and solely dedicated to the scrum master job, especially with new teams, projects, and organizations.
In our experience, developers who double as scrum masters and scrum masters thrashed across multiple teams throw off a team’s ability to extrapolate past performance to future capability. This situation introduces availability variation and delivers inferior protection to a development team, which rarely makes sense quantitatively because a minor improvement in a scrum team’s velocity (see Chapter 4) often has a huge effect on the bottom line. If your team can schedule its organizational interruptions and is so mature that it can’t improve further, contact us; we want to write a book about you.
Like every other role, the scrum master should be a full-time role, and the person who holds it should be solely dedicated to that job, especially for new teams, projects, and organizations.
In addition to coaching the team on how to play scrum, the scrum master facilitates the events: sprint planning meetings, daily scrums, sprint reviews, and sprint retrospectives.
A scrum team is a bunch of intelligent, engaged people with a high degree of ownership in the work that they’re doing. Put these folks in a meeting together, and the creative energy may cause them to explode — or at least go off on a lot of tangents. The scrum master’s role is to focus this energy.
The scrum master’s influence extends to everyone involved, including stakeholders and product owners. The scrum master is a coach to everyone because everyone needs ongoing education and smooth facilitation in scrum.
As the scrum master shields the development team from external interference, the velocity of the team increases dramatically. Think about how well you work when the door’s shut, the phone’s off, and everybody’s away or asleep versus when you’re fielding constant interruptions from colleagues, family members, and even the dog.
Even when outside interference is kept to a minimum, because social density is higher in scrum, it’s not unusual for conflict to also be higher. The pressure to get products working in short sprint windows can be wearing, so the scrum master’s job entails managing conflict to the right level. Task conflict (being willing to fight for what you think is right) is healthy. Personal conflict (challenging someone personally) is not.
The concept of servant leader dates to around 500 BCE and was developed by Lao Tzu, who is thought to be the author of the Tao Te Ching. Yet this concept is mentioned in every major religion and is popular in modern-day corporate leadership models. That’s staying power.
The servant leader puts others first so that they can do their jobs. The leader enables people rather than presenting the solution on a silver plate. If someone says, “I’m hungry,” the servant leader doesn’t hand him a fish. Rather, the leader asks, “How can I help you so that you’re not hungry today, tomorrow, or next year?” The scrum master helps each person build skills and find the solution that works best for that person, whether the answer lies inside or outside the project.
As a servant leader, a scrum master teaches, encourages, removes tactical impediments, and removes strategic impediments so that tactical impediments don’t reappear.
Scrum masters love scrum for many reasons, including these:
Product owner and scrum master are scrum roles created by the founders of scrum and these roles integral to any scrum project. Another role is development team member (see Chapter 4). But like all good things, project management is evolving and growing. Scrum remains a solid framework and foundation. Some common and proven practices can add value.
The following two roles aren’t scrum, but we’ve found that they add enormous value and clarity when approached properly. Consider adding these roles to your project; they may add value to your scrum endeavor.
Stakeholders are people who affect or are affected by your project. Internal stakeholders are within your company or organization; they could be from the legal, sales, marketing, management, procurement, or any other division of your company. External stakeholders could be investors or users.
Two roles deal with stakeholders:
The key to interacting successfully with stakeholders is to recognize and leverage stakeholders’ influence while shielding the development team from any interference.
As we’ve said, scrum is a simple framework in concept but complex in practice. The same can be said of golf. Theoretically, you use a stick to whack a motionless white ball into a hole, using the fewest strokes possible. Yet in practice, golf isn’t easy. Like scrum, it’s a game of nuance. Small factors make an enormous difference in performance.
The mentor, sometimes called a scrum coach, will work alongside the team to help them develop maturity in practicing scrum. The benefit of using a mentor is that mentors are outside of the normal politics and focus on getting the product out the door. They can step back and see objectively watch how the team works. They can not only identify old habits, but also put the brakes on homemade modifications to scrum that are simply ways to let an old dog do its old tricks.
You’ll have the greatest ease and success with scrum if you stick to it in its truest form. A scrum mentor’s job is to help team members keep good form. Like athletic coaches, they stand aside; see old, unproductive habits; and help you form new habits that make you successful.