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, 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.

Read more...

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, 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, Product Owner Fundamentals, 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.

Read more...

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 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.

Read more...
Reverse User Story

Putting Value First With The Reverse User Story

User Stories are a great way to translate your users’ needs into real tasks that your team can work with. They’re succinct, lightweight, and flexible. But what if you could make them even better by moving the “why” of the story to the beginning?

To understand how you can improve them even further, let’s start by looking at an example of a User Story…

User Story format

This format answers the important questions clearly, but it keeps the most important part of the story…the benefit…until the end. The benefit, or the “So I can…” part of the story, is how you ensure that your team understands why they are building this story and how it will contribute to your overall vision for your product. Without clearly stating this benefit you risk adding functionality that doesn’t move your product towards its vision.

Saving this part of the story until the end means that we ignore it or even leave it out completely. The result of this is that the benefit of the story is shortchanged.

Turning the Problem on Its Head

The Reverse User Story, on the other hand, moves this important clause to the beginning of the story.  This format, inspired by the Reverse Stand Up, recognizes that the benefit is the most important part of the story and therefore it should appear first.  Building on the example above, our Reverse User Story would look like this…

Reverse User Story formatMoving the benefit to the beginning of the story forces your team to first think about the business value and resulting benefits of your work. If you’re unable to articulate a benefit for a story then this can be a warning sign that you don’t understand the story as well as you thought you did. This may mean that the story still needs fleshing out or even that it may not be worth the effort required to bring it to fruition.

Finding Balance…Or the Zen of Release Management

Bringing the expected benefits to the forefront can also aide in long term exercises like Release Planning. For example, if the majority of stories selected for a release seem to have similar benefits then this can be a hint at the theme that’s emerging for that release. Alternatively, if too many stories have the same benefit then this can serve as a warning that you’re weighing the release too heavily towards one specific feature set while starving another.

Shifting the focus to the benefit can also help identify stories in the backlog that are duplicating value. Recall that one of the goals of Scrum is to optimize the ROI of the development team. To this end, if more than one story is accomplishing the same end goal then this can be an opportunity to drop a duplicate story in favor of another that may bring more value to the product.

Drawing in the Team

Bringing the business goals of the story to the forefront draws the team into the discussion.  This can even lead to the discovery of alternative approaches as to how those goals may be met.

For example, recall that the original idea of your story was to allow a customer to save items for later.  You’d assumed that the only way to do this was to make their shopping cart persistent.  But, perhaps someone on the team suggests instead providing a wishlist where the customer could store items for long term. This would result in the story being changed to…

So I can save items for later,
As a customer,
I want to add items to a wish list.

This change may even spawn additional conversations regarding the opportunities that the wish list could open up. Perhaps the customer could share their wish list with friends who are shopping for them.  Or, maybe they could even post them to their social networks. This would give you the opportunity to also capture sales from friends of the customer.  This could even happen when your original customer isn’t quite ready to buy an item themselves.

None of these ideas would have ever been suggested if the developers had not first been encouraged to consider the overall benefit they were trying to achieve rather than simply focusing on the action.

Putting This Technique to Use

Though a Reverse User Story has many advantages over the format it still may not be right for every situation.  Specifically, the classic format’s simplicity and broad adoption make it a good choice as a starting point for introducing the concept of User Stories to new teams.

But, if your team seems to be missing the bigger picture of the stories or is becoming mired in the details then this twist on the classic format may be just what you need to shift everyone’s focus away from specific actions and back to the overall goal of the product.

Want to learn even more neat techniques to get the most 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.

Read more...

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 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, Scrum Master Fundamentals, 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.

Read more...

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 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, Scrum Master Fundamentals, 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.

Read more...

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 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, Product Owner Fundamentals, 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.

Read more...

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 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, Scrum Master Fundamentals, 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.

Read more...

Stop Doing Experiments and Start Making Bets

Many teams have embraced the experiment mindset, which teaches that you can learn more from simply trying out an idea and seeing the results than you would ever learn from intense upfront analysis.

