Users, Requirements and feedback loops. Oh my!
For those of you who are wrestling fans, that hopefully hit the canvas. For those of you who are not, let me briefly explain. It was a term coined by a wrestling commentator back in 2000 that has stuck through time and normally can be found applied to anything that comes in threes.
Anyway, enough about wrestling…
I read an article recently from the StackOverflow Blog written by Jared Toporek and it got the cogs spinning. The title was:
The hardest part of building software is not coding, it’s requirements
Having been a software engineer for the past twelve plus years and having had the privilege of working in many distinct industries at varying degrees of both technical and managerial seniority, this struck a chord. Particularly the reference to the all too common saying It’s not a bug, it’s a feature.
This statement has almost become a meme in the technical world (I know I have used this to joke about a particular scenario more than once!), but based on experience it got me thinking about the potential reasons as to why this ultimately happens and I believe it stems largely from process, communication and ownership, or lack-there-of.
Let me attempt to explain with an example:
Your business want to launch a new system or extend an existing system by adding a new large feature. In order to do this, requirements are gathered from users by the product team; those requirements are captured, itemised and passed to to architectural teams to come up with designs; Gantt charts being created based off of “estimates” in order to track delivery; designs passed onto development teams to implement; once “dev complete”, the solution is passed to a QA team to test and ensure acceptance criteria is being met based on the initial requirements; should all be well it’s passed back to the user for verification and a decision to be made on whether or not it meets their needs; if so, it’s passed to a support team for day to day maintenance.
Typically, the process can be modelled like Figure 1. The delivery of a change following this paradigm could span weeks, months or years depending on the magnitude of change, and could at the end of the delivery, be so far off the original mark. If we consider what we need in order for something to be delivered successfully following this model, we have to assume that:
- User needs are clearly interpreted
- Needs are accurately translated into requirements and clearly capture what those needs are
- Technical designs produced cover all of both functional and non functional requirements
- Technical designs can be easily understood by development teams
- QA understand the requirements and user needs in order to ensure acceptance criteria are met
- App support teams understand the change in order to handle the business as usual once live
The above is of course a simplified version of reality and there will no doubt be other points of communication, handovers and considerations that would have to be made. What is apparent however, even with condensed list above, is the number of handoffs and dependencies across stages, each coming with their own risk and potential loss of information and context. We know from studies that have been carried out, and are continually being carried out within industry by pioneers such as Dr Nicole Forsgren and Jez Humble, that release cycles which have a high degree of coupling and handover can lead to lack of ownership and autonomy across teams, which can have detrimental effects on quality. This can ultimately be surfaced through the use of DORA metrics as, for example, an increase in Change Failure Rate might suggest that there is a reduction in quality within a given team.
To further illustrate the effect dependencies can have on the probability of success for a given team, Dominica DeGrandis provides an eloquent example as part of her book “Making Work Visible” and as part of her talk at the DevOps Enterprise Summit in 2017.
The illustration goes that a party wish to dine at a restaurant, but in order to successfully dine, all members of the party must arrive on time. Sounds simple right? Lets take a look at the illustration and probability of success in more detail.
For those who love Math as much as I do, the probability can be seen as a function:
P = 1 / 2ⁿ
Where P is the probability of success and n the number of dependencies you have. Without walking through and solving P based on any arbitrary n, it’s probably easier to look at the function plotted graphically were n is in the range of 0 ≤ n ≤ 15:
As can be seen in Figure 2, with just a single additional dependency, our chances of dining successfully have been slashed to a mere 50%. With each additional dependency added to the party, our odds of success are slashed by half until eventually they are near zero the time we have roughly seven.
Random fact: Statistically, (as captured by Statista) in 2021 25.9% of software projects were recorded as failing to meet deadlines globally with a sample set of fifty four respondents. That equates to roughly fourteen failed deliveries. The statistics do not provide any insight into the reason behind each failure, nor what process was followed in order to deliver, but what it does illustrate is the chance of failure is higher than we would probably be comfortable with given the financial cost of producing quality software today.
So what does this all really mean in relation to the aforementioned delivery process, users, requirements and feedback loops (oh my!)?
To me, there are a few things that can help us become more successful at delivering software:
- Keep feedback loops short
We want to get feedback as immediately as possible through every facet of our delivery cycle, both technically and operationally. Why? If we solely look at things operationally with the goal of providing as much value to our users (and ultimately our business) as possible, then we need to know we are consistently meeting the needs of our users. By getting continual feedback over short cycles, we can quickly change direction by making amendments or changes to the system in question based on the feedback to ensure optimal value is being added to a given stream. If we put a technical lens on instead, then working to a Continuous Delivery model coupled with TDD can help ensure that our software is in a constantly releasable state all whilst providing high levels of assurance via our pipelines and test suites as build artifacts are produced.
Random fact: did you know that the mean time for delivery based on studies carried out by CircleCI in 2023 is 3.3 minutes? CircleCI define delivery as being “the average time in minutes required to move a unit of work through your pipeline. Importantly, a unit of work does not always mean deploying to production”
2. Continually iterate based on feedback
As alluded to above, iterating on feedback will help us build a more robust, valuable system for our user base. By feedback, I refer not only to feedback provided by the user but by the system itself. If we have a high level of empiricism within our systems then we can begin to act upon observations and data collected within our small development cycles, ensuring that again we are providing as much value to the stream as possible. High levels of empiricism can also lead to enhanced experimentation within a given system. To quote Dave Farley on the Tech Lead Journal podcast hosted by Henry Suryawirawan around empiricism:
“Engineering is about real world things. It’s not about some ivory tower imagination of a system. So we need to gather feedback from production. We need to be able to understand what’s really going on. We need to be able to make practical decisions based on what it is that we find.” — Dave Farley
3. Keep dependencies to a minimum
As seen above, dependencies can have a massive effect on nullifying any chance of a teams success should there be a high dependency count. By keeping dependencies on teams to a minimum, we automatically increase their chances of success mathematically. How can this be done practically? One approach is by looking at team topologies within an organisation and how they are structured and aligning teams to streams.
Is the business structured in a domain first way that would allow cross skilled teams to be able to own a value stream in its entirety? Do the teams themselves have the required skills and autonomy in house that would enable them to drive change from concept to production with little input from external teams?
“A stream-aligned team is a team aligned to a single, valuable stream of work… The team is empowered to build and deliver customer or user value as quickly, safely and independently as possible, without requiring hand-offs to other teams to perform parts of the work” — Matthew Skelton & Manual Pais, Team Topologies
