Jeremy Jarrell

Agile Made Simple

Tag: agile

Can The Scrum Master And Product Owner Roles Be Combined?

“Can’t we just combine the Scrum Master and Product Owner roles?” If you’ve been around new Scrum teams for any period of time then you’ve likely heard this question more…

“Can’t we just combine the Scrum Master and Product Owner roles?”

If you’ve been around new Scrum teams for any period of time then you’ve likely heard this question more than once. In fact, it might even sound as if it makes sense. After all, at first glance, the roles actually appear very similar. So similar, in fact, that one might believe that there may even be efficiencies to be gained by doing so.

But, if we look closer, many of these similarities only appear because these two roles are the only roles on a Scrum team which are not developer roles. In fact, that’s where the similarities end.

Creating a balance

While the roles may at first appear similar, in actuality they have very different focuses. The Product Owner is focused on the value that the team will produce and how to select the work that will ultimately enable that value. The Scrum Master, on the other hand, is focused on how to enable the team to deliver the work that the Product Owner chooses most effectively. This means that separating these roles between two individuals helps to strike a productive balance. This balance enables the team to produce value for their organization but to do so in such a way that ensures the long term creation of that value, such as working at a sustainable pace and keeping the level of technical debt in check.

On the other hand, when these roles are combined into a single individual often that individual will gravitate towards the role they are most comfortable with while starving the responsibilities of the other role. For example, if the individual is most comfortable in a technically-oriented role then they may gravitate towards those responsibilities of the Scrum Master that support and enable the Development team while ignoring the value maximizing responsibilities of the Product Owner.

Making the most of two roles

While ensuring that the Scrum Master and Product Owner roles are properly split across two individuals is a necessary ingredient to creating a high-performing Scrum team, there’s more to making the most of these roles than simply splitting them.

Often the tension created by attempting to balance the competing priorities of these roles leads to teams viewing the roles themselves as competitors. However, this simply isn’t true. While a healthy tension should exist between a skilled Scrum Master and Product Owner, these roles should complement each other rather than compete.

But, it’s also important to remember that the Scrum Master is not simply an assistant to the Product Owner, either. While the Scrum Master may help the Product Owner fulfill certain responsibilities, if both agree that doing so would be effective, this in no way implies that the Scrum Master should be subservient to the Product Owner. All members of a Scrum Team are considered to be equal which means that regardless of their roles in the organization, in the context of the Scrum team, the Scrum Master and the Product Owner are peers.

Resisting the temptation

While the temptation may exist to combine the Scrum Master and Product Owner roles, remember that these roles were intentionally designed as separate roles. Respecting this separation of responsibilities helps to ensure that your team will benefit from the the full value that each of these roles are designed to provide, which will bring them one step closer to becoming a high-performing Scrum team.

Want to learn more about how to overcome the most common problems faced by agile teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work with your team.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Can The Scrum Master And Product Owner Roles Be Combined?

Finding Your First Job As A Scrum Master

There’s no doubt that the Scrum Master role has been in the spotlight lately, even being named one of the top 10 most promising careers. This has garnered so much…

There’s no doubt that the Scrum Master role has been in the spotlight lately, even being named one of the top 10 most promising careers. This has garnered so much attention that the role has even begun to attract those from outside of the technology industry. In fact, several individuals have recently reached out to me expressing interest in breaking into the Scrum Master role without experience as part of an agile team or even in technology, in general. If you would love to break into the Scrum Master role but simply don’t have the experience, then don’t despair…finding your first job as a Scrum Master may be easier than you think.

Getting Certified

For better or worse, holding at least an entry level Scrum Master certification is a prerequisite for almost any Scrum Master position today. While the value that some certifications yield may be debatable, their requirement is omnipresent in almost every Scrum Master job posting.

Luckily, the surge in demand for these certifications has resulted in several different options for finding the certification path that’s right for you. The two most dominant options are the Certified ScrumMaster® (CSM) certification offered by Scrum Alliance® and the Professional Scrum Master (PSM) certification offered by Scrum.org. Both certifications are based on the Scrum Guide, which is the standard reference point for learning the Scrum framework, and both certifications offer paths towards more advanced certifications beyond the entry level certification.

The major difference in these certifications is how they’re earned. To earn the Certified ScrumMaster certification you must attend a two-day in person training class offered by a Certified Scrum Trainer, who is licensed by Scrum Alliance. After completing this class you will be eligible to attempt a certification exam which will allow you to earn the Certified ScrumMaster® certification.

On the other hand, while similar two-day in person training classes are offered by Scrum.org licensed Professional Scrum Trainers, the attendance of such a class is not a mandatory prerequisite before attempting Scrum.org’s own Professional Scrum Master certification exam.

Preparing For The Exam

The option to purchase a Professional Scrum Master certification attempt directly from Scrum.org without the need to incur the cost of attending a live class makes this path a very attractive option for those who are seeking a more economical option to certification or for those who simply do not have access to live training in their local area. Be aware, however, that Scrum.org’s exams can be quite rigorous and are not for the faint of heart. The Scrum.org training courses are of very high value, so if you’re considering attempting the Professional Scrum Master exam without the benefit of attending one then you’ll want to take a few steps to prepare yourself.

As a first step, you’ll want to take some time to review the Scrum Guide in depth to make sure that you understand the rules of the Scrum framework. In addition, you’ll also want to familiarize yourself with what is actually part of the Scrum framework versus what complementary practices you may have simply attributed to the Scrum framework. For example, are Story Points part of the Scrum framework? If you think that they are then you may need to spend some time reviewing the Scrum Guide.

