bets-versus-experiments-jeremy-jarrell-com

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

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

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

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

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

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

Jenny: “Great. Sue?”

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

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

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

What’s Wrong?

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

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

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

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

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

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

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

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

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

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

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

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

What’s Different?

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

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

How Do You Get There?

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

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

Building a Cohesive Team

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

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

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

Read more...
finish-line

Choosing the Right Sprint Length

One of the most common questions facing teams that are new to Scrum is “What’s the best sprint length for us?”.  Although this question can seem daunting at first, there’s actually a simple way to arrive at the right answer for your team.

The Scrum Guide places an upper limit of one calendar month on sprint length.  And although there is no “official” lower limit, 1 week is most commonly accepted as the shortest duration that a sprint can last and still be effective.  This gives us a window of 1 week to 1 month for valid sprint durations.

So, how do you find the length that’s best for your team?  The simple answer is that the best way is to experiment until you find the length that allows your team to deliver in the most predictable manner.

Beginning the Experiment

To begin, start your team running in 2 week sprints and continue this length for a few sprints.  If you find that your team either consistently misses their forecasted velocity or that they’re often unable to hit the sprint goals set out at the beginning of each sprint due to unexpected developments during your sprint, then your sprints may be too long.  In response, try shortening your sprints to 1 week in duration to see if they’re able to more consistently meet their forecasted velocity and deliver their sprint goals.

On the other hand, if you find that your team consistently meets their forecasted velocity and delivers their planned sprint goals but they struggle to make meaningful progress on the product in each sprint, then your sprints may be too short.  This is a common problem that can affect teams working in very complex domains where significant time is required to advance the product in meaningful increments.  If this sounds like your situation then experiment with lengthening your sprint to 1 month to see if that better enables your team to deliver a meaningful increment each sprint.

And, of course, if neither of these problems seem to be afflicting your team then you’ve likely discovered that a 2 week duration is just right for your team.

Tuning the Sprint

finish-lineA general rule of thumb when working with Scrum teams is that it usually takes 4 sprints for a team to fully assimilate any new practice or behavior.  If after 4 sprints a team is still struggling with a new practice, then it’s unlikely that the team will ever find success with that practice.  This is often more of an indication that the practice simply doesn’t fit with how the team works best rather than a reflection on the team, themselves.

We can apply the “4 Sprint Rule” in this context, as well.  If a team has found the sprint length that’s right for them then by the 4th sprint their velocity should have normalized to the point where it can be reasonably well forecasted and they should have established a history of successfully delivering their stated sprint goals.

Knowing When Good is Good Enough

Once a team reaches this state the time that they invest in process improvement will be better spent exploring ways to improve the work that happens inside of the sprint itself, rather than continuing to invest in tuning the sprint’s overall length.  Although there is a tendency with new Scrum teams to want to continuously evolve towards shorter and shorter sprints teams should be wary of falling into this trap.

Continuously changing sprint lengths can wreak havoc with a team’s velocity forecasts making longer term planning unnecessarily difficult.  The effects of these changing sprint lengths are often not as simple as a “a team who delivers 50 points in a 2 week sprint should deliver 25 points in a 1 week sprint, or 100 points in a 1 month sprint”, therefore changing the sprint duration often requires several more sprints of observation to see where the team’s new “normal” velocity lands.

It’s not out of a question for a team to begin a new project that has a high amount of unknown using 1 week sprints before eventually transitioning to 2 week sprints as the project becomes more stable.  However, such duration changes should not be taken lightly as they can have significant impacts on a team’s overall cadence.

Discovering the optimal sprint length for your team may take time but will significantly improve the team’s overall performance.  Make the investment in finding the sprint length that best suits your team and encourage the team to stick with that length once they’ve found it.

Want to see more about how to get 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.

Read more...
Refinement

What’s the Right Amount of Backlog Refinement?

Many teams struggle with getting the right level of detail in their backlog.  If the backlog is too vaguely defined, then the team picks up stories that aren’t immediately actionable which can slow them down.  On the other hand, if the backlog is too well defined then it becomes rigid and fails to evolve as the product takes shape.  It can even stifle the creativity of the team as they try to find the best option for achieving each outcome.

