Jeremy Jarrell

Agile Made Simple

Can the Length of Your Iteration Change in the Middle of Your Project?

This post originally appeared on the PivotalTracker blog. Most agile teams work in iterations, especially those teams that follow a cadenced approach, such as scrum. And why not, since an…

This post originally appeared on the PivotalTracker blog.

Most agile teams work in iterations, especially those teams that follow a cadenced approach, such as scrum. And why not, since an iteration-based approach provides many advantages to teams. But while there’s little argument concerning the value of iterations, finding the right iteration length for a team is no small feat.

But, even after finding the right iteration length, some teams start to wonder if the length they once thought was so perfect is still the right choice for them. Perhaps they’re lured by the promise of the greater efficiency of longer iterations, or the greater responsiveness of shorter iterations call to them like a siren’s song. Whatever the reason, it inevitably begs the question: can a team change the length of their iterations in the middle of a project?

If your team happens to be pondering this same question, then you’ll be happy to know that the answer to this question is a resounding, “Yes!” It’s completely acceptable for teams to change the length of their iteration in the middle of their project and it actually happens more often than you might think. But while changing iteration lengths in the middle of a project can be done, it’s not a decision that should be taken lightly. Luckily there are a few things that can improve your odds of success if your team is considering heading down this path.

Preparing Your Team for the Change

Any change to how your team works will require time for them to absorb. This is true whether that change is the adoption of a new piece of the team’s technology stack, a new technical practice, or even a new team member. Even if the change is ultimately a positive one, don’t be surprised if your team’s output dips a bit while they become accustomed to this new way of working. This is especially true when changing your iteration length, since you’re fundamentally altering the timebox in which your team works.

The first thing you’ll need to do to prepare your team for this change is to help them understand how their planning activities will also need to change. For example, your team is probably conducting a planning session at the beginning of each iteration to select and plan their work for the upcoming iteration. And they’re also probably holding a review session at the end of each iteration to review their work and ensure that they’re on track to delivering what their customer needs.

If you are shortening the length of your iteration by half—e.g., from two weeks to one week—then you can expect that the duration of the accompanying planning and review sessions will also be shortened by half. For this to be successful, you must make sure your team understands that this shortened planning duration means that they’ll need to be more efficient during those sessions in order to accomplish everything they need to within the time allowed. A team that shortens its iteration length but continues to spend just as much time in planning sessions gains nothing and actually loses efficiency as now a smaller percentage of their time is spent actually producing value.

On the other hand, if your iterations are becoming longer, then you’ll need to prepare your team for the reality that they’ll now need to spend correspondingly more time in their planning and review sessions. For example, imagine that your team is currently working in two-week iterations but decides that three-week iterations are a better fit. If your team is currently spending four hours on the first day of each iteration planning their work for the next two weeks, then you’ll need to prepare them to spend roughly six hours planning their work on the first day of every iteration moving forward. While most teams will, at least superficially, understand the need for correspondingly longer planning sessions to accommodate the larger undertaking of work, *understanding* a six-hour planning session and *participating* in a six-hour planning session are two entirely different things.

Predicting the Result of the Change

But once you’ve prepared your team for this change, how do you understand the effects it will have on your project? A team’s velocity is often treated as one of the major indicators of a project’s success. And while we understand that velocity is not our goal, tracking a team’s trend in velocity over the past few iterations can be a powerful tool for forecasting the capacity that we can expect from that team in the future. But how can we predict the change in our team’s velocity after we’ve altered their iteration length?

It can often be tempting to simply extrapolate a team’s change in velocity based on the corresponding change in the team’s iteration length. For example, if your team has an average velocity of 50 points per iteration using two-week iterations, then it would stand to reason that that same team should produce 100 points per iteration using four-week iterations, right?

Maybe. Or, maybe not. Extrapolating a team’s new forecasted velocity based on the change in their iteration length may be a good place to start, but the actual effect of that change is rarely that simple.

A lot of factors can affect a team’s velocity from iteration to iteration, and the actual result of a change in iteration length may not be reflected in that team’s velocity for several iterations. This means that while your team’s velocity *will* change as result of a change in iteration length, *how* it will change will be tough to predict. For this reason, you’ll need to be prepared to expect the unexpected for the first few iterations under the new length as well as be prepared to account for this change in velocity in your longer term project planning.

Making the Most of the Change

While you won’t want to alter your team’s iteration length on a regular basis, the occasional change can be not only successful but even a very positive change for your team.