Next, you’ll want practice the Open Assessments that are available for free on Scrum.org’s website. While the assessment questions on the actual exam tend to be more difficult than those found on the Open Assessments, practicing the Open Assessments will help you familiarize yourself with the language and format of the questions that you’ll encounter on the actual exam. Note that Scrum.org makes several different Open Assessments available so you’ll want to consult the PSM I certification page to learn which Open Assessments will be the most helpful for preparing you for your certification.

Finally, you’ll want to take some time to understand how the rules of the Scrum framework play out in practice. A great place to start is Pluralsight’s Using the Scrum Framework Learning Path, which will introduce you to not only the mechanics of the Scrum framework, but also to how those mechanics can be applied inside of your team. Many budding Scrum Masters have used this path to successfully prepare for earning their PSM I certification and you’re likely to find value in it, as well.

Sharing Your Thoughts

Once you’ve learned the basics of the Scrum framework then it’s time to start sharing your thoughts on Scrum with the world. A great way to do this is with your own blog where you can share your evolving thoughts on the Scrum framework and how it can help teams be more effective. If you don’t yet have thoughts on how Scrum can help teams then don’t worry, simply using the blog to document your own learning process as you learn more about the Scrum framework can be a great first step.

You can even use this as a platform to share your thoughts on any agile-related books that you’ve read or to work through open questions that you may still have about the Scrum framework. Whatever the content is, you’ll be amazed at how simply taking the time to write and formulate your thoughts will help you better crystalize your own understanding of Scrum. In fact, simply documenting your own experience earning one of the certifications mentioned above can be a great starting point.

There are a lot of options available for starting a blog so don’t let a lack of experience with blogging stop you from doing so. While you may think of a blogging as hosting and managing your own blog at your own domain, third party publishing sites such as LinkedIn and Medium can making the process of starting your own blog nearly instantaneous. These third party platforms can also remove the headaches that inevitably come with having to manage your own platform and will even give you immediate access to an interested audience rather than having to build a following from the ground up.

But speaking of audience, remember that the size of your audience isn’t important. Your blog is an opportunity for you to showcase your thoughts and passion regarding the Scrum framework and the Scrum Master role. Organizations that are hiring Scrum Masters will be most impressed with your passion for your craft and your initiative to share that passion with the world, not by the size of your audience.

Meeting People

More than anything else, the Scrum Master role is about interacting with people, and there’s no better way to do that then to find like-minded individuals who share your passion for Scrum. Sometimes, simply knowing the right individual at an organization is all it takes for you to get your chance at your first Scrum Master position. But where do you find these individuals?

Start with where they tend to gather. A great starting point is attending the agile related sessions at small regional conferences. Many agile conference sessions are interactive so they can be a great opportunity to meet others in the Scrum Master role. In addition, most major cities offer agile meetups where agile practitioners can meet regularly to discuss advancements in their field. Make it a point to become a regular attendee of your local meetup and you’ll inevitably start to meet others who can help you get your big break.

But there’s actually a way to take this a step further. Many agile companies are proud of their new way of working and are happy to open their doors to others who might benefit from it. Find out which companies are the agile thought leaders in your area and reach out to those companies. Ask if they would be open to you shadowing one of their Scrum teams for a few days to learn how Scrum works in practice, similar to an unpaid internship. You’ll be surprised at how many companies are open to these types of arrangements and are more than happy to allow you to sit in on a few of their Scrum events to see their team in action.

Doing this will not only give you first-hand experience as to how the Scrum framework is often implemented in practice which you can speak to during your next interview, but the connections and friendships that you form during that time might very well lead to your first Scrum Master opportunity.

Taking That First Step

While the steps I’ve discussed above are best followed in the order that they’re presented they can be taken in whatever order makes the most sense for you. For example, if you have the opportunity to spend time with a high-performing Scrum team before you’ve earned your certification then certainly don’t let the lack of a certification stop you from doing so.

What’s important is that you take the first step that’s right for you and helps you come one step closer to fulfilling your dreams of becoming a great Scrum Master.

Do you want to learn more about launching your career as a Scrum Master? Or, are you an experienced Scrum Master who is ready to take your craft to the next level? Check out my course series, Using the Scrum Framework, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Finding Your First Job As A Scrum Master

Measuring The Value Of An Agile Team

Measuring the value that an agile team creates is one of the biggest challenges that teams who are new to agile often face. And while many agile methodologies put an…

Measuring the value that an agile team creates is one of the biggest challenges that teams who are new to agile often face. And while many agile methodologies put an emphasis on focusing on those activities that are most likely to yield value for your organization, how to actually measure that value often remains a question.

For many agile teams, especially those using the Scrum framework, velocity is often the first place we look. But is velocity really the best measure of the value that a team creates?

What’s Wrong With Velocity?

Velocity is often described as a measure of the amount of work a team delivers in a given sprint, but this description isn’t entirely correct. Rather than a measure of the amount of work a team delivers, velocity is actually the sum of the estimates of each story that the team delivered during that sprint.

Let’s look at an example. Imagine during the last sprint your team delivered the following 5 stories.

The total of the estimates of all of those stories was 21 points, which means that your team’s velocity for the last sprint was also 21 points. But does that mean that your team delivered 21 points worth of value? Not necessarily. The points that we’ve just described are estimates of a story’s complexity, which doesn’t always correlate to a story’s business value. For example, the previous sprint’s most complex story, which was the story to update the admin portion of the app to support color blindness mode, was estimated at 8 points. However, just because this was the most complex story undertaken in the sprint doesn’t necessarily mean that it was the story which produced the most business value.