So, how do you strike the right balance when creating your own backlog?  In his excellent book Scrum Product Ownership, Bob Galen introduced the 20/30/50 Rule for product backlog refinement to address this very problem.

Here’s how it works…

The First 20 Percent

20% of the stories on the backlog should be well refined and ready to be picked up at any time.  These are the stories that are immediately actionable that your team can begin work on with little hesitation.  You and your team will need to agree on exactly what makes a story actionable for them, but here are a few options to consider as a starting point….

  1. Each story has a stated objective and corresponding business justification.  While this is often expressed in the popular format “As a…., I want…., So that…” format, the specific format isn’t important as long as the team knows what they’re trying to accomplish and why they’re trying to do so.
  2. Each story has defined acceptance criteria to give the team a clear and unambiguous picture of what the end state of the story should look like.
  3. Each story meets the agreed to Definition of Ready established by your team.  If your team has yet to establish their own, then the INVEST criteria is a good place to start to consider which qualities of stories are important to your team team which may not be as important.

The Next 30 Percent

RefinementThe next 30% of the stories on the backlog aren’t ready to be picked up by your team, but are in a good enough state that you as the Product Owner can have a discussion about these stories with your team and stakeholders to decide when these stories should be worked on…if ever.  

Expect these stories to contain no more than an objective and business justification and to be sized larger than the first 20%.  In fact, it’s not uncommon for many of these stories to simply exist as unrefined epics.  The goal for stories in this bucket are to pin a specific idea to the backlog so that it’s not lost as well as to facilitate a discussion around when it would make sense for the team to invest in tackling that story.  If the story is not specific then this discussion will meander and won’t be productive, but, if the story has already been too well defined then the creativity that would otherwise emerge from that discussion will be stifled.

The Final 50 Percent

The final 50% of stories are the least refined of them all.  These stories tend to be largest stories on the backlog and exist only as vague ideas of things the team would like to consider for the future.  If the previous set of stories tend to be at the Epic level, then these items are the Themes of your backlog.  

These stories are not ready for a team to work on and really aren’t even ready for a team to discuss.  Instead, these stories exist as placeholders for the Product Owner to periodically evaluate whether they still make sense for the direction of the product and, if they do, to begin to introduce them to the discussion.

Finding What Works

Structuring your backlog according to these rules of thumb will help you strike the balance between items that your team can be productive with immediately and items that still deserve more refinement.

Depending on your team and your product, you may find that you need to tweak the percentages to optimize the backlog for what works best in your organization.  You may also find that you need to experiment with whether these numbers correspond to the total remaining story points in your product backlog or to simply the total number of remaining product backlog items.  As with most opportunities in agile, experimentation will be the key to finding what works the best for your team.

However you decide to implement it, the 20/30/50 rule gives you a nice guideline of how much of your backlog should be ready at any time while keeping the risk of over refinement at bay.

Want to learn even more ways to slice your user stories so your team can start working with them immediately? 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...
Chess

What, When, How: The 3 Levels of Strategic Agile Planning

When we think of agile, we often think of quick reactionary planning to the realities of a project as it unfolds.

For that reason, most discussions of agile planning focus on the short term. Our teams plan and synchronize at the daily level using recurring morning stand-ups. And, for those teams practicing Scrum, we plan at the iteration level using recurring sprint planning meetings.

Both of these practices are great for keeping a team on the same page tactically, but what about strategically?

Luckily, there are some simple techniques for aligning your team strategically as well as for helping them to think beyond the sprint.

Strategic agile planning comes down to three simple questions:

  1. What are we doing?
  2. When do we need it done?
  3. How are we going to get there?

The key is to remember that the answers to these questions will likely change as the development of your product progresses. But, by taking an iterative approach, you can keep your team on track to ensure that you deliver the right product at the right time.

So let’s take a look at these three questions in turn to see how each propels you down the path of creating a great product.

What are we building?

The most important decision that you need to make as a team is what are you building? But the question is often more complicated than that. Instead, the deeper question is what need should your product be solving.

