A Blog About Agile from Davisbase Consulting

Becoming Agile is the Davisbase Consulting blog about all things Agile. It features regular posts by our staff, whose diverse expertise and backgrounds enable us to offer fresh perspectives and insightful observations.

Check out some of our favorite entries by visiting the top posts page, and be sure to subscribe by RSS feed or email to keep up-to-date.

Print pagePDF page

An Early Bird catches the SPC

Are you ready to affect meaningful change and take an active role in leading your organization through Scaled Agile Framework (SAFe®)? If so, we’ve got the event for you.

Standard pricing for SPC Training is $2,875. Register before 11/1 and get $200-Off, making registration only $2,675. Register Now!

Early Bird pricing for our 4-day SAFe® Program Consultant training in Atlanta is currently available! During this time, you will receive $200 off regular pricing for the SPC course.  Act quick, because early bird pricing expires on November 1st.


When: 12/X – 12/X
Where: Atlanta, GA
Cost: $2,675

Bird Image: Creative Commons (Attribution 3.0)

Print pagePDF page

Analysis Across 5 Levels of Agile Planning

Analysis Across the 5 Levels of Agile Planning

On Friday, September 25 I had the honor of presenting at the dsmAgile event in Des Moines, Iowa. In case you missed my presentation, Analysis Across 5 Levels of Agile Planning, you can download the slides from this post.  The entire presentation covered 18 different techniques, approaches, and mental models for analysis across the different Agile planning horizons.

The entire presentation was built around the construct called the “5 Levels of Agile Planning.” At this point, I’m not entirely sure where these 5 levels originated, but they are talked about by practitioners from many organizations and consultants from numerous firms.

pic2Here are two important things to know about the 5 Levels.

One: The 5 Levels of Planning are ALWAYS ACCURATE but at varying levels of precision.

Two: The 5 Levels of Planning are practiced by THE TEAM. Levels 1 & 2 are not reserved for leaders, Level 3 is not just the PMO, etc. etc. – All 5 Levels are practiced by THE TEAM. Have questions, please comment on the post.



When the 5 Levels are Used

Sprint 0 + Innovation & PlanningInivative








I took the time to remind attendees that we are really looking to practice the 5 levels of planning within the “construct” phase on a value stream. Here are a few key points about the value stream & the context of how the 5 Levels of Planning fit in.

  • The “initiate” phase is focused on decided three things
    1) Should we do this work?
    2) Are we ready to do this work?
    3) Can we start this work?
  • There are a few criteria that help you know if you should move from “initiate” to “construct”.
    • Vision is understood
    • Success measures are defined
    • Product Owner is prepared
    • Funding is secured
    • Team Members are available
  • The “construct” phase is where all the incremental delivery occurs.
    • For brand new teams this work often starts with an event called Sprint 0 or Iteration 0 where they come together, create working agreements, form team bonds, get through Levels 1 – 3 of Agile planning, and ensure their 1st two iterations of stories are in a “ready” state.
    • Once complete with Sprint 0, they can begin the incremental delivery cycle we all associate with traditional Scrum or Kanban practices. It is important that teams always come back and revisit the “Release Planning” activities to baseline expectations with stakeholders for what will be delivered when.
    • Lastly, after any given release (or perhaps at an 8-12 week cadence), teams should pause the delivery cadence for Innovation & Planning, re-align on the Vision & Roadmap, and create a new Sprint Forecast / Release plan for the next MMFs or MVPs that will be delivered to customers. This time-boxed activity may feel similar to Sprint 0, and once complete, the team will re-enter an incremental delivery cadence.


Kano Analysis

KAnoYou might already be familiar with MOSCoW analysis. It is a prioritization classification method where items are grouped by Must Have, Should Have, Could Have, or Won’t Have.  Kano Analysis is similar in that it is a classification method as well. It is often used for prioritization, but is truly centered around best understanding customer satisfaction.  Instead of the subjective nature for something that “cooooould” or “shoooould” be, Kano provides an explicit model for determining the importance of features in terms of customer satisfaction.


If you research the model, you can learn more about the way the Kano grid helps make this determination by asking the “functional” and “dysfunctional” questions for a single feature.  Here is an example:

  • Context = eCommerce site
  • Feature = Product Comparison
  • The Functional Question = Hi shopper, how would you feel if you were able to compare products while shopping online?  The response, “I would Expect to do that.”
  • The Dysfunctional Question = Hi Shopper, how would you feel if you were not able to compare products while shopping online?  The response, “I would Dislike that.”
  • The Result = Must Have.  By finding the intersection point on the Kano grid, you’re able to determine the Kano value for this feature.