However, this change shouldn’t be taken lightly and your team will need your help to make it successful. By preparing your team for a change in iteration length using the tips above, you can help ensure they make the most of this new new change to their workflow.

Want to learn more about how to make agile work with your team when things don’t go as expected? 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 Can the Length of Your Iteration Change in the Middle of Your Project?

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

3 Simple Things Scrum Masters Can Do To Improve Their Craft

Getting started as a Scrum Master can be pretty easy. Take some time to read the Scrum Guide to learn the mechanics of the framework, watch a few videos to…

Getting started as a Scrum Master can be pretty easy. Take some time to read the Scrum Guide to learn the mechanics of the framework, watch a few videos to go deeper into the role, and then perhaps attend a certification course to learn how to apply these principles in practice.

But even though getting started as a Scrum Master can be relatively easy, the next steps in your journey to becoming a great Scrum Master often aren’t so clear. How do you learn to handle the tough situations that will inevitably arise day-to-day? Or how do you learn to step out of your daily responsibilities and see the bigger picture of how your team is evolving? And finally, how do you ensure that you are growing as a Scrum Master so that you’re continually improving in your quest to help your team become more effective?

Achieving these more advanced goals often isn’t as easy as getting started, but lucky there are some simple practices that can help you take those next steps.

Find Your Tribe

One of single the most effective things you can do to become a more effective Scrum Master is simply to interact with other Scrum Masters. Spending time with other Scrum Masters can reveal a wealth of information, practices, and resources that you may not have been aware of. You’ll be exposed to new perspectives on how to handle common problems faced by Scrum teams and you might even gain insights into how your own practices and behaviors are perceived.

But how do you do this? The easiest way is to simply invite other Scrum Masters in your organization to a regular session in which everyone can meet and share their experiences with their own Scrum teams. A morning coffee chat or even a Friday afternoon session to unwind at the end of the week once per month both work well for this. The only rule is to make it a regular occurrence at a time when everyone can attend without feeling rushed.

Once your group is together, take the opportunity to share recent experiences and developments that have affected your team as well as how you handled them. Then ask if anyone in attendance has encountered similar situations and, if so, how they handled them. You might learn some new approaches to handling the situation should you encounter it again. In addition, if there are others in attendance who haven’t encountered the same situation then they will not only be better prepared to recognize the same situation but they will also have a few tools in their toolbox to handle it when it occurs.

But what if you’re the only Scrum Master in your organization? Maybe you work for a small organization or maybe your organization has just begun its Scrum journey and yours is the first Scrum team on the ground. What do you do then?

In that case, try to find other Scrum Masters in your local area with which you can establish the same standing meeting. Perhaps this is a coffee chat early one morning or lunch at a convenient location one day per month.

While it’s true that Scrum Masters from outside of your organization may not have the same insights into your organization’s unique culture and dynamics, you may find that these same Scrum Masters bring a fresh perspective to your problems simply because of different approaches that they’ve tried in their own organizations. Simply becoming aware of the challenges and experiences of Scrum teams in another organization can open your mind to perspectives and practices that you may not have even considered.

Start a Scrum Master’s Journal

The next practice is even simpler. Go to your favorite bookstore and buy a nice journal and pen. Then every day, at the end of the day, take 10 minutes to write down the day’s experiences.

A great model for this is the Sprint Retrospective that you’re already engaging in with your own team, but from the perspective of your own daily interactions.

Record what you did in your role that day that seemed to have a positive effect on your team and what that effect was. Then record anything that occurred that didn’t go as well as you would have liked. And finally, consider whether there is anything that you’d like to try differently tomorrow.

I would also suggest that you make a note of any major events that occurred during that day, such as key developments that occurred with your team or important events that occurred within your organization. This will help you better understand the context of your notes as well as any external dynamics that may have been affecting your team when you revisit your notes in the future.

Taking a mere 10 minutes at the end of each day to perform a bit of introspection can be incredibly powerful. Not only will this help improve your awareness of your own actions and what effects they have on your team, but it will also help you start to better identify patterns that seem to be affecting your team and better equip you to intervene when you spot those patterns occurring.

Find a Mentor

Interacting with other Scrum Masters will expose you to new perspectives that you may not have previously considered. And starting a regular habit of journaling will help improve your self-awareness of your own behaviors and how those behaviors may be affecting your team. But what about the truly tough problems that you’ll face as a Scrum Master? What about those challenges that are not only facing your team, but also your own growth as a Scrum Master? For that, you’ll need the one-on-one interaction of a mentor.