By comparison, the story to add American Express as a supported credit card was estimated as the least complex story in the sprint at only 2 points. However, due to the potential for additional revenue this story may have been one of the most valuable stories delivered in the entire sprint, despite its relative simplicity.

What does it mean that our most complex story was one of our our least valuable while our least complex story was one of our most valuable? It tells us that velocity isn’t necessarily correlated to the value produced. In fact, this example tells us that it may not even be a reliable proxy.

Changing the Conversation

To measure the value that an agile team produces you must shift the conversation away from your team’s productivity and towards the value that your team actually creates. But to do this, you must have at least an initial understanding of how that value is created.

Sometimes this can be easy, as in the case of a story that may result in increased usage of your product or even in direct revenue. But other times, it may not be as easy. Sometimes the ultimate goal of a story is not to increase revenue, but instead is something more tangential. For example, some stories are written with the goal of streamlining an existing workflow inside of a product, improving the perception and awareness of a company’s brand, or simply making an existing process inside of an organization more operationally efficient.

Measuring the impact of these kinds of stories can be difficult and that difficulty only increases if the impact must be measured soon after a story is delivered. So, how do you measure the impact of these types of stories?

Understanding The Value Your Stories Will Create

The most important point to remember is that if you don’t have at least an idea of how to measure the impact of these stories then immediately stop where you are. Everything an agile team does should be in support of maximizing the value that they produce for their organization. This means that if you don’t have at least an idea of how to measure the value of what your team will be creating then you don’t understand your end goal well enough to continue to invest in it.

If this is the case, then take a step back and consider what the value is that you’d like each story to produce. Once you have an understanding of what that value is then you can begin to brainstorm possible ways to actually measure that value after delivery.

It’s important to realize that your first idea of how to measure the value produced in these cases doesn’t have to be correct. In fact, measuring these types of stories can be so difficult that you’re unlikely to get it right the first time. But to learn from that experience you need to consider why your first attempt was wrong and what you could do differently to measure that value more effectively. Like most things in an agile, learning to measure the value produced by stories that don’t directly produce value themselves is often an iterative process. However, this iterative process not only results in the right answer, but also teaches you more about the value your stories are creating along the way.

Making the Most of Measuring

A high-performing agile team will almost certainly produce value for your organization, but understanding how much value they create isn’t always straightforward. Worse, it can often be easy to conflate metrics such as velocity, which are intended solely for the team's own use for forecasting and planning, with the amount of value that the team is producing.

But by using the opportunity to measure the value that your team is producing as a chance to uncover what that value truly is, you can be sure that your team will always be producing value for your organization.

Want to learn more about getting the most out of agile with your team? Check out my course, Agile in the Real World, for tips and techniques for making agile work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Measuring The Value Of An Agile Team

The Case for Eliminating Epics

It should come as no surprise that the smaller the pieces your team can break their work into, the better chance they’ll have at succeeding at that work. After all,…

It should come as no surprise that the smaller the pieces your team can break their work into, the better chance they'll have at succeeding at that work. After all, smaller pieces not only reduce the risk associated with your work, but they can also be easier for your team to understand.

In fact, breaking work into small pieces is so beneficial for your team, that most agile methodologies is to do everything possible to encourage you to do so.

But, despite all of the obvious advantages of breaking work into small pieces, teams who are new to agile still find themselves hiding large pieces of work inside of epics.

To be fair, epics aren’t inherently evil. They can be a great tool for storing loosely defined work on the product backlog, or for grouping smaller and related pieces of work in a logical way. In fact, there are quite a few perfectly valid uses for epics.

What’s Wrong With Epics?

Unfortunately though, many teams tend to use epics as way to enable their bad habits. In particular, epics can encourage poor refinement of ideas by enabling people to capture details in epics that they would otherwise consider too poorly refined for a normal user story. This can result in poorly refined stories being hidden on the product backlog, under the guise of epics.

While at times this can be acceptable, the trouble arises when epics are slated for teams to work on during a sprint rather than slating the individual stories that comprise those epics. This is because while it can be perfectly acceptable to load the component user stories of an epic directly into a sprint, the epics themselves should never be loaded as a sprint level item.

Loading an epic directly into your sprint allows you to hide larger work inside of your sprint than would otherwise be acceptable. And, when work is not broken down appropriately before loading it important details become much more likely to fall through the cracks and missed by your team.

This can result in vague and poorly defined work which can be tough to prioritize.

So What Should You Do?

Remember that epics are just another type of user story. Don’t lower your bar of what’s considered acceptable for an epic just because it’s larger than a normal story. Instead, simply consider an epic to be a story that’s been refined to the point that’s most appropriate for where that story is at in its lifecycle at that time. This may not mean that an epic should adhere to the same Definition of Ready as a typical user story, but some level quality should still be applied to it.

However, if your team still seems to struggle with understanding what the appropriate level of refinement is for an epic, it may be time to eliminate them from your toolbox until your entire team has a better understanding of how to get the most from this particular tool. This doesn’t mean that epics will never be appropriate for your team, but until everyone has a better handle on how to use them appropriately it may be time to take them off the table.

Want to learn how to get even more out of  user stories? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on The Case for Eliminating Epics

Is Your Process A Rose Or A Dandelion?

This is a rose. Roses are some of the most beautiful, and the most coveted, flowers grown on earth. But, that beauty comes at a cost. To thrive, roses require…