It is a great technique to employ when determining which features to include in a release.


Impact Mapping

Impact mapingIf you’ve read much on user stories you know that there are 3 parts (actually 4 parts).

1. The Who
the end-user you are looking to satisfy
2. The What
the function the user is looking to accomplish.
3. The Why
the reason the user needs it.
4. The Acceptance Criteria
how we will know we have met the end-user’s needs

While the “what” is definitely a critical part, the “why” is often more important because if gives you context for what the end-user is truly trying to accomplish.

Impact Mapping is an approach for exploring customer/user goals and then deriving the actual functions/features that are needed in order to accomplish those goals. As practitioners close to the technology solutions, its far to easy to jump straight to the solution definition. The great thing about impact mapping is it forces us to be uber-clear on the Goal & Why customers need things. Remember, the highest priority is to satisfy the customer! (see Agile principles).


Final Thoughts…

Drowing in papersRemember, even though I review 18 potential ideas for doing analysis, you don’t (and shouldn’t) leverage all of the techniques all the time. Good Agile practitioners have lots of baggage (not the negative emotional kind), and understand the right technique at the right time. So, don’t drown yourself in documentation and extra artifacts in an effort to try and be better. Think about the customer, make them your highest priority, and derive elegant solutions to meet their needs!

Print pagePDF page

More Gravy for Your Brain

Screen Shot 2015-09-20 at 8.20.08 PMIt’s that time of year again. Every October, Charlotte hosts the annual Southern Fried Agile (SFA) event. Each year the event grows and grows, and we’re pleased to say that Davisbase has been involved since the very beginning. It’s exciting that we’ve finally outgrown meeting space in the Charlotte hotels and are moving up to the Charlotte Convention Center + NASCAR Hall of Fame! The schedule is jam packed with fantastic speakers, and it’s sure to be the best event yet.

If you’re available to attend this year, we’d love to see you. Please stop by our sponsorship booth and enter to win a free agileRBI: Agile Maturity Survey for your team!

Attendees of this year’s Southern Fried Agile will also get a chance to see:

CV Photo - Leslie Morse - for print
Leslie J. Morse
Analysis Across the 5 Levels of Agile Planning

An Agile approach for delivering value means you’ve got to abandon the idea of “big design up front.” That can be a scary proposition though, especially if you’re not familiar with how to apply analysis and design techniques within an Agile framework.

During Analysis Across Five Levels of Planning, you’ll learn about a planning model for progressive elaboration, The 5 Levels of Agile Planning, as well as proven analysis and design techniques that apply to each planning horizon.

CV Photo - Andy Painter - for print (1) (1)
      Andy Painter
Agile Expert Panelist

Our very own Andy Painter will have a seat on this year’s Agile Experts panel. The annual panel discussions are always entertaining, engaging, and insightful. Attend this session to learn how people across the industry are developing teams that develop value.


Print pagePDF page

5 Reasons to Consider SAFeĀ®

SAFe3.0.3BigPictureThe Scaled Agile Framework (SAFe®), codified by Dean Leffingwell, but based on a tremendous amount of real experiences in many companies, is a guide to scaling Agile practices across the enterprise. It is a proven framework based on Lean, Systems Thinking and Agile Development principles that is increasingly gaining greater recognition and adoption throughout medium and large corporations.

So why might you want to consider SAFe for your own organization? Here are 5 reasons why:

1. If you have successfully experimented with Agile at the team level and you are now interested in implementing a consistent Agile approach across larger, multi-team programs and portfolios.

Many organizations start with Agile by experimenting with one or two teams. Eventually, after some moderate success, interest in replicating this success across the enterprise grows. That is when much deeper adoption challenges begin to surface. Some oft-heard questions include,

“How do we take these practices and processes that are designed with a small team in mind and scale them up and out across our program or whole organization?”

“How do we align multiple teams, programs, and departments to deliver something of greater substance and market value than what one or two teams can produce?”

“How do we align multiple business departments and IT for greater collaboration, effectiveness, and efficiency in building and shipping software?”

SAFe addresses each of these questions and more by identifying key Lean, Systems Thinking and Agile principles and practices that scale well and must be held in common across your teams and programs for scaling success.

