Archive for agile tag

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

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

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

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

Saving Christmas with Scrum

It’s that time of year when our thoughts turn to the Holidays, Family, and for much of the world…Santa.

I have a soft spot in my heart for this time of year so I never miss the opportunity to catch a classic Christmas movie from my childhood. Not the modern takes on the season, but the classic films where just when times seem the darkest our clay-crafted heroes pull out a Christmas miracle in the last moments before Santa’s sleigh leaves the icy tundra for his trip around the world.

Lately, however, I’ve started to notice a consistently recurring theme in these movies…Santa and his elves are actually saving Christmas with Scrum.

Let’s see how.

Read more...
Top Down Release Planning

Release Planning from the Top Down

Quick…what was the killer feature in your last big release?  If your release is like most then you’ll probably have trouble answering that question.  In fact, if your release is like most it was probably filled with a grab bag of low quality features and a handful of bug fixes.  Sure, there may have been one or two important features in there, but for the most part they were buried amongst an avalanche of noise.

Bottom-Up Release Planning

Bottom Up Release PlanningWe call this type of release planning Bottom Up Release Planning.  It often begins with simply combing the backlog for stories that need to be released and grabbing as many as you can fit in your next release.

Sure, there are advantages to this, most notably that it’s easy to do.  Release planning tends to be simpler and take less time using this method.  In fact, you’ve probably seen these types of releases before, they often begin with a “wishlist” of features that absolutely must be in the next release.

But releases planned in this way tend to feel disjointed and often fail to make an impact on your users since there’s nothing tangible for them to bite on to.

Top-Down Release Planning

Top Down Release PlanningThere’s a better way…and we call it Top Down Release Planning.  This type of release planning occurs when we first define an objective or goal for each release and then select only those backlog items that fit that objective.

This type of release planning can be a bit more involved since we must decide if each item selected fits the objective of the release, but it can lead to much more cohesive releases.  These types of releases often make a bigger impact on users which can resonate with them for a long time to come.

Why Bother?

You may be wondering why if Top-Down Release Planning is even a little more difficult then why we put forth the extra effort?  Well, aside from the advantages I mentioned already, highly cohesive releases tend to be much easier to build a memorable marketing message around.

In addition, focusing the release on a key objective also allows us to make greater strides in trying to solve a sticky problem that our users are currently facing.  If we can solve a particular pain point—and build a great message around that solution—then we’re much more likely to deliver a release that will resonate with our users.

Want to Know More?

I cover Top-Down Release Planning in more depth in my course new course Agile Release Planning, available on Front Row Agile.  If you’ve ever struggled with building large-scale projects using agile techniques, or have just wondered how planning works in an agile framework then this course is a great fit.

In addition to Top-Down Release Planning I also cover

  • How traditional planning and agile planning differ, and how to start adopting a more agile mindset.
  • How to develop a vision for your projects, including creating a vision board and learning proven techniques to cultivate focused concepts.
  • Strategies for building a roadmap to your goal and important things to consider in the first release and all future releases.
  • Ways to plan the release, including how to develop a release grid and prioritize features well.
  • How to build the product backlog by looking through the lens of DEEP and constructing effective sprint plans now and far into the future of your agile development.
  • Methods to keep plans on track when things just don’t go as you expect.

This course is regularly $50 but for a limited time readers of this blog can get all of this content for just $40 by using the discount code PLANBETTER at checkout.  That’s an additional 20% off just for following this blog.

Just enter the code above to claim your discount and be on your way to planning great releases and I’ll see you in the course!

Read more...

Where Afternoon Standups Go Wrong

Most teams are familiar with the morning standup, or the classic scrum ritual that gives teams the opportunity to sync up and plan their work for the day.  For many teams, the morning standup is the bread and butter of their scrum process.

But every once in a awhile a team tries to move their standup to the afternoon.  The reasons always sound legitimate:

“Not everyone gets here at the same time, so we’ll just hold our standup in the afternoon.  That way everyone can attend.”

or

“Mornings are when we’re most productive…we don’t want to interrupt that with another meeting.  Let’s just have the standup in the afternoon.”

As valid as these reasons sound afternoon standups have a tendency to be less useful than morning standups, but the reasons why aren’t always clear.  Let’s take a look at why.

The Ritual Suffers

The standup ritual suffersMorning standups create a nice ritual for your team.  Everyone trickles by 9 o’clock, checks their email, and gets their morning cup of joe.  But, at 9:30 everyone filters into the team room and it’s time for the standup.  After a quick standup the team starts their day for real.  The 9:30 standup is the signal for the day to start.

On the other hand, even though afternoon standups are still scheduled at the same time every they are much less likely to start at the same time every day.  This is because by the afternoon the day is much more likely to have gone awry.  Maybe tasks have taken longer than expected so not everyone is ready.  Perhaps a fire has much of the team too distracted to make the original time.  Or, even if all of the team is available, maybe other meetings outside of the team have ran long and the team’s normal meeting space isn’t available.  Now the team has to hustle to find a space that can accommodate them for their already late standup.

Standups Last Longer

No one likes a long standup.  In fact, one of the most common complaints from new scrum teams is

“Our standups always last at least 45 minutes.”

All standups are susceptible to this but afternoon standups are particularly so.

Standups last longerThink of how you feel in the morning:  You’re energized for the day, you’ve had a fresh cup of coffee, and you’re ready to tackle that sticky problem from yesterday.

Now, think of how you usually feel in the afternoon:  You’ve just had lunch.  You’ve already been at work for 5 hours, and all you want is a reason to sit down and take a break for a bit.  The afternoon standup is that reason.

And, once everyone has sat down, the standup begins to drag.

Your New Status Meeting

But, the most insidious problem of all with afternoon standups is much more subtle.

Standups should have two goals…

  1. Identify blockers so they can be brought to light and removed.
  2. Allow the team to sync up and plan their work for the day.

Nowhere in that list is a goal for the team to report the status of their current work in progress.  That’s not the purpose of the standup…that’s the purpose of the scrum board.

Morning standups are very conducive to these goals since they encourage the team to identify blockers early in the day and to synchronize the day’s work before they get started on the wrong path.

But afternoon standups share neither of these traits.  Although the same blockers might exist in the afternoon as they did in the morning, team members are less likely to bring them to light since they may mistakenly believe they’re close to solving them.  Even if they do, the other team members are likely too deep into their own tasks to volunteer much help.  In addition, since the individual team members have already started their work for the day there’s no opportunity to synchronize the work as a team…everything has already begun.

With both of these options off of the table only one thing is left to talk about in an afternoon standup…status.  When held in the afternoon the focus of the standup naturally shifts to what each team member has accomplished so far that day.  Rather than providing the opportunity for the team to clear their own way and plan the day’s work ahead, the standup simply devolves into yet another status meeting.

Try It and See

The differences between afternoon and morning standups are subtle but the results can vary dramatically.  If your team is currently using afternoon standups and something just doesn’t feel quite right then give morning standups a try.  The difference may surprise you.

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...
Load More
10 of 14