This is a rose.

Roses are some of the most beautiful, and the most coveted, flowers grown on earth. But, that beauty comes at a cost.

To thrive, roses require near perfect conditions and nearly constant attention. For example, if you hope to see that luscious deep red bloom that roses are known for, then at a minimum your rose will demand

  1. Six hours of direct sunlight each day
  2. A bed of perfectly pH-balanced, ideally organic, well-draining soil
  3. 2-3” or coarse, once again ideally organic, mulch surrounding the rose
  4. Infrequently, but deeply applied water, applied directly to the soil and only late in the evening

But these are only the basics. If you really want to see those gorgeous blooms, then be prepared to also take steps like

  1. Regularly chopping banana peels and burying them around the stem of your rose…while being careful, of course, not to touch the roots
  2. Brewing alfalfa tea for your rose and treating it’s surrounding soil to a nice afternoon cup of tea
  3. Pulling out your iPod so your rose can enjoy the sonatas of Beethoven and Mozart. But only their early stuff…you’re rose is a classic, after all.

If you follow each of these steps consistently and without fail, then your rose may reward you with one or two blooms. In fact, you may even get to enjoy these blooms for up to two weeks…before you have to start the process over again, that is.

Meet The Dandelion

This is a dandelion.

Dandelions don’t need perfectly pH-balanced soil. They don’t need perfectly consistent watering that only occurs at the perfect time of day. And, if you try to treat them to afternoon alfalfa tea and the occasional Beethoven sonata, they’ll only laugh in your face.

Compared to roses, dandelions can grow nearly anywhere, in nearly any conditions. And, trying to kill them, seems to only make them stronger.

This is because, regardless of what’s happening in their environment, dandelions will find a way.

A Process Like A Rose

Now think about the process your team uses to deliver software each day. Which of these flowers feels the most familiar to how your team works? Is your team’s process a rose, or is it a dandelion?

We’ve all seen rose-processes. Rose-processes are filled with complicated rules and procedures that must be adhered to. They demand the full attention of the teams who are implementing them and create a plethora of roles and ceremonies that must be strictly followed if they are going to work.

But, when they do work, they are beautiful. They create a clean and streamlined environment in which your team can ship software, and they stay that way as long as the environment that you’ve created for them remains stable and constant. Which, if you’ve ever worked in any technology environment, you know the words ‘stable’ and ‘constant’ typically aren’t the words that spring to mind to describe it.

Becoming A Dandelion

Dandelion-processes, on the other hand, can thrive in nearly any environment. This is because rather than expecting the environment to adapt to their needs, dandelion-processes adapt themselves to the reality of their environment.

A dandelion-process demands little of the team who chooses to practice it, often no more than a few loosely defined roles and ceremonies. In fact, dandelion-processes often prescribe little about how these roles and ceremonies should even be implemented, instead leaving it up to the team to implement them in whatever manner is most likely to succeed in their environment.

In fact, dandelion-processes are so robust that they always seem to find a way to crop back up even when an organization tries to stomp them out. Perhaps it’s the natural resiliency of a dandelion-process that permits this or perhaps it’s simply the insistence of the teams who practice them to want to use a simple process that works, but in either case, dandelion-processes have a way of always coming back.

Any Process Can Be A Dandelion Process

You may think that I’m hinting at certain processes as rose-processes and other processes as dandelion-processes, but this actually isn’t true. While certain processes may naturally find themselves gravitating towards a rose’s fragile beauty while others may naturally gravitate towards a dandelion’s robust utilitarianism, the truth is that any process can be rose or a dandelion.

It all comes down to how each team decides to practice the process they choose to adopt. Given enough time, even the most lightweight and minimalist of processes can gradually accrete enough supporting processes and value-adds to incur the fragility of a rose. While, when boiled down to their essence, even the most complex processes can start to show dandelion-like qualities.

The secret is to understand that whatever process your team adopts, that process is a means to ship great software…not a goal. When the process becomes your focus, any process has a tendency to grow to demand the constant nurturing care of a rose in order to bloom. But, when you remember that the process is there only to support your team and its goal of a shipping software, then you can be sure to keep your process lightweight, robust, and capable of thriving in even the most unidealistic of situations, just like the dandelion.

Want to know more about creating a process for your team that can withstand the reality of your environment? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Is Your Process A Rose Or A Dandelion?

Start With Stickies, Not With Tools

The beginning of a Scrum adoption is always an exciting time for teams. The promise of what the future holds, a new way of working, and the possibility of a…

The beginning of a Scrum adoption is always an exciting time for teams. The promise of what the future holds, a new way of working, and the possibility of a better way to do what the team loves always holds great potential.

But in this excitement, many teams rush into selecting a tool that will help them run their projects in this brave new world. This isn’t surprising, there’s no shortage of agile project management tools available and many of them shine in demos. But choosing a project management tool too soon confines your team to that tool’s approach, rather than allowing your team to discover the approach that works the best for them.

This can lead your team down the path of confusing discussions about the “right way” of operating and how the team can warp their process to meet the expectations of the tool. All of which can lead to a lot of unwarranted frustration with the team’s entire adoption of Scrum.

Starting on the Right Foot

So how do you avoid becoming a slave to your tool? Instead of choosing a tool too early in your Scrum adoption, begin your process as lightweight as possible. This can be done by simply creating a Scrum board on an empty wall in your team area from painter’s tape and a few pads of sticky notes.