2. If you have multiple teams running their own unique implementation of Agile but you regularly experience obstacles, delays, and failures when the teams are dependent on one another.

It’s not uncommon for large organizations to have a few teams implement their own take on Agile and do so successfully for the work in which they are fully autonomous. However, such organizations often struggle when planning releases that involve more than one Agile team. Some common reasons for this include…

  • Teams operating on different iteration cadences
  • Teams using different Agile frameworks
  • Teams using different technical practices for architecture and code quality, and
  • Teams relying on different tools for managing their Agile lifecycle and reporting progress.

Learn about having a successful ART PI planning event in this post from Troy Plant, 5 Tips for Successful SAFe Release Planning

SAFe outlines a consistent approach to planning, execution and delivery of value. The method for doing so is referred to as an Agile Release Train (ART). An ART is a lightweight “program container” that brings multiple Agile teams together on a consistent cadence every 8-12 weeks known as a Program Increment (PI). At the beginning of each PI, the ART comes together to plan what they will deliver in that PI. This opportunity to work together as a team of teams helps organizations uncover, plan for, and address cross-team dependencies, risks, and impediments. During the PI, the teams on the ART use well-known practices like the Scrum-of-Scrums to remain in sync on cross-team dependencies and new practices like cross-team System Demos every two weeks to inspect and adapt the product from a customer-centric point of view.

Finally, at the end of each PI, the ART inspects and adapts on what (product) and how (process) they delivered in the previous 8 to 12 weeks.

3. If you are eager to scale Agile across the organization but are not sure what new roles may be needed and what existing roles (ie management) need to change and how.

Implementing Agile across your organization is a significant change that will no doubt raise questions and potential fears about current roles and potentially new roles. What new roles do you need, if any, to be successful? What about management? Do they still have a role? If so, does it need to change? And, if so, how?

Learn about Adopting SAFe

Take one of our public Leading SAFe classes to get started Scaling Agile.

View Training Dates

These questions about roles and responsibilities are addressed by SAFe across team, program, and portfolio levels. For example, IT Enterprise Architecture holds a seat at the portfolio table to ensure that the necessary “enablers” or “architectural runway” (technology and infrastructure) is established in time to realize the business vision. As for management, suffice it to say, they must “lead the way” and are an important role within SAFe, though there will be some new mindsets and practices to adopt. To aid you in your role additions and changes, there are multiple SAFe training course opportunities available for Scrum Masters, Product Owners and Product Managers, SAFe Practitioners (team members), SAFe Agilists (management) and SAFe Program Consultants (Lean/Agile leaders, coaches, change agents).

4. If you have attempted to scale Agile across your organization but you have struggled to achieve consistent strategy across business departments and consistent alignment from the portfolio level to the program and team levels.

A common challenge with enterprise-scale software development, Agile or not, is establishing and maintaining alignment with the vision and strategy from top to bottom across the organization. Oftentimes, there is a struggle just to align multiple business departments with the same strategy. And even when there is alignment across business departments, there is yet another challenge to ensure that strategy is clearly communicated and delivered upon all the way down at the team levels. Even with alignment, large queues and wishful-thinking may still prevail and need to be addressed.

While SAFe certainly will not solve every problem in your organization, it does provide a framework for implementing Lean, Systems Thinking and Agile consistently from portfolio though team levels. At each level, key roles, responsibilities, practices and metrics are identified that embody Lean|Agile principles, and when applied consistently can help you establish flow and alignment of work top to bottom. Detailing how this cohesion is achieved in SAFe is beyond the scope of this article, but you can get a solid visual of the process via the SAFe Big Picture.

5. If you know your organization needs to improve its product development lead times and you’ve heard about the success that other companies have experienced scaling Agile with SAFe and you want to know how they did it.

It’s no secret that more and more large companies, old and new, such as John Deere, Discount Tire, Spotify, Salesforce.com and others have figured out how to scale Agile (via SAFe or custom approaches) to shorten their product development lead times and frequently deliver working software to delighted customers. And now it isn’t just software and technology companies filling this space, but companies in more traditional domains such as finance, logistics, insurance, and government that are seeking to scale Agile in search of the same benefits.

SAFe is a proven and well-documented approach to bringing its principles, values and benefits to the wider enterprise. It provides a comprehensive view of the business and technical principles and practices needed from top to bottom of the enterprise to successfully scale Agile. These principles and practices aren’t all entirely new or unique to SAFe but have been pulled together into a cohesive package ready for deployment in your organization.