A great mentor can help illuminate the path on your journey to self-development, act as a sounding board as you work through some of your toughest challenges, and even help you spot possible pitfalls that may lie in wait on the path ahead.

Many Scrum Masters have found that regularly participating in a structured mentoring session on a weekly or monthly basis has been one of the most impactful experiences of their career. But where do you find someone to fill the mentorship role for you?

Many senior Scrum Masters are often willing to serve as a mentor to those who are more junior not only because it can be so personally rewarding, but also because serving as mentor can often be an incredibly illuminating experience, as well.

However, if a more senior Scrum Master is not available then many agile coaches are often more than happy to serve this role. Or, if you’ve taken part in a formal Scrum Master training course then consider reaching out to your Scrum trainer as many trainers are happy to continue their relationships with their students beyond the classroom in this same capacity.

But, barring that, many coaches and Scrum Masters are also happy to engage in virtual mentoring arrangements. In these arrangements, a mentor will regularly engage with you in a virtual setting, often working through a very structured and productive mentoring relationship using video conferencing and other collaboration software.

Putting This Into Practice

Regardless of how you start, regularly interacting with other Scrum Masters and engaging in a broader practice of introspection and increased self-awareness will pay tremendous dividends for your growth as a Scrum Master.

You owe it to not only yourself but also your team to begin investing in improving your craft as a Scrum Master by putting these ideas into practice today.

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 3 Simple Things Scrum Masters Can Do To Improve Their Craft

The Best Books to Help Scrum Masters Sharpen Their Skills

So you’ve found yourself in the Scrum Master role with your first team and are wondering where to start. Or, maybe you have a certification or two under your belt,…

So you’ve found yourself in the Scrum Master role with your first team and are wondering where to start. Or, maybe you have a certification or two under your belt, have already worked with a few teams, but are looking for ways to sharpen your skills even further.

Luckily for you, there have been some great books written for Scrum Masters over the past few years. Nearly all of these books are good, but there have been a few that will really help you take your skills to the next level. These books are listed in a specific order that tracks the milestones most Scrum Masters progress through on their journey to becoming a great Scrum Master. To get the most out of these books, I suggest that you work through them in this same order.

Let’s get started…

The Scrum Guide

Surprised? Many people are often taken aback when I recommend such a basic reference book. However, I’m often caught off guard at how many practicing Scrum Masters haven’t actually read the Scrum Guide.

The Scrum Guide is the main touchstone for the rules of the Scrum Framework which you, as the Scrum Master, are responsible for ensuring your team is following. At only 17 pages long, the Scrum Guide can easily be read in an evening, but fully internalizing its content may take much longer.

However, the brief and succinct format of the Scrum Guide can be quite helpful. The Scrum Framework is often accompanied by many complementary practices, such as user stories or planning poker. However, while helpful, did you know that these practices are not actually part of the Scrum Framework?

This is because the creators of Scrum so erred on the side of a lightweight and non-prescriptive framework that many of the practices at are now synonymous with Scrum were explicitly omitted from the Scrum Framework. Reading the Scrum Guide will help you better understand what is part of the Scrum Framework and what isn’t so you can help your team cut through the noise to what actually matters.

Scrum Mastery by Geoff Watts

Once you’ve reacquainted yourself with the rules and values of the Scrum Framework you’ll be better equipped to understand how those values can play out in your organization.

This is where Scrum Mastery comes in. Scrum Mastery uses a scenario-driven format to illustrate specific approaches that a Scrum Master can use to be more effective in their role. It also demonstrates many of the most common challenges a Scrum Master may encounter in their role and then shows possible solutions to work through those challenges in the most productive way.

If you’ve built a good understanding of the basics of the Scrum Framework and your role within it, then Scrum Mastery will help you put those skills into practice.

The Great Scrum Master: #ScrumMasterWay by Zuzana Sochova

Once you’re ready to add some more advanced tools to your Scrum Master toolbox, The Great Scrum Master is a great place to start.

This book is full of practical advice and practices that can help any Scrum Master become more effective in their day-to-day role. Whether you need help getting to the root cause of a pesky problem that continues to afflict your team, understand why certain group dynamics seem to be emerging in your team time and time again, or just start to identify what types of tools might be appropriate for the problem at hand, The Great Scrum Master is full of a wealth of concrete practices that you can start putting to work with your team immediately.