When choosing the columns for your board just ask yourself what steps your team must take to deliver a piece of functionality to the market. We can assume that each feature must be coded, but what happens then? Is it peer reviewed by another member of your development team? Is it tested before release?

Whatever your delivery flow is, capture each step as a column on your Scrum board. Creating your board by hand gives you the flexibility to map out exactly what your delivery process looks like so it’s visible to everyone involved.

Only after you’ve discovered the process that works for your team should you consider finding a tool that supports that process.

Taking Responsibility for Your Process

But there’s another benefit to managing your team’s process by hand. Creating a board manually also requires your team to take responsibility for ensuring that the board is updated and always reflects the current state of each piece of work in progress. Is that authentication routine really still in progress? I thought it was tested yesterday? And what about the latest database migration scripts? The board says that they’re in progress but are you really working on them? Weren’t you busy with a production issue for the last two days? By forcing your team to take responsibility for updating the board each day you increase the odds that the Scrum board accurately reflects the work in progress.

Too many teams take a passive approach to their adoption of the Scrum Framework, relying on their tooling to manage the heavy lifting while they change very little about their way of working. The obvious result of this is that if the team changes very little about how they actually work, then very little actually changes. But by taking a hands-on and manual approach to tracking their project the team is forced to take responsibility for the progress they make day to day and to face tough questions when that progress isn’t what they expected it to be.

Limitations Breed Simplicity

But there is potentially an even bigger benefit to skipping an electronic tool early in the team’s adoption. This is that the natural limitations of a physical board drive a simplicity that simply can’t be matched by an electronic tool.

Electronic tools breed complexity with their multitude of options and seemingly infinite ability to capture detailed information. But a physical board naturally limits your team to focusing only on what is critical to their process. Do the columns on the Scrum board really reflect each step that your team takes to deliver a piece of functionality? If items seem to stay in certain columns for days with no obvious progress then you may be missing a step. Or, maybe you’ll notice that you seem to be trying to fit a lot of information on the the front of a sticky note. What if instead you simply captured the essence of what you’d like that item to accomplish and let the rest of the detail naturally emerge from a conversation between the Development Team and the Product Owner.

Many of the natural aspects of working with a physical board that are often initially considered to be limitations, turn out to be advantages when looked at from the broader perspective of the team’s overall process.

Letting Your Team Drive the Process

The surge in popularity of Scrum and other agile approaches have resulted in a flood of great agile project management tooling on the market, many of which have some great features and amazing functionality. While these tools can add value to a team who has reached a certain level of maturity in their agile approach, they are almost always the wrong choice for a team just getting started on their agile journey.

Use your team’s Scrum adoption as an opportunity to press the reset button and take the chance to discover the process that works best for them, rather than simply jumping into the process prescribed by the tool that demos the best. You’ll find that the long term result is a team that’s much more confident, happier, and effective in how they work. Because at the end of the day, your tool should support your process…not the other way around.

Are you new to the Scrum Master role and are just trying to find your way? Or, are you an experienced Scrum Master who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Start With Stickies, Not With Tools

Scrum Master Demand Is at It’s Strongest Point Ever

It’s no surprise that the Scrum Framework is quickly becoming the framework of choice for teams interested in adopting an agile methodology.  In fact, VersionOne’s 2016 State of Agile Development survey…

It’s no surprise that the Scrum Framework is quickly becoming the framework of choice for teams interested in adopting an agile methodology.  In fact, VersionOne’s 2016 State of Agile Development survey puts the number of teams currently following a pure Scrum approach for their agile implementation at 58%. Furthermore, this number increases to 75% if you include hybrid approaches such as those which combine Scrum with another agile approach such as Kanban to create Scrumban.

But despite the simplicity of the Scrum Framework its adoption by a team new to an agile approach is still not for the faint of heart. If you’ve ever been on a Scrum team you’ll know that a large part of most team’s success is the presence of a skilled Scrum Master. This individual is responsible for ensuring that the team is adhering to the Scrum Framework in a way that helps them to deliver their product in the most effective way. Given the growth in popularity of the Scrum Framework it should come as no surprise that this growth is also fueling an unprecedented demand for Scrum Masters.

Scrum Framework Growth Breeds Scrum Master Demand

So much so, in fact, that the Scrum Master role has found itself square in the middle of LinkedIn’s list of The Most Promising Jobs for 2017. This list, culled from LinkedIn’s unique position to analyze job trends and growth, placed the Scrum Master role at #10 of the 20 most promising jobs for 2017. According to LinkedIn, this uptick in demand has given the role a median base salary of $100,000 USD and a year-over-year job growth of 400%, which will likely drive base salaries even higher as demand for the role continues to increase.

If you’ve seen many “hot jobs” lists in the past then the dominance of jobs from the tech sector should come as no surprise. As a matter of fact, 12 out of 20 jobs on LinkedIn’s Most Promising Jobs for 2017 list come straight from the technology sector.  So what makes the Scrum Master role any different?

Becoming a Scrum Master Is Easier Than You Think

LinkedIn’s Most Promising Jobs list contains many roles which are highly specialized and thus can require years of developing both specialized skills and experience, such as a Data Architect or Site Reliability Engineer.  But unlike these roles, the Scrum Master role can be very accessible for someone who already has a technical background which makes this path more of a lateral career move for many who are already in the tech sector.

This is because some of the most important skills for a successful Scrum Master are an in-depth understanding of your organization’s software delivery process and a willingness to connect with and build relationships with those both inside and outside of your team.  By combining an overarching view of the steps necessary for your organization to bring your product to market with a willingness to build relationships with those individuals who are involved each step of the way, you can build the skills necessary to clear the path for your team to keep them moving as efficiently as possible.  And this ability to keep your team on a clear path is one of the most important responsibilities for a Scrum Master.