One of the best ways to answer this question is with a visioning canvas. There are many variations of the canvas available, including the well-known Lean Canvas, but my personal favorite is Roman Pichler’s Product Vision Board.

Product Vision Board

The example that you see here is how a vision board for a streaming music service, named Ostinato, may look. Notice that the vision board starts at a higher level than the specific needs of the product and instead focuses on the overarching need that the product is trying to fulfill.

Some of the characteristics that you’ll discuss when creating a vision board include defining the specific user needs or market opportunity that the product is trying to fill, identifying the core user base that you’re targeting with the product, identifying potential competitors who may already be in the market, and discussing how the product will generate revenue.

The outcome of the visioning exercise is intentionally vague, as it is not used for planning the execution of the product, but rather to build alignment across the team of what the ultimate result of building the product should be.

Some teams refer to this exercise as “setting their North Star,” since the result is a guiding direction on where the team is heading without dictating the specific steps of how to get there.

Although your product vision is unlikely to change daily, you should expect it to evolve as you learn more about your target users, potential competitors and where your product can most effectively fit in the market.

For that reason, plan to repeat this exercise periodically to reevaluate core assumptions that you may be making about the competitive landscape, as well as to take a fresh look to help spot opportunities for growth.

To do this, a good rule of thumb is to repeat this exercise annually, though newer and more rapidly evolving products may benefit from a slightly more frequent cadence.

To get the full benefit from this session, you should expect it to be attended by the product’s executive sponsors, the relevant product management team and key technical representation such as the product architect.

Although members of the product delivery team such as engineers, testers and designers may benefit as well, be wary of growing the session too large and remember that the resulting vision may be more effectively conveyed to these team members by the architect and product manager after it’s complete.

When does it need to be done?

Now that you know what you’re building, the next question that you need to solve is when does it need to be done?

But, remember that you’re running an agile project, so rather than waiting until the entire project is complete, you’ll want to deliver in small increments to get as much feedback as possible along the way.

This combination of answering both when you want to deliver your overall product as well as how and when you want to make small incremental deliveries along the way will become your product roadmap.

Product roadmaps are high-level plans that show your product’s intended evolution over the next few releases. They show, at a high level, the overall strategic direction that you plan to take your product, as well as the different guide points along the way that will help get you there.

If the idea of long-term planning fills you with fear as images of Gantt charts dance in your head, don’t worry…there are better alternatives that we’ll discuss here.

Agile product roadmapping has become a hot topic in the past few years with several very nice tools coming on to the market. However, my favorite is still the free Goal Oriented Roadmap, or GO Roadmap, which was created by the very same Roman Pichler that I mentioned previously.

What sets the GO Roadmap apart is that rather than focusing on the features required for each release, it instead focuses on the goal of each release. This approach not only frees you from thinking about implementation details and sequencing too early, but it also leaves the responsibility to define the specific features of each release until a time when you know more about them.

GO Product RoadmapIn the example here, we’ve created a GO Roadmap for our streaming music service, Ostinato.  Notice that any features defined here are very high level and intentionally lack specific detail.

Forcing your team to define features too early often creates an unrealistic impression of certainty for your product and can even lock you into a less than optimal feature set too early.

Instead, thinking at a higher level about the overarching goals that each release should meet will free you to think strategically not only about the impact of each release, but also how the entire release cycle for the product fits together as a whole.

While your roadmap won’t change frequently, expect to revisit it more often than your product vision. If you’re revisiting your product vision once a year, then revisiting your roadmap quarterly would be a good rule of thumb.

To be effective, this session should include key technical personnel who can advise you to any technical dependencies or limitations that may affect the goals you’re laying out.

During each roadmapping session, your team should be focusing primarily on the release that’s immediately upcoming. While you’ll still want to leave time to discuss subsequent releases, expect that they will be more vaguely defined and more volatile as they’re farther out on the horizon.

GO Product RoadmapAs a rule of thumb, you should be able to draw a diagonal line from the last objective of the nearest release to the last objective of the farthest release showing how each release becomes progressively less defined as you move toward the horizon.

How are we going to do it?

The final piece of strategic planning is to lay out a plan for how your team will approach the next release. This is done with a tool that’s similar to the GO Roadmap we discussed previously, but with a more fine-grained feel.