Final Thoughts

Screen Shot 2015-09-04 at 11.47.13 AMIf you’re interested in learning more about SAFe and how it could work in your organization, consider reaching out to learn more. With certified SAFe Professional Consultants (SPCs) and Trainers (SPCTs) on-hand and numerous successful SAFe implementations under our belt, we have the experience and expertise to help you leverage SAFe and achieve the benefits of Agile at scale. Contact Us for more information.

Lastly, thanks to my colleague Scott Frost for his assistance in authoring this post. It’s always a pleasure to work with you!

Print pagePDF page

Come See Us at a PMI Event

Continuous learning and professional development are good habits for all professionals, and they are especially important for Agile practitioners. The first line of our 
manifesto tells us…

We're uncovering better ways
It implies we are always seeking new knowledge and information. What is the next one thing we can do to be better?

In the spirit of improvement, we are supporting a PMI® chapter event near our operations headquarters in Charlotte, NC. Please come see us soon!


September 26, 2015
8:00 AM to 5:00 PM

Metrolina Chapter
Project Management Institute
Professional Development Day
Charlotte, NC 9/26/2015

Print pagePDF page

The Fifth Ceremony

Woman with act now or pay later shutterstock_78635185You’re the ScrumMaster of a development team in the middle of a two-week sprint when it becomes obvious the team is stuck on a story.   During your standup you discover the team can’t move forward because they need access to a backend system. Until access is granted they are stuck – and declare this an impediment.  As a good ScrumMaster you do your due diligence and follow up on the impediment (as you should).  So you set up a meeting with the administrator of that system and discover he needs you to get management approval to access the backend system. Ok – how do I get approval?  You need to fill out form X.  Gotcha.  So you fill out form X, and submit it to the manager for approval.  The next day – the story is still blocked pending approval.  This scenario drags on for 3 days; your demo is 2 days away.  Then – bingo, your access is approved, now for the gotcha.  The team explains that they no longer have sufficient time to complete the story in time for the demo, so it must be deferred to the next sprint.  Face palm – Argh!


What Just happened?

The sprint is over and you failed to complete the work that the team had committed to. During your sprint review, it is clear what happened, the team could not complete the story because they didn’t have access to the correct environment. Not their fault right?  It’s time to pause and take look back at how you got into this mess to begin with.  To get to the root cause, I like to start with the Five Why’s. It’s an effective way to quickly get to the bottom of what the heck just happened

  1. Why did we fail to complete the story?
    Because we did not have access to the right environment.
  2. Why did we not have access to the right environment?
    Because it took 3 days to get the access rights approved.
  3. Why was the access right not approved in time to complete the story?
    Because we did not submit the form until the middle of the sprint
  4. Why did we not submit the form until the middle of the sprint?
    Because we did not anticipate the need to request access in advance.
  5. Why did we not anticipate the need in advance?
    Because we did not fully understand the story before we started it!

The Scrum Continues

According to the Scrum Guide by Ken Schwaber and Jeff Sutherland there are 4 standing ceremonies in Scrum.    

      1. Sprint Planning
      2. Daily Scrum
      3. Demo
      4. Retrospective

Each of these ceremonies is critical to the successful implementation of Scrum and are well explained in the Scrum Guide.  Anyone on an experienced Scrum team should be familiar with these ceremonies.  Further along in the Scrum Guide, Schwaber and Sutherland explain the concept of “Product Backlog Refinement.”

The Scrum Guide prescribes:

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.  The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.”

As an Agile Coach – this is the part that deserves more attention.


The Fifth Ceremony

The Product Backlog is where everything starts.   If your backlog is a wreck, guess what?  Your project is likely a candidate for hard times.  So what is the magic bullet to avoid a failed sprint?  Great question!  The answer is simple – Product Backlog Refinement.  In this Coach’s humble opinion – including Product Backlog Refinement, as a regularly scheduled Scrum ceremony is so important to a smooth running project, I would nominate it to be The Fifth Ceremony.

There are a number of hidden dynamics and benefits that happen when you regularly review and refine your product backlog:

      1. The team gains insight into the work coming up.
      2. The team gets to ask key questions they have about the story.
      3. The team can determine in advance if there are any hidden issues that require lead-time to complete, i.e special access permissions to key systems or environments, lead time required by external teams still using waterfall. 
      4. It  buys the Product Owner and Scrum Master time to get questions answered.