This means that if you’ve already gained some experience in your organization’s software development ranks in a role such as a developer, tester, or designer and you like interacting with others in your organization then the Scrum Master role can be an attractive option for your career path and one that’s much more accessible than a highly technical specialization requiring years of training and experience.

What It Takes to Become a Great Scrum Master

If this appeals to you then you’re probably wondering what it takes to land a job as a Scrum Master. Well, in addition to the skills that I described above you’ll need a strong understanding of the practices and components of the Scrum Framework and the ability to help your team learn to interpret the Scrum Framework in the way that’s the most effective for them. You’ll also need a thorough understanding of the broader agile concepts and methods that the Scrum Framework embodies so you can be sure that your team is always adhering to the spirit of the agile methods that underlie Scrum.

But in addition to these skills, many candidates find that holding one of the more recognizable Scrum Master certifications can be a helpful step to getting their foot in the door. The most recognized of these certifications are the Scrum Alliance Certified ScrumMaster© certification, commonly known as the CSM, and the Scrum.org Professional Scrum Master™ I certification, commonly known as the PSM I. You can see the specific requirements for each certification on the respective website of each certification body but, in general, the path to each certification includes attending a multiple-day in-person training event and then passing a written exam testing your knowledge of the Scrum Framework. However, while multiple-day training events are available for both certifications, please note that in the case of the Professional Scrum Master certification attending this event is not required before taking the exam, though it can be extremely helpful.

Building on Your Experience

Without question, in addition to a strong understanding of the inner workings of the Scrum Framework and a well respected certification, the most important ingredient for success as a Scrum Master is the ability to interpret and ford the political waters of your organization to help your team to succeed. This ability can be gained only by an investment of time in learning the ins and outs of the environment and culture in which you will function as a Scrum Master. This is because regardless of the number of certifications they’ve earned or the depth of their knowledge of the Scrum Framework, a Scrum Master who unable to navigate the trade winds of their organization will ultimately be ineffective.

The Scrum Master role can be an incredibly rewarding role for those interested in blending elements of technology, leadership, and business acumen in a way that allows them to help their team deliver great work in a way that’s both productive and enjoyable. And the recent surge in demand for individuals who are able to serve this role, combined with the lateral nature of moving into this role for those individuals who are already from a technical background paint a bright picture of the future demand for this role. All of these elements combine to make this role the ideal choice for anyone who is looking for the next step in their career or who is simply interested in trying their hand at something new.

Does the Scrum Master role sound like the right next step for your career? Or, are you an experienced Scrum Master who wants to become more effective in you role so you meet the increased demand for your skills? If so, then check out the course series, Using the Scrum Framework, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Scrum Master Demand Is at It’s Strongest Point Ever

3 Ways Product Owners Can Help with a Great Sprint Planning

A great Sprint Planning session sets the tone for the entire Sprint. Your team leaves the session energized, excited, and with a clear picture of how to hit the ground…

A great Sprint Planning session sets the tone for the entire Sprint. Your team leaves the session energized, excited, and with a clear picture of how to hit the ground running in the new Sprint. But, what if things don’t go as well as you’d hoped? Then your team will leave the session tired and frustrated.  They will leave without a clear idea of how to get started on their new set of work. They may even leave without any idea of what their goal for the next Sprint even is.

If you’re a Product Owner, you may appreciate the importance of the Sprint Planning session but consider a successful planning session the responsibility of the Scrum Master. While this may be true, there are a few simple tricks that you can use to help your team get the most out of this critical ceremony.

Paint a Clear Picture

The Sprint Planning session is your opportunity to paint a clear picture of the upcoming Sprint and the objective that you hope to complete. But to do so, you must come prepared with both an engaging vision for your team as well as fully prepared to discuss the details of each Product Backlog item that you’ve selected to support that vision.

The details that you provide will be essential for helping your team appreciate the depth and complexity of the items that you’ve selected. And, it's these details that will help your team give as accurate of an estimate, as possible.

Mind Your Body Language

Just accept it, it's going to happen. Sometimes your team will throw an estimate on an item that’s higher than you expected. But when it does happens, how you react will play a major role in setting the tone for your relationship with your team.

On many teams, the Product Owner is treated as a figure of implicit authority. For this reason, it’s imperative that you be acutely aware of your body language, facial expressions, or any other behavior that may put pressure on your team to reduce their estimates.  Even if this pressure is inadvertent.

Pressuring your team to reduce their estimates won’t reduce the actual work behind the estimate and will only make your job harder.  This is because your own long-term planning lives and dies by the validity of the estimates that your team provides. If you pressure your team into giving inaccurate estimates then it will be your release plan that suffers in the end.

Instead of applying pressure, take this opportunity to ask questions. Why is the estimate higher than you expected? Or, what hidden complexity exists in the item that you didn’t see before? Taking the time to understand why the estimate is higher than you expected may reduce your chances of being surprised in the future.  In fact, it may even uncover an alternative path to achieving the same goal with less complexity.

Remember That Estimates Are a Forecast

Above all, remember that the estimates your team provides are a forecast…not a commitment. Holding a team to their estimates creates a culture of fear. And, in such cultures, your team will invariably begin to sandbag their estimates to protect themselves from the possibility of occasionally under-estimating an item.