Becoming a Catalyst: Scrum Master Edition: Using Everyday Interactions to Accelerate Cultural Change by Len Lagestee

We’ve talked a lot about the fundamentals of the Scrum Framework as well as what practices you can use as a Scrum Master to help your team. But, we haven’t talked about how to think about your daily interactions as a Scrum Master. This is where Becoming a Catalyst comes in.

This books gives you the tools to make the most of each of your day-to-day interactions both with your team and your broader organization. It provides guidance on how you can build support for your goals for your team, strengthen your relationships with your co-workers, or even gain insights into where trouble may be brewing ahead.

We frequently talk about the “softer side” of becoming a Scrum Master and how useful strong communication skills can be, but there’s often a gap of resources specifically designed to help grow those skills. Becoming a Catalyst fills that gap.

Coaching Agile Teams by Lyssa Adkins

The inclusion of a book so obviously focused on agile coaching may surprise you. But, effective Scrum Masters know that one of the most important ingredients to their team’s success is their own coaching skills. Whether you’re helping your team better understand the practices and values of the Scrum Framework, improve in a specific area of delivery, or even just work together more effectively great Scrum Masters are also great coaches.

But what’s that you say, you’ve never been trained as a coach? Don’t worry Coaching Agile Teams will give you the tools you need to help you coach more effectively both at the team level as well as within your broader organization. If you’re ready to take the next step in your Scrum Master journey and begin actively coaching your team, then this book will help show you the path.

Putting These Books to Use

While these are my favorites, they’re just a taste of the wealth of information available today for Scrum Masters. But getting value out of these books takes more than simply reading them and moving on. To truly get value out of this material you need to carefully read these books, identify and internalize the practices they espouse, and then look for opportunities to put these practices to work with your team. This is because only by actively applying what you’ve learned can you move your team, and yourself, forward.

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 The Best Books to Help Scrum Masters Sharpen Their Skills

Becoming A Non-technical Scrum Master

If you work in the tech industry then you’ve no doubt noticed the recent explosion in demand for qualified Scrum Masters. But, what’s more interesting is the surge in interest…

If you work in the tech industry then you’ve no doubt noticed the recent explosion in demand for qualified Scrum Masters. But, what’s more interesting is the surge in interest from individuals hoping to fill these positions who are coming from outside of the tech industry. In fact, in the last month alone I’ve received several questions from individuals without a technical background who are interested in becoming a Scrum Master. While the background of each individual is different, all of the emails end with a common question: “Can someone who doesn’t have a technical background find success as a non-technical Scrum Master?”. While opinions on this may certainly differ, I’m thrilled to say that in my experience the answer to this question has been a resounding “Yes!”.

Learning The Skills To Be A Great Scrum Master

While there’s no question that having a strong technical background can be advantageous to becoming a successful Scrum Master, it’s in no way a requirement. In fact, some of the best Scrum Masters that I’ve ever worked with have come from completely non-technical backgrounds.

So, if a technical background isn’t a requirement for becoming an effective Scrum Master, then what is?

The Scrum Master role is all about fostering collaboration across your team. And to do this effectively you need to be able to build connections with others and communicate with them in a way that makes sense to them. Therefore, great Scrum Masters need to be great communicators and understand how to adapt their communication style to a variety of situations and individual preferences.

Teams who are new to the Scrum framework are often skeptical of the number of ceremonies and artifacts that are required to adhere to the rules of the framework. It’s your responsibility as a Scrum Master to communicate the value of each of these ceremonies and artifacts in a way that resonates with each member of your team so that everyone is on board with fully participating in the framework.

In addition, great Scrum Master have a knack for setting short-term goals with their teams and then visualizing the steps necessary to reach those goals. In this way, the Scrum Master helps their team understand the value of each of their sprint goals and helps them build a plan to reach those goals.

But What About Technical Skills?

Both of the skills mentioned above are non-technical in nature, meaning that anyone from any background could be capable of employing these skills successfully. But, does this mean that there are no technical skills required for becoming a great Scrum Master?

Not exactly.

Truly effective Scrum Masters also possess a deep understanding of how their organization delivers software. However, this is not the same thing as being a skilled software developer. Great Scrum Masters have a clear mental picture of all of the steps their organization takes to deliver an increment of product to market and how each of those steps fit together. This doesn’t mean that the Scrum Master understands every line of code used to bring a product to life, or the specific nuances of each step of the product’s deployment pipeline, but they do understand how each step of that process fits together and how changes to one step can affect other steps.