Now that we have established the importance of Backlog Refinement, how far out should we be looking and how much time should we devote to this fifth ceremony?
The Scrum Guide suggests no more than 10% of the team’s capacity.  That is really up to the team to decide.  Figure 1 below illustrates a suggested continuum for how far out you should be looking.   Set aside at least one hour of your work week, preferably mid week when you can realize max participation to do your backlog review and refinement.
UntitledSprint +3 – 4 – This is the time when the PO is working with the business to clarify their understanding of the story.  The PO needs to have a clear understanding as possible in order to clearly communicate the specifics to the team and define the acceptance criteria.

Sprint +2 – Story Refinement is where the team gains a better understanding of the work moving closer to the execution horizon.  The team needs to start analyzing the story with an understanding of how it fits into the architecture and determining if there are any dependencies on external teams.  This is the time to make sure you clear any anticipated impediments, such as approvals for access to systems, compliance with any regulatory requirements, etc…

Check out Definition of Ready – Revisited by Leslie Morse.

Sprint +1Story Review is the teams opportunity to confirm with the PO that they have a solid understanding of the story and have all questions answered.   By the time you get to Sprint planning, the only thing the team needs to do is to break down and assign the tasks. This is the appropriate time to leverage a Definition of Ready. Not sure what that is? 


Final Thoughts

In summary, by getting ahead in your review of stories, the team can ask the key questions, anticipate requirements, and buy time for the PO and SM to clear impediments BEFORE they happen.   Getting your team in these good habits is like preventive maintenance on your car.  It will keep things running smoothly.  If you don’t want to blow your engine, change your oil.  If you don’t want to blow up your sprints up, plan your work regularly.   Action is the key to success.  Good ideas add zero value until someone takes action on them.  So leverage the 5th ceremony, dig into your backlog, and start planning your work not reacting to your work!

Print pagePDF page

Our New Scaled Agile SPC Trainers

Partner-Badge-Gold-SPCT-135We are thrilled to announce that two of the newest Scaled Agile Inc. SAFe Program Consultant Trainers (SPCTs) are from our Davisbase Team. Congratulations to Steve Davis & Scott Frost for completing the rigorous program and earning our firm Scaled Agile Gold Partner SPCT status.

Currently, only 9 organizations (with a total of 23 SPCTs) have Scaled Agile Gold SPCT status. This new capability will allow us to enhance our ability to ensure our clients build self-sustaining Lean|Agile Enterprises.

CV Photo - Steve Davis - thumbnail web
Steve Davis
“I’ve had a lot of great experience helping companies, teams, and individuals transform the way they work. Working with Scaled Agile and receiving my SPCT gives me a platform to guide leaders and organizations in their Lean|Agile journey. Most importantly this opens doors for me to showcase how Lean Systems thinking allows leaders to build teams that deliver value. Having a hand in growing the SPC community assures me that I can leave a legacy that truly changes lives for the better.”

CV Photo - Scott Frost - thumbnail web
      Scott Frost
I’m truly humbled to join the servant leadership ranks of the SPCT community.  It’s both a way to give back and help new students of SAFe on their Lean|Agile journey and a way for me to continue mine.  As we at Davisbase say, “Know, Doing, Becoming”, it’s a journey that creates a life-long learning journey of ever growing our skills, experiences, and service hearts.  I’m thrilled to be an SPCT and look forward to seeing the “Ah-ha ”moments in every new class and client transformation.”

If you’re interested in learning more about Scaled Agile Framework, consider one of these upcoming opportunities!

Print pagePDF page

Roadmaps are Intended to Scale

For those of us who fall into a certain age bracket, you’ll remember those family vacations where everything in the entire house was crammed into an oversized station wagon (with hood ornament) so that the entire family could hit the open road. Our parents had lists upon lists of things that needed to be done prior to pulling out of the driveway with fully loaded vehicles….and with good fortune the children were in there somewhere. The car’s gas tank was full and a few new quarts of engine oil would have topped of the reservoir. Once all that was done, there was only one thing left to do. That thing….for those who can remember….would have been to purchase a brand new Rand McNally road atlas on the way out of town.


The Road Atlas

