Mark Noneman

I often get this question when coaching or training organizations new to Scrum: “I’m a project manager. What do I do?” I’m happy when I get the question; it gives me the opportunity to talk it through. Too many times, people assume or jump to the conclusion that the role of project manager must be the Scrum Master in the Scrum framework. Maybe it’s because they kind of know what a Product Owner does. The role has the word “product” in it anyway and we know what the product is—sort of. And everyone knows what a “developer” is—or at least they think they do. But what is this crazy term: Scrum Master? They know they have “project managers” and Scrum Master is new an unfamiliar so, obviously, the Scrum Master is a project manager, right? Wrong! For whatever reasons people believe the Scrum Master to be a project manager, they couldn’t be much further from the truth. From the Scrum Guide: The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. Most Scrum-knowledgeable people would also say the Scrum Master “removes impediments.” Which is true although she may do so by coaching the Development Team or Product Owner on how they could remove the impediment themselves. If we’re able to move forward again, we’ve adhered to the intent of the Scrum framework. Contrast this description with the role of project manager. To do that, I often ask groups to list the activities of a project manager. After learning about the roles in the Scrum framework, we then go through those activities and decide which role in Scrum might be responsible for that activity, based on the definition of Scrum. Here’s an example of one such exercise: (By the way, “mgmt” means “management.”) Of course, your list of project manager activities may differ. I’ve found each organization has their own. In this image, PO stands for Product Owner, DT for Development Team, and SM for Scrum Master. Notice the Scrum Master has little, if anything, to do with traditional project manager activities! Nevertheless, at least 80% of the activities people typically identify as “project manager stuff” are performed (although sometimes differently) by one or more roles in Scrum. So, what about the other 20%? Maybe you need a project manager for that. I don’t know. Sometimes, those activities are specific to waterfall development and may no longer be needed. Or maybe they’re needed for now but may be modified or eliminated as the organization matures in its use of Scrum. So back to the original questions: “I’m a project manager. What do I do?” The answer is: How can you best contribute to the goals of the organizations. Groups don’t (or at least, shouldn’t) adopt Scrum for Scrum’s-sake. People adopt Scrum to improve business agility—their ability to quickly and effectively respond to changes in their environment. So how can you contribute to that? That’s when the discussion gets interesting.

In part 1 of this blog, we looked at what software inventory is and why it's problematic for business. Basically, software inventory is investment we have made (salary, taxes, benefits, servers, overhead, etc.) for which we are not yet realizing return or benefit (which can only be achieved by release to production use). Inventory is a problem because it ties up capital and we risk the inventory becoming "obsolete"--the user needs change or the technology no longer provides the desired value--producing less return than expected Let's look at how agile development and delivery affect software inventory, and even business return. The purpose of agile development is to increase business agility: the ability to quickly and nimbly take advantage of business opportunities as they arise. Or, as Craig Larman likes to say, "To turn on a dime for a dime." As noted in the first paragraph, the only way to realize business benefit through software development is to get the software into production use. The development team being "done" produces nothing of value until it is used by the customer. Until then, it's still inventory. Traditional development often takes years to deliver into production. Look at Figure 1. It shows a baseline return on investment for a one year release frequency. Figure 1. The return on investment and software inventory for a one year release frequency. The positive vertical axis represents benefit or return from the software; that is, income. The negative vertical axis represents the cost or investment to develop and deliver the software. For simplicity, these figures use "first order" analysis. In other words, straight lines. Of course, real investment and return would be look more complicated over time. Nevertheless, this simplification makes understanding the concepts easier. (You can certainly replace the straight-line return with a more realistic S-curve; I'll leave that as an exercise for the reader.) Notice the red line, representing the investment, continues at a steady pace as the organization develops the software. At the one year point, the software is released and begins accruing return (the dashed yellow line). Development continues toward another release a year after that. Adding the return line and the investment line together (the solid yellow line) shows when the software return has paid for all the investment. When the solid yellow line crosses zero, we have achieved the break-even point; from that point onward, we have paid for all the development to date and can begin reaping net profit. In Figure 1, all of the investment up to the first year is inventory. Let's say your organization invests $1 million per year in development and delivery of software (not a very big organization!). Your peak inventory is about $1 million. In the second year, the inventory is the same. After break-even, the investment toward the next release is still inventory even if the software is now profitable. Let's say after reading this blog, you've begun adopting agile practices and worked hard to release software more frequently. Now you're able to release quarterly instead of annually. Figure 2 adds the curves for quarterly releases. The dashed green line begins accruing return after only one quarter and keeps adding more return every quarterly release. Again, for simplicity we have shown each quarterly release delivering one quarter of the value of an annual release. In a mature agile organization, we would focus on the most valuable features first and continue discovering what is most valuable each release. In other words, a truly agile organization would deliver more than one-quarter of the value and would continue discovering higher value to deliver; taking advantage of business agility. Figure 2. The return on vestment for quarterly releases showing faster break-even and dramatically lower software inventory. The solid green line represents the sum of the return and the investment showing a break-even point much earlier than annual releases. That is, agile organizations reach profitability earlier! Of course, the peak inventory for quarterly releases is one-fourth of the annual releases; in our case, $250,000. Thereby tying up much less capital that can be used for other things ... like other new products, perhaps? And of course, our risk of obsolescence is reduced by getting production software into the users hands faster. Software inventory has an important impact on the financials of any organization developing software. Agile organizations release software more frequently, reduce their software inventory thereby freeing capital for other uses, and reduce the risk of users’ needs or technology expectations changing before the software generates the hoped-for returns. Be agile, release more frequently!