While this release plan contains much of the same information found in your roadmap, it also adds lower level information such as a prioritized list features that will be tackled in each release.

Release PlanThese features can be prioritized by whatever means is the most comfortable for your team … as long as they are prioritized. I’ll often use the MoSCoW prioritization technique, which has the advantage that it allows for items to be explicitly removed from a release.

Expect to revisit your release plan after each minor release, which should occur more frequently than the major releases detailed on your roadmap. For example, if you follow a release cadence of a major release at the end of each quarter with minor releases at the end of each subsequent month, then you should expect to revisit your roadmap quarterly and your release plan monthly.  The goal is to create a plan that represents what your team is currently working towards as well as to give you an idea of what lies in the future.

Ideally, your entire team should be involved in this meeting as they will be the ones who will deliver the work inside of each release.

And, as with the roadmapping discussion, you should be focused primarily on the next upcoming release and expect subsequent releases to be progressively less defined as you move out to the horizon.

In fact, the guiding principle of drawing a horizontal line from the last feature in the next release to the last feature in the farthest release works just as well for release plans as it does for roadmaps.

Seeing the big picture

Strategic agile planning is as much of an iterative exercise as anything else that we do in an agile context. The secret is to realize that no matter how confident you feel in your overall vision today, it’s very likely to change as your product grows and your market evolves around it.

By taking an agile approach to your strategic planning, you can significantly increase the odds that the product you deliver will make the impact that you envision.

This post was originally published on the Front Row Agile blog.

Read more...
Blocker

The 3 Levels of a Scrum Master Removing Impediments

Often when someone becomes a Scrum Master the only instruction they are given is to “remove impediments”, but what does that even mean?

Impediments can come in many forms and have many effects on a team.  Some can simply slow a team down by slowly eating away at their progress one bite at time while others can stop a team dead in their tracks.  How successful a Scrum Master is at identifying and removing these impediments tells a lot about how they are growing in their role.  To dive deeper into this, let’s look at some of the most common types of impediments a team can face and how a Scrum Master can detect and remove them.

Blockers

Blockers are the classic stop a team in their tracks problems that most people tend to think of when they picture impediments.  Maybe the hard drive cracked on a tester’s laptop taking him totally out of action for the next 2 days.  Or, maybe a developer’s daughter suddenly became sick and she needs to leave early to pick her up from school.

BlockerWhatever the reason, blockers are often easy to spot because someone on the team grinds to a halt as soon as they occur.  In fact, these are typically the types of issues most people think of when asked “What’s in your way?” at the morning standup.  As a Scrum Master, it’s your job to listen to these issues and do everything in your power to clear these blockers so the team can keep moving forward.

Many of these you can probably address yourself, directly.  Is there a spare laptop somewhere a tester can work from in the meantime, or can he pair with another tester to test his stories in parallel?

Others, however, you may be able to do very little about.  Can the team work around the work in progress of the developer who suddenly had to be out of the office due to a family illness?  Or, can she work remotely while her daughter recovers?  You may have to stretch yourself to remove these issues, or you may have to get creative to help the team work around them while these issue are in their way.

Classic Impediments

Classic Impediments are a bit trickier.  These are the things that slow your team down but don’t necessarily ground them to a halt.  Often the team is aware of these issues but have become so accustomed to working around them that they have simply written them off as “that’s how things will always be”.  In some cases, the team may have become so used to these issues that they don’t even notice them anymore or have forgotten that they even exist.  Examples of common impediments include a team who is not empowered to make changes to their production environment in order to deliver new features or a team that has to frequently stop to correct merge conflicts as a result of dealing with an antiquated source control system that they don’t have the freedom to replace.

ImpedimentIt can take an adept Scrum Master to detect these impediments since the team has often become so used to dealing with them they no longer even bother to mention them at the daily standup.  Your job as Scrum Master is to first bring these issues to the team’s attention and remind them that they exist and are slowing them down.  Once the team has accepted these issues, though, impediments often aren’t as easy to remove as blockers.