Now the concept of family vacations may have changed over the years, but one item that still prevails for many households today is still the Rand McNally road atlas. Inside was a vast treasure trove of national highway maps, state maps, big city maps, national park maps and other fascinating pieces of trivia that any self-subscribing roadtrip enthusiast would enjoy learning more about. There are also scales for lots of meaningful information points such as distance, driving time between major cities, enhance resolution of big cities, elevation and even latitude/longitude. These scales always provided countless hours of discussion which usually centered around the phrase, “are we there yet?”  

Over the course of a few hundred or few thousand miles, that road atlas would see all kinds of action.  Pages would get accidentally torn as kids fought over the maps in the backseat. Coffee may have spilled on the key pages during quick stops or hasty escapes after driving down a one way street in Kansas City, MO. And, of course, let’s not forget ketchup and mustard smears that the children would have sworn didn’t come from them. All things considered, the atlas would take a beating on these trips, yet was always considered to be a cornerstone of any good vacation.


The Road Atlas & Agile

While this trip down memory lane should elicit some memories (hopefully more good than bad), readers may be wondering what an Rand McNally atlas has to do with Agile and the answer is everything. Granted, our Agile roadmaps should get printed more than once a year as opposed to what I remember about Rand McNally, but the parallels between the two should not be overlooked by any organization, leader, manager, division that is moving through their respective Agile journey. As a matter of fact, I recommend that organizations develop their own Agile Atlas as part of any successful strategy to help scale Agile beyond the application development division. Let’s briefly look at the how we could use the Rand McNally atlas as a layout guide for how organizations could help to scale Agile beyond the traditional boundaries of software application development.


Corporate Roadmap

One of the first things that I remember about the atlas was a two page layout of the continental United States all the way from the Florida keys up to Alaska. I never could figure out why Hawaii was so far to the left everything else, but that answer eventually presented itself to me as I got older. These two pages had major interstates listed and usually an outline of the various states, but not much else. One could look at it and know how to get to just about anywhere using a simple grid of East/West and North/South interstate systems. As I coach clients at the enterprise level, I’m always encouraging them to create their own Corporate Roadmap and have use the Rand McNally atlas example many times. This approach seems to resonate with many and helps to transcend a traditional notation that Agile concepts and techniques are just for technology teams.  


Division Roadmap

Map, pencil and curvimeter (map measurer)Next, I remember that each state was listed in alphabetical order with an intricate system of both national interstate systems, state highways and even some secondary roads. The state was also drawn to scale on the map and if I didn’t remember where the state fit into the national system, all I had to do was look back to the first page and find the corresponding shape. The same can be said and used successfully for organizations at either the division or department level. These Division Roadmaps will have and should have a logical connection back to the corporate roadmap mentioned previously. The level of detail will definitely be greater, yet the simplicity of the connection points should never be overlooked. Provide the organization and potentially even customers with the key pieces of information that are both meaningful and valuable as part of a division roadmap strategy. The key aspect in this regard is to create roadmaps for all divisions, not just IT.


Product, Program, & Portfolio Roadmap

Now, each state would always have a large city or national park that deserved special attention. These maps may have been on their own separate page, or were callouts for states with smaller geographic sizes. For me, these maps translate to both Product Roadmaps and even Technical Product Roadmaps, both of which have significant value and should be viewed with both horizontal and vertical stacking. I always encourage organizations to use similar views when creating these types of roadmaps if they are truly interested in further scaling. In addition, these two categories of roadmap could grow into both Program Roadmaps as well as Portfolio Roadmaps that could then be stacked (horizontally and vertically) with both the division and the corporate roadmap in order to get a true corporate picture.  

Now while my days of sitting in the backseat and arguing with my siblings may be over, the Rand McNally atlas comes with us for all of our road trips. Of course, that means the coffee stains on the pages are mine and mine alone…except when I unsuccessfully attempt to blame them on the wife.  

As agile practitioners, we all know the value of continual planning and “road mapping” is definitely not an exception to this mindset. Yet for many, the idea of using Agile techniques to scale beyond technology teams isn’t in everyone’s immediate comfort level. This type of approach takes practice, discipline and continued dedication.  Yet, if undertaken, the results will provide tremendous value to your organization and even your customers time and time again. Thus, I always encourage those that will listen to create the own Agile Atlas as part of their continued scaling and progression path.  

As a coach told me many years ago, “get out of the comfort zone”….and as I tell teams, divisions and executives today, “champions are not created when it’s nice outside”.  

Enjoy your Agile journey and keep scaling!

Print pagePDF page

5 tips for a successful SAFe Release Planning Event