How Much Software Inventory Do You Have? When I ask this question of people in IT departments, even among senior managers and finance people, I get a variety of responses.

In the Professional Scrum Product Owner course, we teach that high performing Product Owners are entrepreneurial. They not only act with the business in mind, they have the authority to make important decisions. What should we do now versus later? What choices give us the best return on investment? What’s the ROI if we do this feature later instead of now? Not only do they have authority to decide the sequence of the work, entrepreneurial Product Owners should be responsible for how much money is invested in their product. Even influencing the portfolio decisions of the relative investment in their product in the context of the overall business strategy. To make those decisions of when to implement which features, Don Reinertsen in his book The Principles of Product Development Flow recommends that these decisions be made in the context of a common measure. Specifically, what is the impact on lifecycle profit (for for-profit companies, anyway) of deciding to implement this feature now instead of that one? Wait…lifecycle? You mean, the entire business life of the product? How long is that? For most of the Product Owners I work with, their products or systems last many years, even decades. Meanwhile, most Product Owners fulfill their role for a few years at most before moving on to other things. So in that context, the Product Owner is really a steward of the product. Making decisions today that will impact not only the rest of the lifecycle of the product but of future Product Owners as well. In fact, most Product Owners are not the first. They are living with decisions made by Product Owners past, sometimes seriously bad decisions that those Product Owners are no longer dealing with…but their successors are! This concept of Product Steward applies not only to lifecycle profit but to other decisions as well. Should we release now even though we know we have taken important shortcuts in development? Should we mortgage our future selves and future Product Stewards with the technical debt we have incurred to “just release it”? Even though we have the best of intentions to fix it later…do we really believe we’ll ever get to it? Since when do we have spare time to repay technical debt when all those new feature requests are calling to us? So next time you’re faced with those hard decisions, Product Stewards, think about your future and those future Product Stewards that will have to deal with the choices you make today. A steward of the product will do what’s right for the long run. After all, you owe it to yourself.