This is because impediments are often more of a global, systemic issue that affects the team as whole rather than a single individual.  In addition, impediments tend to be more subtle artifacts that arise as a result of factors in your organizational structure or culture.  These can make them very difficult to remove.

While your first task as a Scrum Master may initially be to remove these impediments so your team can operate at their full potential, ideally your long term goal should be to empower your team to start to remove these impediments for themselves.  I’ve mentioned previously that impediments tend to be symptoms of deeper issues in your organization’s culture.  If this is the case then the team working to identify and address these impediments themselves will have a longer lasting effect than the Scrum Master swooping in to correct these issues for them.  This is because the most effective way to address deep organizational issues is for the organization to acknowledge and address these issues for themselves.  Even if the Scrum Master is also a member of the organization, simply fixing issues for others on the team often becomes more of a band aide than a meaningful change in behavior.

Landmines

The final type of impediment a Scrum Master may find themselves removing are the landmines and pitfalls that lie in wait for their team to trip over.  These can be the trickiest type of all since, unlike a classic impediment which the team may have once been aware of but has since faded to the background, they likely have never even noticed the landmines before.  Often these are issues that a Scrum Master recognizes only because he’s seen them befall similar teams in the past or because it takes a second set of eyes to notice them.

LandmineSome landmines a Scrum Master may spot but aren’t entirely obvious to the team at large include an aggressive functional manager over participating in ceremonies such as retrospectives or daily standups thus limiting the transparency or honesty that the team is comfortable sharing.  Or maybe daily standups moved from the morning to the afternoon turning them from an opportunity for the team to plan and synchronize at the daily level to a mere afternoon status meeting.  Or even a Product Owner who is overcommitted to multiple teams thus limiting their ability to effectively clear a path for any of them.  Note that in all of these cases while the presence of such a landmine isn’t a guarantee of disaster it can at least be a warning of possible issues to come.  It’s up to the Scrum Master to evaluate each situation in the current environment and determine how likely it is that the landmine will detonate at the worst possible time for the team or simply become a harmless dud that fizzles out before the team even blindly wanders past it.

To make things even tougher, it’s not uncommon for a team to be initially resistive when a Scrum Master first attempts to point out landmines to the the team.  This means that a Scrum Master must have a sensitive touch when coaching their team to identify and to remove this particular type of impediment.

As with classic impediments, it’s often best to coach the team to remove these impediments for themselves.  But, how you coach may depend on how open your team is to such issues.  If you find that your team is particularly responsive to learning about and addressing landmines then simply guiding them to identifying them with a series of leading questions may be quite effective.  On the other hand, if your team resists the possibility of such landmines due to a strong cultural bias or organizational gravity then you may be better off standing aside while the team sails towards the brink to help illustrate the possible downfalls of not addressing the landmines that lie in their path.  Although this approach isn’t ideal, often it’s only necessary once or twice before a team becomes more receptive to feedback on where the landmines may lay.

A Natural Progression for Scrum Masters

In all cases, how a Scrum Master progresses through identifying each type of impediment, removing it, and ultimately coaching the team to clear it for themselves are important steps in the journey from Scrum Master to coach.

Although we often describe the Scrum Master role as the one who must remove impediments for their team, it’s important to remember that true success with agile only becomes possible once the team has become empowered to identify and remove such impediments for themselves.

Want to see more about becoming a great Scrum Master? Check out my course, Scrum Master Fundamentals: Foundations, for tips and techniques to help your team perform at the highest level.

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

Read more...
cup-of-coffee-and-napkin-sketch

Why Your Minimum Viable Products Probably Are Not Viable nor Even a Product

Founders pay a lot of attention to Minimum Viable Products, or “MVPs”.  However, for all of the attention that’s paid there seems to be just as much confusion about what an MVP exactly is.

Despite the name, MVPs aren’t intended to actually be viable products.  MVPs serve one purpose and one purpose only…to validate a specific hypothesis.  Sometimes that means you need to release a product to the market to validate that hypothesis, but usually not.

cup-of-coffee-and-napkin-sketchWhat this means is that most early MVPs actually aren’t viable in the marketplace.  In fact, they’re usually not even products.