In addition, while they may have a deep understanding of their organization’s software development process, they also understand that their organization’s process is almost guaranteed to differ from another organization’s process…and that this difference is ok.

The goal of understanding their process is to better position them to spot impediments that could be affecting their team, especially those impediments that their team may not even see themselves. And another goal is to help them to spot opportunities to improve and optimize that process so their team can deliver software more effectively.

So while some level of technical understanding is necessary, the good news is that this level of understanding can be learned on the job by anyone willing to invest the effort to do so.

Finding Success As A Non-Technical Scrum Master

But despite the skills above, a large part of your success as a non-technical Scrum Master will depend on how willing your team is to accept a Scrum Master from a non-technical background.

For some teams, this won’t be an issue. They’ll be happy to have the aide of a great Scrum Master and won’t care about your level of technical chops…or lack thereof. For others, however, this may be more of an issue.

For some teams, a Scrum Master from a non-technical background may need to work a little harder to gain their team’s trust. This can be particularly true for teams who are new to the Scrum framework and are already a bit skeptical of the Scrum Master’s role to begin with. But don’t despair, if you find yourself in this situation all hope is not lost.

When working with a team whose trust you may have to work harder than usual to earn, your first order of business should be to invest in building strong relationships with each individual on the team. This can pay huge dividends since people whom you have strong relationships with will be more likely to support and follow you as you begin to drive change in your role. Or, even if they don’t always agree with you, they’ll at least be less likely to publicly detract from you when they disagree.

But beyond this, you must also work to really learn the skills and responsibilities that are expected of a Scrum Master. And then, make a visible effort to put these same skills to work bettering the lives of your team.

As mentioned above, it’s not unusual for teams are who are new to the Scrum framework to also be skeptical of the Scrum Master role in general. Often this skepticism is rooted in a general lack of understanding of purpose of the Scrum Master role as well as the value that this role can bring to their team.

But, by working to truly develop the skills of an effective Scrum Master you’ll not only start to show your team how you can add value to their work but you’ll also demonstrate that the Scrum Master role is a craft of it’s own that requires a commitment to mastery comparable to their own roles and therefore worthy of their respect.

Beginning Your Journey To Becoming A Great Scrum Master

So, you’re confident that you can become a truly effective Scrum Master even without a technical background but you don’t know where to start? Luckily, getting started is easier than you think.

First, there are a wealth of books and online courses available to help you deepen your knowledge of your craft and to teach you the specific skills you’ll need to be successful. Becoming an effective Scrum Master is a career-long pursuit and there’s always more to learn, but luckily you’ll never be at a loss for inspiration.

Second, finding an experienced Scrum Master who can serve as a mentor can be an incredibly effective way to accelerate your own growth as a Scrum Master. A great mentor can give guidance as to what materials or learning would be most appropriate for where you are in your journey, provide insight and advice to problems that you may be facing based on their own experience with similar problems in the past, or just act as a sounding board and listen encouragingly as you reason out the best approach for yourself. If you’re looking for a mentor, a great place to start are the more experienced Scrum Masters in your own organization, Scrum Masters from outside organizations that you may encounter at local user groups or conferences, or even those Scrum Masters who can provide coaching and mentoring remotely via the internet.

And finally, jumping into your role with both feet is the most effective way to quickly find success as a Scrum Master. Truly effective Scrum Masters are great communicators and great facilitators, but above all, truly effective Scrum Masters are great problem solvers. This is because every situation you’ll face will be different and therefore the problems you’ll face with one team will differ from the problems you’ll face with another team. Great Scrum Masters don’t have all the answers, but they excel at putting their problem solving skills to work to find those answers. And there’s no better way to do this, then to dive headfirst into your first team and start solving these problems for yourself.

Are you ready to take the first step in your Scrum Master career? Or, are you an experienced Scrum Master whose 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 Becoming A Non-technical Scrum Master

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

My Team Works Hard But We Never Seem To Finish. Why Not?

We’ve all experienced this. Your team seems to be working hard. In fact, you know your team is working hard because you’re right there in the trenches with them. But,…

We’ve all experienced this. Your team seems to be working hard. In fact, you know your team is working hard because you’re right there in the trenches with them. But, no matter how hard your team works, they never seem to actually get anything finished.