One of the most critical alignment events for every Agile Release Train is the Release Planning Event.  This is an opportunity for teams working on a common Vision & Roadmap to come together and build a plan for delivering their next increment of value. Release Planning of this magnitude can be quite stressful, less valuable, and nearly disastrous if teams have not prepared. Having participated in  dozens of SAFe® Release Planning Events, here are 5 easy tips that will help make your next planning event a success!

  1. Get Leadership Engaged & Involved
  2. Create a Feature Readiness Board
  3. Bring in External or Unbiased Facilitators
  4. Go Off-Site and Feed the Participants Well
  5. Have Fun


Get Leadership Engaged & Involved

The SAFe® House of Lean has Leadership at the foundation for a reason!  Nothing is more demotivating than initiating your Plan Review teams have worked hard on all day and your Business Owners aren’t represented in the room.  What message does it send to your teams, if you aren’t interested in seeing what they plan to work on for the next 10-to-12 weeks? 

Management is about arranging and telling. Leadership is about nurturing and enhancing. —Tom Peters

When the leadership team is engaged and available throughout the event they are able to make on-the-spot decisions and guide teams in real-time. This prevents re-work and increases the feasibility as well as confidence in the plan. When teams know leadership has their backs, fully understands the work they are doing, and supports and cares about them –  it makes a world of difference in morale and quality.


Create a Feature Readiness Board

Product Managers and Product Owners are constantly balancing the needs of the current Program Increment (PI) with having to look ahead and define Features and Stories for the upcoming PI.  Business readiness is a critical aspect for increasing organizational agility, and a Feature Kanban board allows for clarity and transparency about where upcoming features are in readiness process. BVIRs (Big Visible Information Radiators) are essential for Agile teams and ensure the 1st golden rule of Kanban is met.  Feature Readiness boards enable focus, and help teams plan handoffs and ensure business & architectural aspects of readiness are taken care of.

Bring in External or Unbiased Facilitators

“The facilitator’s job is to support everyone to do their best thinking. To do this, the facilitator encourages full participation, promotes mutual understanding, and cultivates shared responsibility.”1

Being the facilitator of a planning event can be quite a daunting task.  Proper facilitation is important to keep the people engaged and the activities on track!  There are 2 critical elements for being a successful facilitator. 1) You cannot be a participant. If you try to facilitate and participate, the event will rapidly veer off track.  2) You cannot have a vested interest in the outcome. If you steer planning towards a pre-determined direction, you will lose authenticity of the plan. Neutral, unbiased facilitators assist with avoiding political stress, free up your Release Train Engineer (RTE) to focus on the teams and their needs, and enable someone to be committed to timing and progress.  For your next planning event, try an external coach, or someone outside your Release Train as the MC of the event, the benefits will certainly delight you.

Go Off-Site and Feed the Participants Well

The right environment and facilities are a key factor for a success. You need ample wall-space and a room large enough for each Agile team to have their own area for collaboration and information radiators. If the room is cramped, it will be difficult to pull groups together for ROAMing risks, discussing dependencies, and holding scrum-of-scrum discussions. Often clients say, “It was great to get away for two days and really focus on the work without the distraction of being in the office and stuck back at their desk.”

Assume for a moment that you selected the ideal physical space. From experience, I can tell you that companies failing to provide snacks, lunch, and plenty of beverages will undoubtedly hear about it during the end-of-event retrospective. Trust me, teams will be happier and more engaged if you feed them.  This seems like a small thing, but it will go a long way!  When planning food & beverage, remember your vegetarians and anyone with significant allergies.

One final space planning note, check your mobile devices and laptops at the door! Teams need to come prepared to focus, do work, and avoid distractions. Electronic devices open up the gateway for a huge productivity killer – e-mail.

Have Fun!

“There is good evidence that if you allow employees to engage in something they want to do, (which) is playful, there are better outcomes in terms of productivity and motivation.”2

Two full days of planning can be taxing.  Incorporating fun into the event can relieve stress and reboot mental capacity.  I recommend a friendly competition between teams. Hold it immediately following the lunch hour, and you’ll better ensure everyone is back in their seats for the afternoon session. Nerf® sports, table tennis, Wheel-of-Fortune, or Trivia games are always a hit.

You’re not limited to games though. My personal favorite was when a Release Train Engineer kicked off the event singing a rap song he wrote about his train and teams. Everyone was up on their feet and energized for the day.