Let’s dive a bit deeper into this.  Often when you first begin work on your product the hypotheses that you’re validating are less about specific features that would be tested with a build and more about your overall product direction or business model.  These are the “would you pay for this questions” that underly all assumptions about your product from the outset.  And, these are the most important assumptions that you need to be validating with your early MVPs.

So, how do you validate these early hypotheses?  You do so with the most lightweight MVP possible…a conversation.  You don’t need a functioning app, or even a prototype, to be able to have an early discussion with a potential customer about the validity of your idea.  Often, you just need a list of questions and a sketch on a napkin.  If this list of questions and sketch helps you to test whether or not your hypothesis is valid then this is your MVP.

Could this list of questions and sketch be considered a product?  Probably not.  Would it be viable in the marketplace?  Absolutely not.  But, it’s well suited to validating the specific hypothesis that you have at that moment because this hypothesis is about your overall vision for your product and where it fits in the market…not about specific features.

Meet the MMP

So, if an MVP is not always viable in the market then what is?  The MMP.

An MMP, or Minimum Marketable Product, embodies what people often think of when it comes to MVPs.  An MMP is the smallest possible product increment that could conceivably be viable in the marketplace.

Is a list of questions and a napkin sketch a viable product in the marketplace?  No.  But the first build of that product containing the bare minimum of features may be.  Often when we discuss adding only enough features into our product to create an MVP, we’re actually referring to an MMP.

All MMPs are MVPs

We use MVPs to prove a hypothesis that we’ve set for our product.  Depending on the nature of that hypothesis our MVP may be a sketch on a napkin, a landing page that collects email sign ups, or even just a cup of coffee and conversation with a potentialmvp-mmp customer.  It doesn’t matter what form they take, as long as they can be used to validate a hypothesis and move your product forward.

Once our hypotheses have matured to the point that we’re now testing actual features our MVPs start to become viable product builds, often in the form of MMPs.  Although an MMP will be more refined than the MVPs described above it can be just as useful for validating a hypothesis about your product.  The point we must remember, however, is that shipping a full fledged product to validate a hypothesis will take much more time and effort than walking a napkin sketch to a coffee shop.  This means that we should always be asking ourselves if we’re using the absolute lightest weight MVP possible to validate that hypothesis.

Choosing the Right Path

In the end, it all comes down to the nature of the hypotheses that you wish to validate and where you are in your product life cycle.   Early hypotheses concerning your vision or market fit can be much more effectively validated using a simple MVP.  This is because their lighter weight and more malleable nature will allow you to get feedback sooner and more easily adjust course if you take a misstep.  Later hypotheses concerning specific features, distribution channels, or platform decisions may warrant the investment in an MMP.  But your goal is to delay that investment as long as possible until you’ve proven as many of your initial hypotheses as possible using other means.

Want to learn more about choosing the right features for each step of your release?  Check out my course Agile Release Planning on Front Row Agile to learn more.

Read more...
early-adopter

Beware Your Early Adopters

If you’re building a product then you want users…it’s that simple.  

And you want these users as soon as possible because the earlier you can get users, the sooner you can get start to get that feedback that will be so crucial to your product’s success.

These first users are your early adopters and the feedback that they provide will be instrumental in the early stages of your product.  But as much as you need your early adopters there’s one thing that you must remember about them:  your early adopters are not your mainstream users.

Sure, there may be overlap.  And sure, with any luck, some of your early adopters will grow alongside your product into your mainstream users as your product matures.  But, more often than not, early adopters are an entirely different breed than your mainstream users.

Inside the Mind of the Early Adopter
early-adopter

Early adopters tend to have different needs than mainstream customers.  On the surface, both groups may be solving the same problems but by their very nature early adopters are more adventurous and are willing to put in more of an effort to do so.  And, while everyone wants a great experience, early adopters tend to be more tolerant of the occasional bug or odd usability choice.

But there’s an emotional component at play here, as well.  Often early adopters are just as attracted to your product for the fact that it’s new as they are for the underlying problem that it solves.  This newness is exciting in its own right and, in large part, drives their use of the product.  But this “I used your product before it was cool” quality isn’t a quality that you can count on to drive usage as a your product matures.