If this sounds familiar, then you’re not alone. Most teams face this problem at some point in their development. However, despite how common this problem is it’s actually quite easy to overcome.

Why It Happens

To overcome this problem you first have to understand why it happens, in the first place. Most often this is due to two reasons.

First, it can happen because your team is accepting work from outside of the Sprint. This is the “can’t wait” work that wasn’t planned for during your team’s Sprint Planning, but reared it’s head after the Sprint has begun. Sometimes this happens because the Scrum Master is unable to head off a major stakeholder. Or sometimes the Scrum Master simply can’t make that stakeholder understand the impact that this new work will have on the team’s outcome. Or even other times, the Scrum Master may not even be aware of the unplanned work, in the first place.

But regardless of the reason, if your team is spending time working on unplanned work instead of the work they had planned for the Sprint, then they may look busy but they’re unlikely to finish what you expect them to.

Second, it can happen because your team is working on too much work at once. This can be counter-intuitive at first, but if your team decides to tackle all of their work at once then the team will make surprisingly little progress on any of their work. This is because the team’s total effort will be spread across a much wider surface area resulting the in team making very little forward progress.

In addition, on many teams when the amount of work in progress is not closely tracked, it can be common for some individuals to begin work on one item and then move to a second item before the first item is complete. Once again, this can create an image of very busy individuals on a team, but with very little actual work in result.

Luckily, there are solutions for both of these situations that will get your team back on track and back to finishing the amount of work that you know they’re capable of.

Make It Visible

In the first case, where the team is continuing to work on items outside of the Sprint, work with your team to craft a clearly defined Sprint Goal that describes the goal that the team should accomplish with the work in the next Sprint. Once your team is in agreement about the goal, share the goal with your stakeholders so that everyone understands what your team plans to accomplish during the next Sprint and how this Sprint Goal contributes to your overall product goals. Then, when outside work begins to appear during the Sprint, you can work with your stakeholders to evaluate how that work maps to the goal the team has selected for the Sprint and what effect accepting the work may have on that goal.

If you’re still unable to prevent the work from being worked on during the Sprint, then make a special effort to estimate the newly accepted work and add it the Sprint board. You can even dedicate a reserved row of the Sprint board for this type of work, or use a different colored card so the unplanned work is immediately obvious. This visual differentiation will make visible the impact that the unplanned work is having on the work that was originally planned in pursuit of the Sprint Goal. In addition, the estimated points will allow you to better communicate to your stakeholders during the Sprint Review what percent of the team’s effort was spent on work that didn’t directly contribute to the Sprint Goal.

Both of these actions will help your stakeholders stop thinking of the Sprint as an empty bucket that work can simply be poured into, and instead begin to think of the Sprint as a strategically planned batch of work that moves the team closer to a stated goal.

Limit Your Throughput

In the second case, where the team is working on too much work at once, work with your team to establish work in progress limits, commonly known as WIP limits, on the key states of your Sprint board.

A WIP limit restricts the number of items that can be in a given state at any time. For example, in the image below, a WIP limit of 3 has been assigned to the Development column and a WIP limit of 2 has been assigned to the Testing column. This means that at any given time, no more than 3 items can be in development at one time and no more than 2 items can be in test at one time.


What happens if the WIP limit is reached? Then your team must work together to figure out how to complete the items in the column where the limit has been reached to make room for new work, thus allowing more work to flow through the process.

For example, imagine that a developer on your team completes the an item and attempts to move it to the Testing column. However, the Testing column has already reached its limit. The developer must work with your team’s testers to understand how they can help clear the existing the items from the Testing column. This may mean that the developer needs to assist the tester with their work so they can complete the items currently waiting to be tested, or that that team as a whole needs to make a greater investment into automated testing so that the testing process is more efficient overall. Regardless of the solution, the new item cannot be added to the Testing column until the existing items have been cleared.

While at first, WIP limits may seem as if they would cause a team to move slower, the opposite is actually true. WIP limits incentive your team to move work to completion, rather than to simply start it. This results in more work being completed by your team which allows them to reach their goals faster.

Focus on Finishing

Many teams look busy but surprisingly few actually complete the amount of work that may be expected of them. But, by defining clear goals for each Sprint that your team can aim for, and then incentivizing them to focus on finishing the work required to complete those goals, you can ensure that your team actually delivers the value that your stakeholders expect.

Do you want to learn more about how you can help your team deliver work more efficiently? 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 My Team Works Hard But We Never Seem To Finish. Why Not?

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?

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