Root Cause Analysis – Core Competency

Related to removing impediments is the skill of identifying root causes, typically called Root Cause Analysis (RCA) within the technical world.  Some Project Leaders (be it a traditional Project Manager, Scrum Master or something in between) may believe that RCA is really a skill that the team has full ownership and that the Scrum Master should simply connect people with the right resources to either swarm or focus on the right path to resolution, but believe that approach is short sighted.

An experienced Project Leader will be like the Larry King of root cause investigation, asking questions to determine the signs of where a root cause may be found.  Project Leaders should help “connect the dots” like Steve Jobs has been famous for saying in his Stanford Commencement address in 2005 (  Connecting the dots isn’t just about product vision or strategy but finding the missing part that is blocking the team from completing the blocked task.

Confident many reading this are already thinking along these lines, so I’ll state that there are times with the Project Lead will have no clue about the root cause and should instead play the role of observer so they gain more experience on helping identify trends for future issue resolution and impediment removal.


The Art of Removing Impediments

Been noticing in my career that one skill set Project Managers / Scrum Masters should master, but often don’t is the art of removing impediments.  This is not an easy skill to master and requires curiosity, courage, diplomacy, tenacity and a little bit of creativity and communication.

Often removing impediments involves connecting the right people together.  It is typically a social problem.  Yes, going to Uncle Google or Father YouTube certainly helps with any issues that plague people  the time like, “why doesn’t my OneDrive show up on Windows File Explorer”, but often with teams, these are very specific and challenging issues that won’t have an apparent answer on the grand Internet.

A true leader, whether a “command and control” leader or “servant leader” or something in between should have the curiosity to always be asking and encouraging the delivery team to bring up impediments that impact a person or the team within a short period of time.  I’ll usually state, “come see me in an hour if you and your contacts haven’t been able to figure out a solution to a given issue stopping you”.  However, the expected escalation time frame is really specific to the situation of the team, the project and the company, so use your best judgment, knowing that many team members will stretch the escalation time if they think they are close (but may actually not be even in the same planet).

Also, a project manager should have the courage to ensure the team is following the guidelines on requesting help and be willing to take ownership of resolving that issue with a high degree of urgency.  Project Managers should do anything within their power to help team members as fast as possible, but also show diplomacy, recognizing people’s time and always making them feel respected and important through the addressing the issue.  Project managers have to deal with the human microcosm of tradeoffs and ensure that those that help resolve the issue get the recognition deserved and also in turn be helped when they are in a time of need.

Tenacity is a necessary core skill a project manager must possess to resolve any team blockage as soon as possible.  Don’t ever give up, especially when you feel like it is hopeless.  There is always a solution, given enough time and thought.  That leads to creativity since the solution may require a different approach than initially expected.  The project manager should encourage the team and any parties that get involved to be educated on the nature of the issue and think through every possible path to resolve the problem.  This requires that tenacity to ensure no one feels like throwing in the towel.

Dual Track Scrum Summary

In my previous blogs of Dual Track Scrum (DTS), I cover the current expansion of Scrum to place more attention on building the right product through the means of a detailed, continuous discovery process tailored for developing better backlogs through multiple tools and techniques, such as story boards, feedback groups and surveys.  This is tracked through a separate discovery backlog similar in usage to the product backlog and feeds the results into improvements in not only the accuracy but the certainty that the right backlog is in place.

This overall discovery backlog (or also called the Opportunity Backlog) should address the pains of the target users, remedies to resolve/alleviated those pains, experiments to validate those remedies and any ideas and further options for product development.  It is very user centric, intended to identify those features that will delight users.  For instance, like many people I use my smart phone to deposit checks.  I used to get frustrated by having to deal with poor lighting or poor focus for the checks and would often have to take multiple pictures to get one to take.  Now, the Bank of America app came up with a version that turns on your phone’s light and auto sets the box so that when you have it at the right place, the app automatically takes the picture for you.  Viola!  Instant gratification!  This is the type of feature that I wanted, but hadn’t expressed.  Bank of America did a good job finding out a chief issue I had with electronic deposits…


I see two primary benefits with Dual Track Scrum:

  1. Increased confidence and improvement of delivering the best product to increase end user adoption
  2. improved handover of the product backlog to delivery

Note if your solution is strictly regulated and have little leverage to change or delivering in more of a waterfall fashion, this may seem like an improbable approach, but would say in my experience in for example the Health Care industry and Government, that the usability of regulated systems are in the most need of Dual Track Scrum.

With regards to the benefit of improved handover, it will directly address the issue many organizations have early in their Agile adoption and essentially break out requirements development, architecture and development/testing into an mini-waterfall process, which breaks one of the few core tenants of scrum of having fully tested, working software at the end of each sprint.  When the product backlog is unclear and backlog grooming isn’t sufficient, often delivery will slow down unless a more thorough approach such as DTS is substituted.

This often happens when a Product Owner is overwhelmed or simply not certain where to take the product next.  Often, I’ve seen Product Owner training for newer Product Owners unfamiliar with Scrum, and that would be a good supplement along with DTS.  Identifying and addressing insufficient Product Owner coverage early in delivery is critical for the successful implementation of DTS.

Cost and time are factors involved and often an approach such as Dual Track Scrum will be sacrificed or not even considered due to those limits.  Every situation is unique, but highly recommend considering using as much of DTS as possible even if “watered down” with the frequency of discovery sessions held is decreased.  Why?  Because cost and schedules will inevitably deliver an inferior product and assumptions with delivering your Minimum Viable Product should be validated frequently.

So if you aren’t sure your solution truly addresses your user’s needs or your scrum teams are frequently frustrated with extended user story elaboration and prolonged marathon Sprint Planning events due to nebulous product backlog items, then try Dual Track Scrum is worth trying and remember to fail (and learn) fast!

Dual Track Scrum Tools and Techniques, Part 2

Within Scrum, a product backlog is used for tracking prioritized development requirements as normally determined by the product owner.  In Dual Track Scrum, it is recommend to use a separate backlog for the Discovery track.  Essentially, the discovery track backlog will “feed” into the product delivery backlog.  Discovery tracks would include techniques such as User Research/Validation, story mapping, building and testing personas, engaging in “what if” scenarios on design, creating minimum ceremony prototypes and tracking Key Performance Indicators.

Consider the opportunity canvas from my last blog (, which covers the pains, remedies, experiments, ideas and options with continuously validating the right solution is being developed.  From that opportunity canvas, user research helps determine what your target audience wants is fully understood.  This can be done via user feedback groups, surveys, usability tests (like A/B Testing) tracking metrics and reaching out directly to the user base.  Now, if you don’t have an existing product, reaching out directly to the user base may be your only option to get direct and candid feedback of product ideas.

Story mapping is a core Agile principle similar to story boarding in the film industry where each step within a solution are created visually through a low fidelity interface in a top down approach.  This is intended to be very flexible so that story can be quickly added and removed as new ideas come up.  At a physical level, a board with post-its work really well.  There are many tools to map digitally and have a preference for FeatureMap and CardBoard, but recommend you research what is best for your needs.  A good article on story mapping is at

When it comes to delivering the right solution, knowing your audience down to a specific persona should not be overlooked.  Build model and “edge” audiences to determine all variances of users.  If your target audience are women between 18 and 35 for a cosmetic app, you should still consider including men of different ages that may have a reason to use the app as well.  These personas should be fed into your story board and real users should be found that closely match these personas to validate assumptions and clarify new ideas.

Holding “what if” brainstorming sessions on what and how to build will help promote continuous improvement and recommend using mind maps as tools to visually expand on asking questions on what the ideal solution would do if time, budget and feasibility were not a limitation.

Quick and repeated visualization is a key to delivering a continuously improving solution.  Through low fidelity prototypes, quick assessment and validation can be used for all the previous steps as a visual aid.  As the discovery matures, these prototypes should mature too, becoming higher in fidelity as features are validated as the right ones to build.  New ideas are then introduced at minimum visualization and mature as they are accepted or disappear if rejected.

Finally, to follow the old adage of “What gets tracked, gets done”, Key Performance Indicators should be determined for validating the benefit of discovery.  Ensuring that new features are being modified and improved is necessary.  If the discovery does not create enough change or no change at all, then the discovery track is broken and must be addressed.  Metrics such as the rate of changes, the projected benefits of those changes and the resulting improvements with user adoption (and funding) are critical to tracking.

I’ve heard of cases where daily refinement sessions to properly flesh out the user stories for the delivery backlog, would be held right after the daily stand up, but recommend this be held on an “as needed” basis, which may be every other day, weekly or even less.  However, a regular cadence should be set for each technique to best track progress.  The outputs of the discovery sessions should be incorporated into the product backlog and transitioned to the sprint backlog by the start of a new sprint.

In my next blog, I shall cover my overall opinion of Dual Track Scrum and it’s usage in today’s solution focused industry.

Dual Track Scrum Tools and Techniques

To continue on Dual Track Scrum (DTS), please note at this juncture, I have not put any of these steps fully in practice and so they are purely from a theoretical perspective, although I am aware that DTS pundits such as Aaron Sanders has implemented these tools and techniques within multiple organizations.

To recap, Dual Track Scrum provides an expanded Agile framework for Product discovery that aligns with Product delivery.  This expands on the rather thin structure around backlog grooming and story boarding thus putting more effort and rigor into that process to continuously validate the right solution is being development.

Remember the tenants of discovery are building valuable, usable and feasible solutions.

There are several tools and techniques available with DTS and will cover the overall current state approach with the opportunity canvas.

The opportunity canvas brings detailed clarity of the current product landscape, in an effort to better define what features are the most important in any given solution.  They include:

  • Documenting any assumptions that would be a product killer if proven false.  Be very open and honest on determining these and can be as simple as “Google releases a similar product”.
  • A clear description of the problems the solution is addressing as well as the solution description itself.  This should be high level from an end user perspective as part of a product theme that is frequently tweaked.
  • Describe the users and customers that currently experience the problem.  Who are they?  What is an example persona?  How much does it impact them?
  • How these problems are addressed today?  There is always an existing process and there are usually more than one.  What are they and how much time / effort do they take?
  • How this solution will provide the users new value/improvements?  Time savings?  Cost savings?  Entertainment?  What else?
  • How to measure whether and how much the users would adopt this solution.  Look at what metrics will make a difference in knowing the predicted adoption rates.
  • Determine the adoption strategy to bring the most users on board.  This should be based on the previous opportunity backlog answers to derive the best strategy.
  • Determine any business problems in building and delivering this solution.  Find out the challenges with delivery, marketing, sales, support, etc. with the solution.
  • Identify and measure any changes in business performance metrics for releasing this solution.  Your business will change with the release of this solution and therefore the measurement of success must factor in this solution.
  • The budget must always be considered on how much can be built for a Minimum Viable Product and when revenue must come in to continue building and expanding the product.

I will cover further tools and techniques in my next blog.  A big “hats off” to Aaron Sanders for much of this material.

Dual Track Scrum continued

In my last blog, the topic of Dual-Track Scrum (DTS) was brought up.  That was for my initial impressions.  Now this blog covers a deeper dive.  The ideas behind DTS started with Marty Cagan in 2009 and expanded to being supported by Jeff Patton and Aaron Sanders, among others.

Essentially, Dual-Track Scrum follows core Scrum for the delivery path and expands on the idea of a parallel discovery path for better and more thorough product development.

This parallel discovery path has three core tenants.  The results of the discovery path should be:

  1. Valuable – This is determined by the Product Owner and the UX/UI Expert and validated by the end user community as something they would want.  Discovery of valuable features is critical to successful delivery
  2. Usable – This is determined by the UX/UI Expert and the Development Lead.  The interface for the feature should be built in such a manner than it is as simple as possible that the users love, adhering to Lund’s Usability Maxims (see
  3. Feasible – This is determined by the Product Owner and the Development Lead.  Dream big, but make certain it’s something that can be done with the technology available.

The discovery process has been expanded into more details as opposed to backlog grooming.  In Scrum, backlog grooming is an exercise for the Product Owner to work with the Scrum Master and key team members to validate the backlog priority and prepare for upcoming Sprints.  Per the book “Scrum Essentials” by Kenneth Rubin, this is done on an “as needed” basis.

In Dual Track Scrum, these are broken into regular scheduled meetings similar to Sprint Planning and Review meetings and should be held in a similar cadence.  Attendees include the Product Owner, Business Analysts (as needed), the UX/UI lead, the Development Lead and the Scrum Master (optional).

These discovery sessions go into much further detail of discovery that brings the end user feedback along with tools and techniques to bring out more accuracy and detail on ensure the right product is being built and evolved over time.  Arguably, most critical component of delivering software is not whether it was built on time, on budget or even in defined scope, but whether the end users like and even delight in it, to expand its usage far beyond original expectations, which leads to growth and success.

In my next blog, I will review the tools and techniques for the discovery path.

Dual-Track Scrum: Initial Impressions

Recently, I attended a Meetup on Dual Track Scrum (DTS), presented by Aaron Sanders, and since unfamiliar with this new Agile flavor of delivery, have done some additional research on the topic and here are my initial impressions.

Dual-Track scrum follows the principle that there should be continuous discovery by the product development team in parallel to the delivery.  This discovery is normally led by the product owner, the lead developer and the UX/UI expert, but can vary to the key roles in product development based on your delivery framework.  Hence there are two parallel or dual paths: discovery and delivery.

One key success factor is to ensure that collaboration of Dual Track Scrum is understood by all stakeholders involved in delivery, from the delivery team to the CTO/CIO, all the way through sales and marketing.

Conceptually and from what I’ve researched, DTS greatly reduces the problem personally experienced with insufficiently documented backlogs that are frequently too scrambled to be DEEP (Detailed, Emergent, Estimated, Prioritized) enough for Sprint Planning sessions.  If this is a problem within your organization, DTS would be an excellent suggestion to try.  However, it is worth noting that some companies don’t have the resources to support this approach and hence getting leadership involvement to bolster resources to implement DTS would be necessary, a task easier written than performed.

At a glance, my current concern with DTS involves scalability.  When mixing in Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS), Dual Track Scrum has an unclear place.  However, it would appear that DTS would scale with some adjustments.  For LeSS, there are Area Product Owners and Area Product Backlogs.  These would be scaled with dual tracked teams and some adjustments would be made for the level of Product Backlog discovery and grooming.  With SAFe, the role of Product Management can be extended for DTS without much resistance, understanding that flexibility is key.

My thoughts on DTS are positive and recommend if your organization has trouble keeping the product backlog detailed enough and/or your delivery teams are having to do an inordinate amount of rework after each Sprint Review to seriously consider Dual Track Scrum as a viable alternative.

In my next blog, I shall go into more detail of Dual Track Scrum with the discovery track.

New Perspective

Always take time to make time by removing yourself momentarily from the hustle and bustle of your work and make sure you are still going in the right direction at the pace you expect out of yourself and your team.

Stretch yourself and be creative in your thinking.  Don’t avoid brainstorming and questioning any of the assumptions you have made with your current work.  Often cases, you’ll find some don’t apply anymore.​

How to Measure Technical Debt

So one of the biggest challenges I’ve repeatedly heard about technical debt is that although the delivery team knows it exists, there is no easy way to measure the actual cost of technical debt.  However, there are ways to help bridge the unspecific to the specific.

With technical debt, using a financial analysis of comparing addressing the technical debt now versus addressing the technical debt later (at a pre-determined point) will bring useful data to make informed decisions.

So how accurate is that data?  What level of confidence will leaders place on it?  One method to help bridge that trust gap would be to use technical debt evaluation tool like SonarQube that can give detailed counts of technical debt risks.  This can then be used as a “ground level up” method of determining the full cost of fixing technical debt now and given as detailed evidence that this isn’t simply “developer guesswork”.  From organizing the reported debt, the seven axes of Quality reported by SonarQube can then be mathematically estimated and used as supporting evidence.
The example chart gives a comparison that non-technical employees can understand.  This speaks in clear financial figures and can be measured to determine progress and where key decisions can be made.

No longer does technical debt have to be the software delivery department wrestling with business.  There can be a common ground for discussion, collaboration and agreement on how much effort should be made to resolve any accrued technical debt.

Engagement Ceremony

If there is ever an art to delivering technology, it’s about knowing when and how to prioritize events as they unfold.  Some events are small and may only need an email.  Others, a simple test or instant message may do.  At higher levels of modality are direct phone ​calls with screen sharing, Skype, or even face to face meetings.

A recognition of when there is not enough or too much ceremony for the roles involved.  If a dozen emails go by for something that would take two minutes to discuss, then using email is the wrong modality.  Sometimes, that isn’t clear until the communication unfolds, but immediately change the mode if you see that it is dragging down in the form of communication provided.

Also, too much communication can happen.  If a meeting takes up more time than actual doing the work or logging the work is taking up more time than just doing it, the process should be questioned.

​It’s all about business alacrity and a good project manager, and any business professional, should always look for ways to reduce waste in delivery.