While this mindset can help your team make rapid gains, there’s also a dark side to this approach.  Although experimentation can yield faster and more in-depth learning than traditional analysis, many teams forget that some initial lightweight analysis can also be useful for helping them choose those experiments that are the most likely to succeed.  As a result, these teams embark upon poorly planned and risky experiments without first considering what they stand to gain…or lose.

The root of the problem lies in the word “experiment”.  By their nature, experiments can be very open ended.  This can make them a bad model for change since the lack of a defined end state can lead to a lack of clarity on how to proceed, or even a lack of understanding of what the team stands to gain from the experiment.

Playing the Game

A better model is a bet.  Imagine playing a game of poker but with no chips.  Without a need to commit chips then each hand becomes nothing more than a simple experiment with no potential upside or downside.  This means that you could play forever and still have no real investment in the game.

But adding chips to the hand changes the game.  When you’re working with a finite amount of chips you start to become very aware of the real possibility of gain and the real possibility of loss that hides in each hand.  

This forces you to weigh your options much more carefully.

Watch a great poker player play the game and you may be surprised at what you see.  Great poker players don’t play every hand…in fact, many even sit out more hands than they actually play.

Why?  Because great poker players know that they have a finite amount of chips and, if they want to play the game long enough for that big pay out, then they need to protect the chips they have.  This means that they evaluate each hand at the outset and decide if it’s a hand they stand a chance at winning.  If they’re not likely to win, then they simply bow out and wait for a better opportunity.  This is because they know that every hand has a cost, and the more bad hands that they pass on, the more likely they’ll still be in the game when those truly great hands come along.

Betting on Change

So should you abandon experiments altogether?  Not so fast.  A true embracement of an experiment mindset is one of the hallmarks that separates the best teams from the mediocre ones.  The difference, is that rather than simply diving headfirst into every opportunity, the best teams evaluate each of the possible experiments on their plates and choose to focus on those experiments that have the most potential for a positive upside, given the investment they’ll need to make.

For example, imagine that during the most recent retrospective your team complained that their Product Owner is not easily accessible throughout the sprint to provide feedback or clarification on items that are in progress.  As a result, your team has repeatedly found themselves reviewing items at the Sprint Review that turned out to not be what the Product Owner had in mind.  This means that they’ve had to invest additional time in the next sprint to rework those items, which has slowed the team down as a whole.

After a few minutes of brainstorming your team comes up with several experiments they could run which could help address the problem.  For example, maybe the Product Owner could appoint a proxy Product Owner on the team that would be empowered to provide feedback and make decisions on the Product Owner’s behalf whenever he’s unavailable.  Or, perhaps the Product Owner could make more of an effort to attend the team’s standup whenever possible so he’s available to provide feedback to the team as items are complete.  Of, maybe he could even keep regular “office hours” in the team room so he’s more accessible to the team a few days per week.

Placing the Right Bet

Any of these options could be worth pursuing, and when each is considered as an experiment they all look equally promising.  It’s only when we look at these options through the lens of making a bet do the tradeoffs between each become more clear.

The table below demonstrates a simple framework for evaluating different experiments through the lens of a bet.

Bet Potential Upside Potential Downside Odds of Success 
Proxy Product Owner Quick response to questions

Proxy may provide wrong responses leading to future rework

Proxy role becomes a distraction from that team member’s responsibilities

Unlikely
Product Owner attends standups

Slightly more availability to team

Quicker response to questions, if asked during standup

Greater impact on Product Owner’s time Possible
Product Owner office hours

Tighter collaboration with team

Quicker response to questions

Less impact on Product Owner’s time

Different way of working for Product Owner Likely

When a team starts to look at experiments through the lens of a bet, not only does the potential for gain become clearer, but they also better understand the investment that they’ll need to make to carry out each experiment.  This can help them better separate those experiments that are likely to fail from those that have a better chance of success so they’ll know where to focus their efforts.

Knowing the Cost

An experiment mindset can be a powerful tool for teams who desire to improve their way of working.  But, while experiments may appear to be free, few truly are.  Most experiments carry with them very real costs, but by evaluating the potential for loss or gain of each your team can focus on those experiments with the greatest likelihood for success…meaning that they’ll be around to play the game for a long time to come.

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.

