While I was contemplating the discussion of the second of the three core capabilities for teams to prosper after the COVID-19 lockdowns are lifted, I got an email from a friend asking why I did not think the business environment would return to where it was a few months ago. While reading my friend’s email, I got a breaking news text reporting the World Monetary Fund saying they expect one of the steepest recessions on record. Last evening I read a piece from Goldman Sachs discussing whether the slowdown would follow a V or U pattern (the U pattern will take longer to recover). The experts all agree that the future will be different. In any scenario, there will be dislocations and a new reality; that new reality will require teams to prosper. Teams that focus on an outcome of efficiency, dependability, and effectiveness will have the clearest path. One positive is that all of the core characteristics are demonstrable.
Dependability is perhaps the most difficult of the three characteristics to operationally define. Part of the problem is that dependability and reliability get combined when we are discussing team performance. At a system level, Beth Leonard, Director, Delivery Excellence at Attain, states that IT Service Management (ITSM) defines reliability as, “the measure of how long a service, component or configuration item can perform its agreed function without interruption.” Beth further points out that, “dependability – especially related to people – it is more subjective than reliability from a measurement perspective.” Jeff Dalton, President of Broadsword, makes a similar argument suggesting that dependability means that work provides what was asked for and reliability means that it performs to expectations. Both are required for a product owner to be satisfied. Anthony Mersino, President of VItality Chicago, states, “operationally I don’t see much of a difference.” I am going to actively conflate both terms based on a common synonym, trustworthiness. Conflating reliability with dependability. This allows us to demonstrate dependability without reverting to surveys, expensive and time-consuming phycological tests, measuring whether people show up to work or semantic arguments about the difference between the terms. Using a simple operational definition of dependability as the ability of a team to say what they will do and do what they say we can demonstrate dependability. Further, we can translate this simple definition into three demonstrable behaviors. A team is dependable if they can do all of the following items consistently.
The team establishes agreement on what work it will deliver (regardless of time horizon) before it starts.
A team agrees with its product owner(s) or stakeholders on what is to be accomplished. This can occur as a result of Scrum planning or daily planning for a continuous delivery Kanban team, the scope of the timeframe is less relevant than planning being a conversation between all involved parties. The team delivers the agreed-upon work at the agreed-upon time and place (not everything is software) agreed upon.
The team needs to deliver. Note there are several implicit agreements that all parties make when they are agile, including leaders not redirecting the team and teams not accepting work outside of normal work entry paths. Another implicit contract between the team and organization is that work items, once started, will meet the definition of done at some point. The agreed-upon work product meets product owner expectations.
Completing work items only matters if what is delivered meets the expectations of the product owner. Just delivering stuff that is not useful or does not meet quality standards does not meet the definition of dependable.
A very simple metric that I often use for Scrum (or other incremental frameworks) to quantifiably monitor dependability is story escape rate. If we qualify that a story or work item must exhibit all three characteristics, then a team can monitor whether what they say they will do and what they deliver is consistent. The calculation is simple:
1 – (items delivered as agreed / items agreed upon) = escape rate
For example, if a team delivers 9 items that are acceptable to the product owner within the agreed-upon time frame of 10 total agreed-upon items, there is a 10% escape rate. (I have a minor twist on the metric to address work that enters a sprint/iteration after planning which I will document later; ask if you need it now). This metric will probably never be a perfect 100% over multiple sprints, but it should not be widely erratic. The escape rate metric should help the team to become dependable (and prove it) that can be counted on to deliver what is agreed upon when it’s needed.
Title: Dependability In Software Development: Preparing For Life After COVID-19
Sourced From: tcagley.wordpress.com/2020/04/14/dependability-in-software-development-preparing-for-life-after-covid-19/
Published Date: Tue, 14 Apr 2020 23:55:33 +0000