Once this happens, your team will begin to continually pad their estimates to create a larger and larger margin of safety. The result, of course, being that the amount of actual work completed each Sprint will continue to dwindle.

But, there's an even worse casualty of this trend. Learning can only occur when a team feels safe enough to embark on experiments and learn from their failures. If a team is punished for every mistake then all learning will eventually cease. And, without the ability to learn, your organization cannot hope to compete in the world of product development.

Helping Your Team Succeed

The role of the Product Owner is easily one of the most important roles on a Scrum Team but is also arguably the most difficult. The Sprint Planning session is your opportunity to invest in your relationship with your team each Sprint. Because it's only with an ongoing investment in that relationship will your product see long-term success in the market.

Have you suddenly found yourself in the Product Owner role and want to know how you can use this role to help your team be successful? Check out my course series, Using the Scrum Framework, to learn how you can help your team reach their highest potential and deliver a great product to market.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on 3 Ways Product Owners Can Help with a Great Sprint Planning

Every Team Member Is a Scrum Master

There’s a saying in the US Navy that every sailor is a firefighter.  This is because when a ship is threatened by fire, there are few worse places to be…

There’s a saying in the US Navy that every sailor is a firefighter.  This is because when a ship is threatened by fire, there are few worse places to be than trapped on a ship, miles from land, with no place to go.  When this happens, regardless of your title, everyone on the ship becomes one thing and one thing only…a firefighter.

A similar principle could be applied to Scrum teams.

What If There's No Scrum Master?

Scrum teams are comprised of 3 different roles…the Development Team, a Product Owner, and a Scrum Master.  The Scrum Guide tells us that the Scrum Master is the team member responsible for keeping the team on track within the context of the Scrum Framework and for helping the entire team perform at their highest potential.  This is great if you have a talented Scrum Master who’s always around to help the team.  But what happens when that person isn’t around?  Maybe she’s taken a vacation, has suddenly come down with the flu, or simply isn’t feeling up to the task?  If so, then the responsibility of keeping the team on track must fall to the other members on the team.

In times like these, every team member is a Scrum Master.

Does your team seem to be falling behind your expected velocity?  Or, are you in danger of missing your goal for the sprint?  If so, then it’s your entire team’s responsibility to pull together to understand why your velocity is less than you expected.  Or, to pull together to understand what you can do to accomplish your goal before the end of your sprint.

Is there someone on the team who seems to be struggling this sprint?  Or, is there someone who just doesn’t seem to be connecting with the rest of the Scrum team?  Then the rest of the team must work together to help that individual find their footing and get back to producing at the level that they’re truly capable of.

It's Everyone's Responsibility

When the sprint is in trouble, it’s everyone’s responsibility to to help right the ship…not just the Scrum Master.  Sure, the Scrum Master may be who we think of first as the individual responsible, but if the Scrum Master is unable to right the ship by themselves then she’s not the only one who suffers…the whole team suffers.  So if everyone is at risk, then why shouldn’t everyone pitch in to correct the problem?

Great Scrum Master's don't define truly high functioning Scrum teams.  Teams in which every member is willing to contribute to the Scrum Master role define truly high functioning Scrum teams.  This is because truly great teams know that when times get hard, every team member becomes a Scrum Master.

Are you new to the Scrum Master role and are just trying to find your way? Or, are you an experienced Scrum Master who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Comments Off on Every Team Member Is a Scrum Master

The Daily Scrum is a Planning Meeting…Not a Status Meeting

The Daily Scrum is a core ceremony of Scrum and one of the first that most teams adopt. But, despite its prominence, many teams struggle to grasp the point of…

The Daily Scrum is a core ceremony of Scrum and one of the first that most teams adopt. But, despite its prominence, many teams struggle to grasp the point of this ceremony.

For example, let's look at a typical Daily Scrum for a team building an ecommerce product. We’ll start with our Scrum Master, Jenny.

Jenny: “Ok guys, let's circle up for the scrum. Joe, how about you go first?”

Joe: “Sure, yesterday I continued testing the shopping cart story and made it through the bulk of it. Today I should finish it and be ready to move on my next item. I have no blockers.”

Jenny: “Great. Sue?”

Sue: “Yesterday I made pretty good progress on the story to track inventory of items and automatically mark them as out of stock when we've sold the last one. There's still a good bit to do for this one though so I don't expect to finish it until tomorrow, at least. I have no blockers, either.”

Jenny: “Thanks, Sue. Pedro, that leaves you.”

Pedro: “Ok. Yesterday I wrapped up the data import of the next batch of new products and started work on importing our old customer contact list into the new app. This data is pretty messy, so it'll probably take me the rest of the day to wrap that up.”

What's Wrong?

At first glance, that may have seemed like a perfectly adequate Daily Scrum. The team circled up, talked about what they had been working on recently and what they would continue to do during the day. But, if you listened closely you may have noticed a common thread.

Each member of the team focused on a status update to their Scrum Master…not what they were actually doing to move their work forward.

Teams that are new to Scrum often fall into the trap of using the Daily Scrum as a simple status reporting meeting…especially if they’re transitioning from an environment where previously a large emphasis was placed on status reporting.

But, the Daily Scrum is much more than a status meeting. This ceremony is intended to be an opportunity for the team to synchronize and make a plan for the day about how they’ll work together to move closer to their sprint goal. In fact, just as the purpose of the Sprint Planning meeting is to give the team the chance to plan their work for the sprint to come, the purpose of the Daily Scrum is to give the team the chance to plan one slice of that sprint’s work for the day. But to do this, the team needs to shift away from simply reporting their status on their work each morning and instead shift their focus to what they’re doing to move their work forward that day. It’s only with this level of transparency can the team actually work together to plan their day’s work.