Read more...
Capability Debt

Solving Capability Debt Within Your Organization

“We know it’s broken…but we don’t have time to fix it.”  “Yes, we know it could be better…but we’ll fix it when we get farther ahead.”  “Yeah, it’s not great…but there’s other things we need to deal with, first”.

If you write code then you’ve probably encountered codebases that have been described just like those phrases.  In fact, it’s such a common occurrence that there’s even a term for it: “Technical Debt”.  Technical Debt is used to describe code that is so hard to work with or so difficult to maintain that it slows down the overall progress of the team.

But, debt doesn’t just happen to your code…it can also happen to your process.  Ever had to track your time spent…across 3 different systems?  Or, have you ever had to create excruciating detailed documentation for a feature after it was written just to satisfy an arcane reporting requirement of your organization?  In either case, your organization was likely very aware of the waste that was incurred by the practice and probably even knew how to fix it.  Maybe they knew that it wouldn’t take much effort at all to write a simple integration for those 3 separate time tracking system that would let you track your time once and publish it to the other 2 systems.  Or, maybe they suspected that a feature’s test plan could perfectly fulfill that documentation requirement…if someone would only have the necessary conversation with the compliance team.

In fact, debt can even happen to your skills.  Have you ever performed a routine task for the 100th time but couldn’t shake the feeling that there’s probably a better way to do it…if you could only had the time to try?

Whatever the reason, if you’ve ever found yourself or your organization performing at a lower level than you should be…simply because you can’t find the time to invest in improving…then you’ve experienced Capability Debt.

Capability DebtCapability Debt can be thought of as any point of friction in your team’s software development flow that ultimately slows down the delivery of great software.  This could be redundancy within your organization’s process that the team must adhere to, regulatory overhead that the impedes the development process, or something that occurs in the act of creating software that everyone knows isn’t as good as it could be…but no one can find the time to fix.

Whatever the reason, the result is the same…wasted time and wasted effort in your team’s approach to delivering software to the market. But, just like Technical Debt, the answer is always the same whenever someone suggests addressing the problem…”we just don’t have time to fix that.”

In fact, often the situation is even worse than Technical Debt.  Since Capability Debt is often inextricably wound into the DNA of the organization itself, many teams assume that the there’s simply no way to address the friction that’s occurring so they don’t even try.

But, luckily there is a way to address Capability Debt, and if you’ve ever addressed Technical Debt, then the approach should sound pretty familiar.

What’s the Problem?

First, you need to identify the problem and it’s downstream result.  What is happening in the organization that’s slowing the team down and what effect is it having the broader organization?

In the case of the team tracking their time across 3 different systems, how much time is the team spending to do this?  Is there an hourly burn rate for that team that can can put a dollar value on this debt or is there lost opportunity in the sense of work that the team simply doesn’t have time to tackle due to the time lost?  However you measure it, there will be a cost involved with this effort.  Find out what it is.

Where Did It Come From?

Next, you need to determine how you got here. More often than not, Capability Debt is the outgrowth of some process that had a historical basis within the organization in the past, but is no longer applicable to how the organization currently functions. Understanding the origin of a specific piece of debt can be very helpful in understanding how difficult it will be to address and who can can help you do so.

Pay It Back

Finally, once you understand what the debt is and how it arose you can build a plan to remove it.  Maybe this will be a specific plan that addresses the debt once and for and all, or maybe this is just an experiment to try to solve the underlying issue that may or may not be successful.  Either way, just like with Technical Debt, once you can put a specific number on how much the debt is costing your organization then you’ll be more prepared to invest in a specific plan to remove it.

Solve It

Though Capability Debt arises from an organization’s overall process, it’s really no different than Technical Debt.  While there are often perfectly justifiable reasons why the debt exists, if it’s not dealt with swiftly then its effects will continue to eat away at your team’s productivity.  Investing in solving Capability Debt will keep your team performing at their top potential so they can keep delivering great software to market.

Want to learn more about solving common problems with delivery flow in your organization? Check out my course, Agile in the Real World, for tips and techniques for solving the most common impediments that you team may face.

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

Read more...
Load More
10 of 41