Inside the Mind of the Mainstream User

Mainstream customers are less drawn to a product for its newness but are also less drawn by the product’s feature set.  Since this may be surprising, let me explain.  Mainstream customers don’t buy a product because of its specific features, they buy a product because of the specific problems it solves.  This doesn’t mean that all of the same features that were compelling to early adopters aren’t also compelling to your mainstream customers, but it does mean that these feature aren’t likely to be the deciding factor to whether they make the jump.

Expanding on this, your mainstream customers will have much mess tolerance for the same bugs and usability issues that your early adopters had.  Whereas your early adopters viewed rough corners and hiccups with your product as a fair trade for getting access to a new and exciting product early your mainstream customers won’t be so kind.  These users will expect a complete and polished product that functions out of the box.  And, to the same end, while an early adopter may be willing to invest some time fiddling with and configuring their own experience, a mainstream customer will want an experience that fits their needs on day one.

Making the Jump

So, why does this matter?  This matters because if you expect your product to grow you’ll ultimately need to make the jump from your early adopters to your mainstream customers.  The catch, however, it that the same qualities that appealed to your early adopters may not entirely align with the same qualities that will appeal to your mainstream users.  Therefore, you may have to make the decision to alienate some of your early adopters, who have been with since the beginning, in order to grow to the mainstream.

To this end, you’ll also want to be cognizant of catering too much to the early adopters in your roadmap.  You’ll want to measure every step of the way once your product hits the market but beware of blindly following those metrics.  Don’t double down on features or trends that have had a lot of uptake in your product by your early adopters but aren’t likely to appeal to your mainstream customers.  By the same token, evaluate judiciously the decision to drop any feature with little uptake by your early adopters that potentially may be a play towards the mainstream market.

Product development is a journey.  On that journey you’ll encounter many customers all with different needs.  Don’t forget your early customers and the lessons they taught you at the beginning but don’t become trapped by those same customers, either.  By learning to tell the difference between the needs of your early adopters and the needs of your mainstream customers you’ll know when it’s time to take the next step in your product’s journey.

Want to learn more about how to grow your product from inception to the mainstream?  Check out my course Agile Release Planning on Front Row Agile to learn concrete strategies for planning your product’s evolution.

Read more...
A quintet of vintage hanging light bulbs over a dark brown background

Get More out of Your Sprint Review

Is your Sprint Review just a dog-and-pony show for your stakeholders?  If so, then you may be missing one of the most valuable aspects of the Scrum process.

It’s Not a Demo, It’s a Review

The root of this problem often lies in the habit of referring to the Sprint Review as a “demo”.  Demos are one-sided meetings where the team walks through the highlights of the product in a carefully scripted manner to a disinterested set of observers.

Reviews, on the other hand, are hands-on conversations between the team and stakeholders to discuss the work they’ve done so far and how it matches the stakeholder’s intent.  A good review lets stakeholders test drive the work the team has done so far in as close to a real-world environment as possible.  Only then will the team get the feedback it needs to adapt their plan moving forward to deliver a great product.

So, how do you ensure that you’re making the most of this opportunity?  Here are a few tricks to help you out…

Get the Right Feedback

Believe it or not, many stakeholders are just as uncomfortable in their first review as the team is.  Some mA quintet of vintage hanging light bulbs over a dark brown backgrounday worry about hurting the team’s feelings after a strong effort, or looking silly when they offer their opinion to the team they’ve hired to be the “experts”.  As the facilitator of the review it’s your job to put them at ease when offering their feedback and to help them understand what types of feedback would be the most helpful to you.

First, let the stakeholders know that the entire purpose of this session is to get their feedback so they should not hesitate to give it.  Without their feedback, after all, you won’t know when you need to adjust course.

Second, coach them on the specific types of feedback that would be most helpful.  The type may change depending on the product that you’re building, but some common examples include…

  • Flow – Does the way the user moves through the app make sense?  Is there a better way?
  • Messaging – Is the language the team is using in the app appropriate to the product.  This can be particularly important in products that target a specific business domain, such as healthcare, to ensure that users understand the features as quickly as possible.
  • Superfluousness – Is everything that the team is showing useful and providing value?  Is there anything that could be removed?