When all you have is a hammer, everything looks like a nail! Huh? I don’t know; it’s something my father always said. I think he meant that if you don’t have the right tool for the job, you’ll use the tool you have. And if it’s the wrong tool, the job will suffer. Agile frameworks are tools of a sort. You might say that Scrum is like a wrench—requiring many turns to deliver the end result. Perhaps Kanban is like a hammer—delivering each bit and moving on to the next. Maybe waterfall is like a shovel—you know, you can use it to dig yourself a deep hole! Now I suppose it’s possible to put in a nail with a wrench (okay, I admit it, I’ve done it!). Perhaps you could even use a hammer for some kinds of bolts. In either case, the results won’t be pretty. (I’ll let you decide about the shovel.) But from an agile framework perspective, what does a nail look like…or a bolt for that matter? Kanban is a framework to focus on the flow of work. When the influx of work is highly variable and unknowable while the work itself has a definite pattern, Kanban may be a good choice. (Kind of like hammering in nails.) Examples of work for which Kanban may be the best tool for the job: IT Operations: “Tickets” come in at a variable rate and the priority of the work is also highly variable (e.g., new user account request compared to patching a server operating system compared to a server crash). Each type of request has a similar workflow. Results are often delivered back directly to the requestor. Software maintenance (also known as “sustainment”): Users report production defects, request changes in production configuration, or need modification of centrally administered data. Again, requests come in at a variable rate and the priority of the work is highly variable. Results may be delivered in a small software release or patch. (Non-IT example) Staffing: New openings occur randomly but typically in bursts. Applicants pass through a relatively regular work flow for each open position and need to be tracked through to closure (rejection of the applicant or acceptance of an offer). Kanban comes from lean principles, relying on high quality as the primary focus and continuous improvement (Kaizen) through experimentation to constantly improve responsiveness in the flow of work. Scrum is a framework designed to develop new, valuable products. Teams work in very small batches (less than 30 days’ worth…usually just 2 weeks) to develop something valuable, get feedback on what’s been developed, and use that feedback to determine what to do next. (That’s the inspect-and-adapt feedback loop.) Sort of like using a wrench on a bolt, I suppose. Examples of work for which Scrum may be the best tool for the job: Software development: Developing a new software product or enhancing an existing one where users (or proxies thereof) are available to discuss their needs and provide feedback on bits of functionality. Getting the functionality right often involves iteratively and incrementally developing it using feedback on what works and what doesn’t. Marketing: The development of marketing materials and campaigns also works best by iteratively and incrementally developing ideas and testing them with potential customers. Feedback (through focus groups, studies, A/B testing) helps to determine the most successful marketing approaches and allows abandoning approaches that don’t work. Creative writing: Writing novels or screenplays proceeds in an iterative and incremental approach as well. Characters and scenes are written, reviewed, and re-written, sometimes adding or deleting entire scenes as the story develops. Scrum is built on lean principles, too. Using empiricism continuously evaluates the work as it’s developed and using that evaluation to guide the next steps. The same approach is used to improve the process of doing the work. Constantly evaluating what practices, tools, and skills are working and improving those that aren’t. Finally, waterfall may be a good fit when the work is highly predictable with very low variability. If you can get consistent outputs given a set of inputs and the application of known work steps, waterfall may be a reasonable choice. Kind of like digging a hole with a shovel. The construction industry successfully uses waterfall methods to build housing developments and office complexes. [Note that manufacturing (which is highly predictable and has low variability) abandoned waterfall methods in favor of lean approaches starting in the 1950s!] When working to solve business problems, it’s best to use the right tool for the job. In companies that use and develop software, both Scrum and Kanban may be appropriate tools. If you need to respond to requests with high quality and fast response, Kanban may be a good choice. If you need to develop new, valuable, quality applications, Scrum is the best tool for the job. Choose the right tool and the results will follow.

