Per a January 20th, 2017 article by Daniel Shapero, VP of Talent Solutions and Careers at LinkedIn, the role of “Scrum Master” is in high demand. It’s ranked number 10 on his list of most promising jobs of 2017.
This all sounds great - a six-figure salary, tons of job openings, and lots of career advancement! So, what does it take to be a Scrum Master and how can you get a job in the field?
Let’s start with the basic list of top skills outlined in the LinkedIn research and go through each:
I’m not going to sugar coat it. If you want to be a Scrum Master, it helps to take the words naming that role literally. You'll need to be a master at using Scrum. You'll need to know Scrum so well that you can explain it to others in terms they understand even if they haven’t learned anything before about Scrum. Moreover, you need to understand why Scrum works, what problem each role, event, and artifact is solving, and why traditional SDLCs (aka, “Waterfall”) are inferior in the realm of new product delivery.
How can you understand Scrum at a master level? You need to read, practice, and experiment. You need to take the continuous improvement principles Scrum applies and embrace them at a very personal level. Even if you’ve taken a class, start by reading the Scrum Guide. Read it again, and read it one more time. Oh, and the Scrum Guide itself changes to continuously improve, so you’ll likely need to read it again next year.
Getting solid Scrum Master training and being certified helps, but getting a Professional Scrum Master (PSM-1) or a Certified Scrum Master (CSM) certificate is just the beginning of your journey. While these certifications may look good on your resume, it’s what’s inside that counts. You’ll need to know your stuff and constantly be learning.
Software Project Management
If you don’t understand how software teams work or how they are traditionally managed, Scrum will be foreign to you. Learning it would be like giving you an answer to a question you never had. It’s key to understand the traditional ways of managing a project, and the differences between a “Product” and “Project” to understand why Scrum works and what problem it solves. To gain this knowledge you’ll need experience in one of the following: Project Management, business analysis, software development, software quality assurance, user interface or user experience design, or some field that would give you intimate knowledge of how new products are made and the challenges people face in making them.
Scrum Requirement Analysis
If you understand how Scrum works, you also need to understand how the needs of the stakeholders are communicated to the team with which you work. Traditional ways of building new products involve large stacks of requirements. These requirements are designed to resist change and attempt to describe the end state of a product. A good Scrum Master can help their team work in better collaboration with their stakeholders to understand the problems they want solved and deliver quickly to solve the most important problems. This gives delivery teams flexibility to change as needs of the customer change.
A technical background helps considerably when working with product development teams. A background working with databases and using Structured Query Language (SQL), or software development, or something technical is important. You may not be doing the technical work as a Scrum Master, but you need to know enough about technology to be helpful. Part of a Scrum Master’s role is to aid in removing problems that reduce a development team’s efficacy. It’s hard to do that if you can’t help identify problems or don’t know the right questions to ask a development team to expose them.
Additional skills you’ll need
The ability to influence without authority is necessary to be successful. You are no one’s boss as a Scrum Master. Your role is to be a servant leader to the team. A ‘servant leader’ means you serve the development team to help guide them to success. Whip-crackers need not apply.
In general, excellent soft-skills and high emotional intelligence are necessary to be a good Scrum Master. If people don’t like working with you, your efforts to improve will stall quickly. This includes members of your team and the people in your organization that help you remove impediments. You also need to build a strong network within your organization to make things happen. If you never leave the area in which your team works, how can you possibly help remove roadblocks to team success? Again, soft-skills are critical to being an effective Scrum Master.
How do I find a job as a Scrum Master?
Clearly, you’ll need experience being on a product development team, so start there. You will also need an opportunity to experiment with the role of Scrum Master, so find a company going through an agile adoption or one that has already made the change. Seek opportunities to apply the skills mentioned above to project or product delivery teams. “Scrum Master” is just a role, it’s not a job title. Even if your job is to develop the product, test it, or project manage it, you can gain valuable experience by filling the need for a Scrum Master on your team. Get good training and keep learning. If you decide to make a career change and become a Scrum Master as a full-time job, you’ll be more than prepared to make the leap.
Being a Scrum Master is a challenging, but rewarding role. It takes years of experience and training to be one. Bad Scrum Masters don’t last long at an organization. If you’re curious about what a bad Scrum Master looks like, a simple YouTube search on that very topic will yield many humorous examples. Aim to be a good Scrum Master and your opportunities are without bounds. The world doesn’t need any more bad ones.
Your team has been trained and coached to deliver new chunks of software in a short time frame. Those using Scrum will be able to deliver in a Sprint. Those using Kanban will deliver as soon as their small feature is done. You’ve learned alternative ways of estimating which don’t include time as a measurement. Maybe you’re using story points, t-shirt sizes, or pills of vicodin to measure the complexity of your work. Delivery has clearly improved, but you still get asked every December to estimate year-long initiatives for annual budgeting meetings. Something doesn’t make sense and you’re having a hard time explaining it to upper management.
Let’s look at the issue from another angle. When you take your car to a mechanic to get new tires, you get a quote based on the set that fits your wheels, the brand and quality you expect, and a time estimate for when it will be finished. If any of the variables don’t line up with your needs, you’ll head toward a shop that can meet your expectations. When you get your car back and pay for services rendered, there were likely few surprises. The shop finished on-time, the cost was what you expected, and the brand of tire you requested is on your car as you leave the shop. The people who finance your projects are trying to make a similar decision regarding development initiatives. How much quality can we get for what price? When will it be finished? What will we get for that money? The difference here is that changing tires is a repeatable process. Auto shops do this every day.
Software projects are complex with many unknowns about the technology, the people, the problem, etc… The larger the project is, the exponentially more uncertain things become. If you’re a software developer and think “I’ve done this before, I can estimate it”, think again. Just look at a problem you solved a year ago. If you had to resolve the problem using the same technology, would you write the code the same way? If you said yes you’re lying to yourself.
I’ve never met a developer who enjoys their job that isn’t constantly improving the way they write code. Writing software is more like writing poetry than changing tires. It can always be written better, more concise, more readable and maintainable, even in the same language with the same tools. Coding style changes over time as a developer hones their craft. I remember a situation going through code I deemed too unreadable to avoid rewriting, but hit a wall. Unable to decipher the code, I went off to find the author to ask questions. After looking at the digital tags identifying the author, I realized I had written the bad code just 6 months ago. This was proof to me that I would likely never solve the same problem the same way twice.
On the delivery side we manage complexity by breaking large projects up into small and manageable pieces that can be delivered quickly. This technique is why we are agile and can respond quickly to change. If a mistake is made or the customer doesn’t like what was made, it’s far easier to change direction if we didn’t go too far on the wrong path before having something to deliver.
More on managing complexity
Let’s look at a couple other examples of complex systems that your finance people and senior management will better understand: The stock market and hurricanes.
No one will guarantee estimates of the behavior of these systems in the long-term. No one legally knows what the stock price of their favorite tech company will be in one-year’s time. No meteorologist really knows where hurricane johnny is going to be in a week.
The best tools we have involve creating a forecast, inspecting at a regular cadence and updating the forecast based on new information. Let’s take a look at a financial forecast:
Figure 1 - S&P 500 2012 forecast
At the end of 2011 this graph represented the best information available to forecast what 2012 would look like. Notice the wide cone... its representing a large range of possibilities that could occur by the end of 2012. Also notice none of them involve the S&P 500 hitting 1000 or 2000. The range of possibilities narrows as you are nearer to the present. As it turns out, the S&P closed at 1257.60 on December 30th 2012. Just north of the bottom end of the cone.
Hurricane forecasting is very similar. This is a forecast made for Irene
Figure 2 - Forecasted path of Hurricane Irene
While the actual path of Irene was somewhat different than the original forecast, it remained within the forecast the whole time.
Figure 3 - Actual path of Hurricane Irene
To understand forecasting complex projects, you need to understand the cone of uncertainty. Its an easy-to-digest model representing the variance in estimates you’ll find in a complex system. When you are close to done, estimates vary less. When you are much further from done, estimates vary much more and it’s not a linear relationship.
Using this model, you’ll want to be closer to done when you estimate. The closer you get to done with any work, the more likely you’ll be right in estimates about when it will be finished. The further you are, the worse. Still feel comfortable giving an estimate to that e-commerce website rewrite?
Figure 4 - The cone of uncertainty
How you can talk to senior leaders
It’s important to discuss this with your senior leadership and to explain the complex nature of software development. Show them that long-range estimates include exponentially increasing variance as predicted by the cone of uncertainty. The key to success is breaking up large initiatives into smaller deliverable and valuable pieces... and fund those. If you can get your initiatives down to 3-month, completely finished projects, you’d be on the right track to better estimates and better funding decisions.
Projects often get batched larger and larger. Resist that urge and encourage your senior leaders to do the same. This technique is not that different than earnings forecasts wall street analysts produce and their follow up examination of true earnings public companies report quarterly.
I strongly recommend you employ an empirical process to investing in your company’s initiatives and break the large batch project funding cycle that prevents true organizational agility.
I see four common reasons agile implementations don’t get the benefits hoped for. These reasons include a failure to limit risk, long end-to-end delivery lead times, consistent cost-overruns, and no one knows why you do what you do. Are you in this situation? Read on to see if these match up to your current situation.
You’re not limiting risk
General adoption of agile ideas, frameworks, and tools have happened. In my experience there are few organizations deriving the maximum benefit by embracing agility as an organizational goal. Baked into agile frameworks is risk mitigation. Risk comes in many forms, but the most common include:
You may be using Scrum, Kanban, XP, SAFe, etc..but that doesn't mean you’re appropriately protecting yourself from these risks. If that’s true then you’re limiting the benefits you receive. If you look to traditional SDLCs, they were designed to mitigate risk. Project managers serve a major role in ensuring risks are mitigated and dealt with appropriately.
When it comes to change and flexibility, traditional SDLCs usually go too far with control and do more harm than good. It's not that waterfall is bad, it just requires you know with certainty the end state, the time to complete, and the cost to get there. Any change to the plan risks disrupting the certainty in these variables and the happiness of your customers.
In many cases traditional projects increase time-to-first-value, which means delaying the total value achieved over time. The tendency for traditional projects to increase in scope to multiyear efforts adds back in the risk of change while trying to mitigate the risks of everything else. Enforcement of official change requests worsens the tendency toward longer projects since customers want to make sure everything they could possibly want is in scope before signing off to start. The more traditional SDLCs attempt to mitigate risk the more risk they create.
Just because you deliver in small batches doesn't mean you’ve mitigated all risk. For an agile adoption to be successful it must also address the same risks listed above and do as good of a job to mitigate or eliminate them.
To often I see agile shops that don’t adopt the practices as intended. Some examples include
Plain and simple, it's taking you too long to get an idea into customers hands.
The first thing I’d look for when auditing an agile implementation is the time it takes to go from concept to cash. This is the time it takes for a feature idea to become reality and ready for use by the customer. One has to consider all quality checks, documentation requirements, and anything else necessary to be customer-ready. In some cases, the amount of quality checks involved considerably constrains how much you can shorten lead time. In one company I consulted a 3 month regression test was the norm. Any change, no matter how small, would cause a 3 month manual regression test to get to production. If you have long lead times, you're not getting the full benefits of agility.
Consistent cost overruns
Cost overruns can come from numerous sources and I’ll list a few common ones. If you don’t build cross-functional feature teams, but instead build component teams that feed one another in a dependency chain, you increase the time to first value. There’s no guarantee the downstream teams will be able to use the upstream team’s contribution. To finish a feature, thrashing occurs when downstream teams send work back for fixes to be done by upstream teams. This scenario causes significant delays. The irony here is that component teams are often set up to be more efficient and cost-effective. The results are the opposite. If you have no control over costs, you’re not getting all the benefits of agility.
No one knows why
Do you know why you decided to become agile? Do the teams stand around like robots every day failing to question bad decisions? Does your Product Owner still expect your team to commit to a date including completion of every single item on their list? Why does your business exist and does the team know that? If no one knows why, or even asks, you aren’t getting the benefits of agility.
Let’s redefine agile: it's being nimble or light on your feet. If something changes and you can’t respond quickly and cheaply, I’d say you have a way to go before you call yourself ‘agile’. Agile frameworks are designed to help you be light on your feet, but they don’t promise you’ll succeed in using them as intended. That’s up to you. If you’re struggling with the above consider bringing in an outsider to help audit your implementation. It’s hard to see what’s right in front of you when you’re in the weeds of execution on a daily basis.
Any other things you’ve seen which prevent organizations from getting the true benefits of agility? Leave a comment!
I’ve been pulled into many emergency war rooms to kickoff last-ditch efforts to save failing projects. It’s heartbreaking to watch. Leaders in the room try hard to believe there’s hope to remedy the crisis. They sell a “great opportunity” to those tasked to fight the enemy. The technical team looks around in disbelief...they’ll have to endure another death march. The team’s reluctant to ask the hard questions such as “why is Q1 a hard deadline?”. The product management team crosses their fingers behind their backs with a barely genuine smile on their face. Racing through all of their minds is the question: Will I miss my kids birthday again this year? The pressure is on, the scope’s been determined...oh, and here’s your date, go!!
What’s the problem?
If you’ve ever solved a complicated puzzle before, try solving one at gunpoint. As you might imagine it doesn’t go well. Your fight-or-flight response kicks in and creative thinking sits in the backseat next to extreme nervousness and your résumé. For more reading on why solving puzzles under a lot of pressure to perform, see Glucksberg and the candle problem.
How did you get here?
Organizations that are struggling, or even dying, make terrible decisions in attempt to save themselves. Rather than pause, address the root issue, fix it, and improve, they throw more gasoline on the fire. They really think more people and more pressure will do the trick. For those that still hold on to this idea, the one that more people will fix your late project problems, Brooks Law applies and we’ve known this doesn’t work since the 1970’s.
This scenario plays out often with agile adoptions gone wrong. There is a myth in the world of software development that by being ‘agile’ you get the same work done faster. Another myth is you can apply a new software delivery framework superimposed on top of your old SDLC. Now, If you’re no more nimble now than you were before, are you really agile? Did doing ‘Agile’ make you more agile? I didn’t think so. Applying more pressure won’t help your condition. We’ll need to look deeper.
What can you do now?
Before you rush into the next death march, slow down a little and learn. Ask lots of questions like: “why are you where you are?”, “What are the real constraints?”, and “What’s the real problem?.” My favorite analogy in this case is: you have to stop the car to change a flat tire. If you have an educational flat tire, fix it first, then build an organizational habit of learning. Take this advice and begin to speed along faster than before.
Are you new to data warehousing? Take a class and work with a strong mentor or consultant as you get ramped up on your critical project. Are you new to Scrum, LeSS or SAFe? Take a proper training and get really good coaching to help navigate the grey areas you don’t learn in class. We in the technology space grossly underestimate how hard our work is, how hard coordination of many people against a large product offering can be. A medical analogy, we need to really understand the principles and practices of brain surgery before we have our first trauma patient. Do you really think large scale software development efforts are less complicated than brain surgery?
One last point
You have to slow down and educate yourself before you’re in a crisis. No one’s going to have a lessons-learned discussion or take proactive steps to fill in educational gaps when the house is on fire. They’re just going to put out the fire. Its like groundhog day...over and over organizations are just putting out the next project fire. Please, please stop setting projects on fire.
If you’re in the market to improve your company’s ability to delight customers or looking to reduce the time it takes to get new product enhancements to your customer, you’re probably asking about ‘agile’. If you have quality problems that constantly delay releases, you’re probably looking to be ‘agile’. If you’ve noticed that all the successful businesses in your industry are using an agile framework, you really want 'agile'.
So what is this ‘agile’ thing? Many in the software development industry still think agile is a noun, or a verb, but it’s really an adjective. Even when industry practitioners reference the Manifesto for Agile Software Development they miss that ‘agile’ is just an adjective. If ‘agile’ were a verb or noun you might be able to buy it off the shelf and use it. But you can’t buy agile. Agile has to be earned.
Let me elaborate with an analogy: if you want to be a marathon runner, and win, you’re going to need to be in good shape. You’ll have to eat right, sleep right, exercise right, and maintain that discipline for a long time. Failure to do so and you won’t get to the first water stand in your first race. If you really want to be good, you’ll hire a trainer and coach. Can you buy the ability to be a competitive marathon runner? Can you buy ‘healthy’ or ‘in shape’? Can you just take a pill? No, you cannot, because health and fitness have to be earned.
Being an agile organization is no different than being healthy and in-shape as a person. It takes time, discipline, good choices, and will-power. It takes knowledge and reinforcement of the right practices. For a person to be a marathon runner, it starts with applying the right form, building good habits, and sticking to the plan. Organizations must approach being agile the same way. The organization must start by applying the right form, or the right frameworks and build discipline. Next, the organization must set and reinforce good habits by challenging one another, asking ‘why’, and constantly finding ways to improve and to learn. Keep up the discipline and bake these ideas into your culture for long-term sustained success.
Taking a class won’t make you agile. Reading a book won’t make you agile. Hiring a team of agile coaches won’t even make you agile. However, doing all of these things and relentlessly focusing on being a nimble, healthy, and in-shape organization will eventually earn your company the adjective “agile”.
Ever heard of Water-Scrum-Fall? Ever heard someone in a product development group tell you “they use a hybrid-agile approach”? There’s a million ways people continue using a traditional, phase gated, software development lifecycle approach and marry it with an agile framework or methodology. They'll put familiar labels on meetings to get some of the benefits. They might use the word ‘Sprint’ to describe a chunk of time when some type of work happens or use 'daily standups' as a way to keep the project manager up-to-date on the work done the day before.
I’m not writing to tell you that you're bad, evil, doing it wrong, or the agile gods are going to strike you down. I'm going to write about how to be mostly-successful using a phase-gated approach and still be agile. Yeah, sounds kinda crazy, right?
Here's how to do it:
If you’ve learned Scrum and tried to implement it in any large organization you’ve likely run into a few issues. Getting dedicated people on your team is hard. Building cross-functional teams is really hard. Breaking your work down into small problems your customers care to have solved is probably the hardest. I'd like to talk a little about what I see as the most common three things Scrum teams get wrong.
If you’re struggling with the above you’ll see the symptoms immediately. As a matter of fact, when I’m first working with new Scrum teams, these are the first things I look for.
#1 - Your backlog is a list of hamburger orders
Take a look at your backlog. Does every item on it have a technical title and little else to describe it? If so, you have a backlog of hamburger orders. Hamburger orders don’t get questioned. The customer usually knows they want two patties, grilled onions, ketchup and mustard. It's not your job as a short order cook to ask the customer how many people they’re trying to feed or if they have a cholesterol problem.
In knowledge work, it is your job to know what problem you’re solving, so it can be solved. So often my clients will start from a 'requirements' document, break it down to a list of must-haves, and the team blindly builds them.
What’s the problem?
Teams can’t be creative if told exactly what to do. Sadly, this is how many developers are used to working. It doesn’t have to be this way. If you treat developers like hamburger order takers you will increase total delivery times, increase time-to-first-value, reduce quality, and discourage innovation.
What can I do?
Present business problems to Scrum teams. Better yet, provide them in order of importance. Work with your technical teams to represent the value needed on a product in terms of problems to solve and document it... then let the technical teams figure out how to solve the problems. Ensure that anyone who reads the backlog can understand the problems to improve communication between the stakeholders and development teams and reduce the need to translate. You did hire smart people, right? Then enable them to be brilliant and empower them to creatively the tackle problems they were trained to solve.
#2 - Your development team isn’t a team at all.
Well, your team is more like a football team that has a subteam of quarterbacks, another subteam of linebackers, and another for kickers that gather every Sunday to play, but your team doesn't always get the same players.
What’s the problem?
Your teams aren’t thinking like teams, not working like teams, and not succeeding like teams. They have different and competing goals. Those goals rarely align to solve business problems effectively.
One of the key benefits to building a cross-functional product-aligned team is to give the team all the skills needed to deliver value, and keep them focused on the same goals. Another problem might stem from having people collected as teams, but they’re working on initiatives that have nothing to do with one another.
What can I do?
Take a temperature of the team. Do they have the same goals? Do they really act like a team? Do they work like a team? If they don’t have the same goals, fix that first. Forget Scrum, Forget agile, good teams solve problems. Reduce the amount of work in progress your team is handling by properly filtering all the requests coming into the team into a single ordered backlog. This is where a strong Product Owner is key.
Work to build and grow your team from the inside... this is a people problem. Start with understanding Tuckman’s stages of group formation (Forming, Storming, Norming and Performing) and help guide the team through that journey. A strong Scrum Master would be a key individual I’d look to for this difficult job.
#3 - Your team has no way to know if they’re on track to finish a large release
What’s the problem?
When a team doesn’t properly refine a backlog during a Sprint you’ll have only a few Sprints worth of estimates. This makes it very difficult to know if the team is on track toward hitting important milestones. If you don’t know, you’re back to guessing and I’m confident there are people in your org that want to know how you're progressing. A common thing i hear is “we’re doing Scrum, so we don’t do dates.” Well that's just unacceptable to anyone writing your checks. Unless you want to keep having status report meetings, lets find another way.
What can I do?
You can release plan if you regularly refine your backlog. Aim to build domain knowledge, create clear description, and track your teams velocity. A good place to start is by writing your backlog items in the form of a user story. Then write good acceptance criteria and apply the INVEST model (see my references):
When your team has a good understanding of the problems they’re solving, they can estimate them and deliver the solutions in order of most important. It’s common in agile circles to use story points as a means by which to estimate. If you do so, they give you a number on the Y-Axis and time in units of Sprints on the X-axis. (see below graph)
A release plan graph (like the above) will give your organization visibility into your progress over time. If stakeholders don't like what they see, they can make a business decision sooner. Show this release burndown in every Sprint review and highlight the updates as your ‘Actual’ line changes over time.
If you’re on a team suffering the 3 things scrum teams get wrong, know that it's common. But also know you don’t have to suffer. Take these ideas and improve your team today. Did i miss ways your teams are solving these problems? Any questions left unanswered? Message me!