Giving stakeholders examples of the specific types of feedback that you’re looking for often makes them more likely to offer it during the session.  And although stakeholders tend to start with the specific types that you prompt them with they’ll rarely constrain themselves to it for long.

Finally, be sure to elicit this feedback in an open ended manner instead of asking them as yes/no questions.  For example, rather than asking if the messaging that you’re using in the app is appropriate, ask if there’s more appropriate message that could be used instead.  Or, if you are seeking more general feedback for a portion of the app, do not simply accept “yes, this looks good”.  Continue digging until you understand why the work looks good and why it is solving the problem at hand so you can replicate that same experience elsewhere in the app.

Plan Ahead

Although we want Sprint Reviews to be a two way conversation rather than a scripted demo that doesn’t mean that we don’t start with a little bit of planning.  Make a list of the key topics you want to get feedback on before the Sprint Review.  These may be new features that have been added to the product, significant enhancements, or particularly nasty bugs that were fixed.  Like Scrum ceremonies, the Sprint Review is a time-boxed meeting so be sure to prioritize the list to tackle the most important topics first.  Once the list is complete, send it to attendees before the review to encourage the right people to attend.  Although a large meeting may be more difficult for you to manage, sharing the topics ahead of time will increase the chances of getting the right people in the room to get the feedback that you need.

As a word of warning, though, be aware that your list of topics does not evolve into a script.  Carefully scripted Sprint Reviews yield little value since they don’t accurately represent the product in use.  Interact with your product casually in the Sprint Review just as you would in a day to day scenario.  This will best convey the actual working state to your stakeholders and will invite their feedback if it doesn’t.  A demonstrable more casual approach to your interaction will also convey to them that their feedback is invited at any time, while a scripted Sprint Review will appear more formal and encourage attendees to hold their feedback until the end of your presentation.  Instead, keep the review casual and informal.  After all, your users won’t be using the product from a script…why should you?

Use Real Data

Just as we ant to interact with the product in a meaningful we’ll want to do so using real data.  All too often we prime products with carefully scrubbed test data that’s been painstakingly curated to contain elements that we’re certain the product can handle.  Unless your users are also painstakingly scrubbing any input or data they feed into your product this gives an inaccurate representation of the state of your product to your stakeholders.

Strive to conduct every Sprint Review with as authentic test data as you have available and use each review to re-confirm with your stakeholders that the data you are showing is representative of the actual data they will be working with.  Unless you explicitly call it out, many stakeholders will assume that you’re aware that your data is not indicative of what the product will be working with in the real world…encourage them to call this out so you can get the test data you need.

Coming Attractions

A common question for new teams embarking on their first review is whether or not they should review unfinished work.  Although, not everything the team creates is worth reviewing along the way, if it’s a significant portion of the product then you should take the opportunity to put it in front of stakeholders as soon as possible.  This “first look” is your chance to confirm that you haven’t completely misunderstood the overarching goal of the feature before you get too far down the wrong path.

Reviewing unfinished work can be a bit tricky, however, especially with stakeholders who are new to an agile process.  If you do decide to review unfinished work be sure to add the caveat that this work is still in progress and that you’re most interested in feedback concerning whether the team has correctly understood the problem and if they’re on the right track with the solution.  As with other pieces of the review, coaching stakeholders on the type of feedback that is most useful here is critical.

It can be helpful to save these topics until the end of the session.  As this work is still new it tends to be the most malleable, therefore it’s of lower priority than work that’s nearer completion.  Also, since less completed work tends to invite more open-ended feedback the natural time box of the Sprint Review can help manage this feedback before it grows out of control.

Inspecting and Adapting

Sprint Reviews are one of the most important ceremonies of the Scrum process as they allow teams to get to the critical feedback that results in a great product.  Without genuine feedback, the team has nothing to adapt to and runs the risk of continuing down the wrong path without an opportunity for correction.  It’s the team’s responsibility to make the review as authentic and productive as possible so they can get the right feedback from their stakeholders and deliver the right product, in return.

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

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

Read more...
Load More
10 of 33