[Author’s note: I will be a Scrum Day Dallas on 27 March 2015; a great opportunity to meet me and other master Scrum Masters. Find me there and let’s talk about your Scrum Master journey. Exciting travels –Mark Noneman] So you’re a Scrum Master now. Maybe you’ve volunteered to fulfill the role or maybe you’ve taken a Scrum Master class. Now what? The apprenticeship system is a useful reference. In apprenticeship, one studies under a “master.” (Unfortunately, the terminology conflicts with the Scrum Master name but we’re stuck with it; I’ll use upper-case Scrum Master when referring to the role, lower-case master when referring to the highest level of expertise.) The apprentice learns the basic skills of the job until they are proficient enough to work on their own under normal circumstances. At this point they have achieved the journeyman level of competence. A master teaches apprentices and journeyman and can handle the most difficult situations. To continue your growth in the Scrum Master role, you need to do two things: “Do” the Scrum Master role to gain experience, and Learn to achieve mastery as a Scrum Master. To do the Scrum Master role, practice what you’ve learned. Make sure you’re doing the basics correctly. If you haven’t read the Scrum Guide, do it now (it’s only 16 pages). But don’t just read it, understand it. If you haven’t yet, consider taking the Professional Scrum Master course. If you can pass the Professional Scrum Master 1 credential, that’s good evidence you understand the roles, artifacts, events, and basic rules of Scrum. From the Scrum Guide, we know the Scrum Master is: … responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. That’s a tall order. You have to understand Scrum well enough to teach others. Experience will be an important component of your ability to help others do Scrum well. Most Scrum Masters that I work with are either apprentice or journeyman level. Some are just learning the basics (apprentice). Many are able to support Development Teams in “doing” Scrum on their own (journeyman). In the long run, that’s not enough. You will have to grow in your abilities beyond just doing Scrum. To be a master Scrum Master, you will not only need to gain experience in the mechanics of Scrum, you will need to gain an innate understanding of what Scrum means and to live by agile principles. How do the underlying principles of Scrum and agile affect actual work? Why do the Scrum roles, artifacts and events exist in the first place? Why are they important? Learn the answers to these question. Again, from the Scrum Guide: The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. In other words, a master Scrum Master is able to serve the self-organizing Development Team to constantly improve…even when the team can’t think of anything to improve upon. The master has absorbed the underlying principles of empiricism, constantly working to help the Scrum Team, the organization, and themselves inspect and adapt. The master’s focus shifts from features in releases to value delivery. And ultimately, the master Scrum Master focuses on behaviors more than process; that’s where mastery lies. But why should you? You already work long and hard at just doing the Scrum Master role. It will take that plus more effort and energy to become a master. I can think of at least three reasons why it’s worth it: The team: The Development Team will be better for it. A master Scrum Master doesn’t just schedule planning meetings and remove impediments. They proactively look for improvement opportunities the team is unable to see. They seek out how others are getting value out of new approaches and find ways to make this information available for the team to consider. A master Scrum Master is essential for a truly high-productive Scrum Team. Advanced Development Teams select their own Scrum Master; how will you be their first choice? The organization: In mechanical Scrum, journeyman Scrum Masters will focus on things like the planning of Product Backlog Items, velocity, and impediments. In professional Scrum, a master Scrum Master understands velocity is irrelevant unless the team is delivering value. Lots of irrelevant features are worse than useless—they waste investment. A master Scrum Master helps the Development Team, the Product Owner, and in fact, the whole organization to understand value delivery. Superior organizations consistently deliver more value for their investment; how will you make that happen in your organization? You: Daniel Pink, author of the book “Drive: The Surprising Truth About What Motivates Us,” identifies 3 primary motivators for people in creative professions like ours: autonomy, purpose, and mastery. Mastery is exactly what this article is about: the opportunity and drive to become among the best in your field. If you’re passionate about servant leadership in the Scrum environment, how will you achieve mastery in your role? If you’re going to grow toward mastery as Scrum Master, you need to not only support but actually help the other roles of Scrum: the Product Owner and the Development Team members. You don’t necessarily have to be an expert in those roles, but you do have to learn what it takes to do those roles. Consider classes for other Scrum roles such as the Professional Scrum series for Product Owner and Developer. And since the team is self-directing, you will need to excel at coaching skill such as those to be learned from the Agile Coaching Institute. The deeper awareness of Scrum required for mastery won’t come from experience alone. You will have to learn from others, just as apprentices and journeyman in other professions do. Of course, books, articles, and blogs will help. But there’s nothing like learning from others’ experiences. Get involved in local Scrum users groups. Go to meetings and events such as Scrum Days. Find other master Scrum Masters; talk to them…learn from them. Since we don’t currently have an apprenticeship system for Scrum or agile, how can you find the masters? Look for people that have evidence of mastery. Years of experience is necessary, of course. And objective evidence helps. For example, the Scrum.org Professional Scrum Master 2 credential is a difficult test confirming a person’s knowledge and experience. The up-coming Professional Scrum Expert credential (available in 2015) will be further evidence. Credentials alone don’t prove mastery but they can get you pointed in the right direction. It may be cliché, but to become a master Scrum Master is a journey. You can’t get there by reading a book or taking a test. You have to experience it, learn from other masters, and continuously improve yourself.