Let’s look at that same Daily Scrum again, but from this time from the perspective of treating it as a planning meeting…

Jenny: “Ok guys, let's circle up for the morning standup. Who would like to start us off?”

Joe: “I’ll go. Yesterday I tested the ability to add items to the shopping cart and it looks good. I still have a bit left to do, though, so today I’ll be testing the ability to remove items from the shopping cart and update the quantities of existing items. It looks like the product review story is ready to go so I’m going to plan to start that after I finish the shopping cart story.”

Sue: “My turn. Yesterday I worked on tracking the inventory of items and added the functionality to automatically mark an item as out of stock when the last one is sold. There are a lot of tendrils with this one though so I’ll be working through those today. The biggest one is understanding what happens when an item has already been placed in one customer’s cart but then goes out of stock when another customer completes their purchase. I suppose I’m a bit blocked on this since I don’t know how to handle that case….in fact, I’m not even sure how to test for that.

Joe: “I can help you with that. I’ll be doing something similar with setting up test cases to track item quantities across individual carts so let’s sync up after the standup to see what we can come up with so we don’t duplicate our efforts.”

Jenny: “Let’s also grab Dave this morning and pose this question to him. As our Product Owner, he may have already considered the case when a customer adds a product to their cart but doesn’t check out immediately and what impact that can have on inventory.  Maybe we're thinking about this all wrong and the idea is to deduct the item from inventory as soon as it’s in the cart. Let’s circle up with him this morning and get an answer before we go too deeply.”

Sue: “That sounds great, guys. Let’s do that.”

Pedro: “Ok, I suppose that leaves me. Yesterday I wrapped up the data import of the next batch of new products and started work on importing our old customer contact list into the new app. I was able to import the raw records pretty easily but this data is pretty messy, so I’ll be working today to figure out the best way to clean up the data and remove any duplicates. Joe, you mentioned that you were going to move on to the product review story today? Please let me know before you do…product reviews are always tied to customers and I’ll be truncating the customer’s table pretty frequently today as I try to get this import process sorted out. Please give me a heads up before you start so I can warn you each time I truncate it…otherwise you’re going to have a hard time getting anywhere with reviews when I’m constantly deleting your customers out from under you.”

What’s Different?

This is the same team, the same product, and the same day. They’re even describing the same pieces of work they’ll be tackling. So what’s different? Rather than just giving a simple status update for each item currently in progress, the team dove deeper into their actual plans for their work for the day which uncovered several opportunities for them to sync up and work more effectively together. In fact, in Pedro’s case this additional detail let him spot a potential problem where he and Joe would interfere with one another so they could plan accordingly.

By turning the Daily Scrum from a simple status meeting into an actual planning meeting for that day, the team was able coordinate much more effectively on the work in progress and significantly increase the odds that they can complete all of the work they planned for the current sprint.

How Do You Get There?

The shift from treating the Daily Scrum as a status meeting to treating it as a planning meeting is a powerful but subtle one, so it’s not always obvious how a team can do so. But, here are a few tips that can help.

  1. As the Scrum Master, discourage the team from reporting their status directly to you. The Daily Scrum is for the team’s benefit, not yours, so you’ll need to help your team understand this. If a team member seems to be looking at you while giving their update, try looking away to the Scrum board. This will communicate that you should not be the focus for the Daily Scrum and that the content should instead focus on the work represented on the board.
  2. Help the team learn to facilitate the Daily Scrum on their own without your prodding. At the very least, this means that the individual members of the team can keep the meeting moving without a need for you to call on each member. If your team struggles with this, then try to resist the urge to call on each member of the team simply to avoid an awkward silence between updates. If the silence is allowed to grow long enough between updates eventually someone will step in to fill the void. Once this has happened a few times the team will become much more adept at keeping the pace moving and avoiding these gaps.
  3. Although the Scrum Guide doesn’t explicitly specify what time of day the Daily Scrum should take place, teams that hold their Daily Scrums in the morning are much more likely to treat this ceremony as a planning opportunity than those teams who hold this ceremony in the afternoon. When a team meets for their Daily Scrum in the morning they have the entire day in front of them and are more likely to be in a planning mindset. But when a team meets in the afternoon the bulk of the day has passed so there’s little planning to be done. These teams are more likely to focus on the work already performed day and thus shift the meeting to a mere status report. Although this isn’t always possible, try to hold the Daily Scrum in the morning so your team is in a planning state of mind when they meet.
  4. Perhaps one of the simplest ways to coach your team away from treating the Daily Scrum as a simple status meeting is to discourage them from reporting on their recent work, altogether. The Reverse Standup, an alternative format for the Daily Scrum, was created to do just that. This format moves the “What did I do yesterday?” question to the end of question set and even makes it optional to downplay its significance. Try this format out with your team to help shift their focus from reporting on work that’s already happened to planning for work that’s next in the queue.

Building a Cohesive Team

The Daily Scrum is simultaneously one of the simplest and the most powerful aspects of the Scrum framework. But teams who insist on using it as a mere status meeting are barely scratching the surface of its potential. Encourage your team to make the shift to treating the Daily Scrum as a true daily planning meeting to help them work together more cohesively and deliver great products along the way.

Want to see more about how to make textbook agile work on real teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on The Daily Scrum is a Planning Meeting…Not a Status Meeting

Type on the field below and hit Enter/Return to search