Treat release planning like a celebration and the buzz of excitement will yield a plentiful bounty.


Hopefully, these tips will help improve your next Release planning event. Please give them a try and let me know how it goes! Happy planning!


1. Facilitator’s Guide to Participatory Decision-Making by Sam Kaner, et al
2. Dr. Stuart Brown, founder of the National Institute for Play

Print pagePDF page

Agile Q&A: Improve Backlog Collaboration

The Question: My team refuses to make time for collaborating on backlog items. What should we do?

The Answer: Retrospect, Experiment, Retrospect

If you read our #BecomingAgile blog very often, then the pattern of having a retrospective, trying something new, and reflecting again should not be new to you. The idea of continuous improvement is a core tenet of Agile.

In order to answer this one for you I’ll touch on:questions!!!

  • The team retrospective
  • A personal retrospective
  • Compelling them with CvC
  • Experimentation
  • Capacity Reminders

Team Retrospective

Does the team recognize that there is a need to improve? If not, it will be very difficult to change behaviors.

If the retrospective goes well, and the team sees an opportunity for improvement, then I would baby-step into a more comprehensive & collaborative approach for backlog refinement. Suddenly instituting a 4-hour Story Refinement session, Story Review session, and strict adherence to a Definition of Ready will probably be too much too fast. Based on your team dynamics select the one technique that could improve the understanding of story details and work incrementally from there.

Personal Retrospective

If the team doesn’t acknowledge a gap, then it may be best to look inward first. Have you done a personal retrospective? Is the team really doing OK? Do they have a strong and stable velocity? Is the Complete vs. Commit (CvC) ratio sprint-over-sprint consistently above 85%-95%?  If so, you may be trying to add extra weight to the process. Simply because refinement workshops, review sessions, and other techniques have proven to be successful, it doesn’t mean you have to do it that way.

Compelling CvC

Let’s assume the team’s CvC metric is not consistently above 85%-95%. While the team doesn’t “feel” like there is a problem, something fishy is definitely going on. Pointing out some obvious indicators may be helpful.

Some of the classic symptoms I see with teams struggling in this area include:

  • The first few days of the sprint seem really chaotic and we are running around trying to figure out how to go about delivering solutions for these stories. What can we do to reduce that churn?
  • Task planning at the beginning of every sprint is a nightmare; we struggle to know what the tasks are. It might be useful for us to set aside a little time in advance of sprint planning to collaborate on stories so that we can get better.
  • Alternates of this include the team having a low level of accuracy when estimating task hours, or they have a pattern of discovering a significant number of tasks  mid-sprint.

CvC metric, don’t just consider “Complete” as in all the tasks are finished: it really is “AvC” Accepted vs Committed. Of the stories the team committed to delivering during the sprint, how many were actually accepted? If the team is finishing all the tasks, but the stories are continually rejected during the demo, that’s a very clear sign better collaboration is needed.

Remember, when looking at the CvC metric, don’t just consider “Complete” as in all the tasks are finished: it really is “AvC” Accepted vs Committed. Of the stories the team committed to delivering during the sprint, how many were actually accepted? If the team is finishing all the tasks, but the stories are continually rejected during the demo, that’s a very clear sign better collaboration is needed.

Perform an Experiment

When in doubt, work with the team to try out a new cadence for collaboration. You don’t have to commit to doing it forever, but you can start somewhere.  A 2-sprint trial of Story Refinement sessions might be enough. At the end of the 2 sprints you can reflect on whether or not it made things better. If it did, keep on going and a few sprints later try another experiment to add an additional technique.

Be Sure to Reserve Capacity

Don’t forget, when you’re introducing these techniques, make sure the team doesn’t inadvertently start overcommitting. If a 7-person team is going to start allocating 4-hours to a Refinement Workshop each sprint, that is 28 hours of capacity no longer available for doing tasks during the sprint. Make sure the team is decrementing available capacity properly so that sprint planning commitments remain authentic.

Final Suggestion

Check out our webinar recording “Strategies for Grooming Your Backlog.”*  If the idea or intent of terms like “Story Refinement Session” or “Story Review Session” are confusing, it will help you shore up your understanding of the recommended cadence and time it may take to keep a well refined backlog.

*Note, “Grooming” and “Refinement” are synonyms. Since the recording of the webinar, the industry has moved away from the term “grooming” and adopted “refinement” in its place.

Print pagePDF page