by Tony Brill, April 11, 2023
Working software is the primary measure of progress. Principles behind the Agile Manifesto
One of the most prevalent topics for many of my peers has been on getting a better view on their software development teams perform. The complexity of software development including the difficulty in effectively articulating user needs makes the job difficult. Throw in attribution bias, the job becomes impossible. The perception of IT suffers as a result. Given this, I’ve been talking with others and thinking a lot about the topic and what to do.
My moment of clarity happened unexpectedly when I was talking to my close friend, the late Jared Richardson, and remembered the mind the gap signs on the subway platforms in London. We often have differing views on what’s happening and a tendency to not always remember clearly the past decisions we’ve made. As with so many other things, a view into the different perspectives seems the right place to start.
Think about the different perspectives involved and some of the challenges faced bridging the views:
Now factor in the normal business flow and the time these groups traditionally spend together. Far too often, they typically work within their own groups managers in meetings, executives in meetings, teams working together, and stakeholders doing what they do. It’s not much of a stretch that as a result, the groups tend to form their own perceptions and culture that will, over time, influence the members within that group. This in reinforces the group’s culture and dynamic. Without deliberate effort, interactions devolve into “us” versus “them”. This bolsters the attribution bias, and around we go again.
The biggest problem in communication is the illusion that it has taken place - attributed to George Bernard Shaw
Welcome to the gap!
To close the gap executives, managers, teams and stakeholders all have a clear view of where they are and how their views align with the other groups’ views.
Having transparency and dealing with perceptions can be a major challenge for an organization. While it may be difficult to achieve a level of clarity and manage expectations, it’s certainly obtainable and a worthwhile goal. There are numerous examples of the challenge. One that comes readily to mind is when a stakeholder screams for a new feature (and I need it today!).
To deliver this new “I need it today” feature, teams make decisions about how to build the feature. With the time pressure, they often take short cuts to deliver what the stakeholder wants. With no transparency, the stakeholders don’t know what decisions the team made, and how it will impact delivery of future “I need it now!” features. This creates a gap between the stakeholder’s view, “I can quickly get what I want” and the teams view “We build quality software.”
As the software cruft accumulates feature delivery takes longer, contains more defects, and when all is said and done, stakeholders are left with a poor perception of the delivery team. The team needs to manage stakeholders perceptions. However, managing perceptions is only possible if you have visibility and transparency.
In an effort to provide a starting point for putting development teams on a path to success, I’ve started with transparency. I’ve added other areas as well which are:
My goal is to ask the questions that need to be answered to get teams on the right path. Many of the questions are leading and don’t say how to gather the data. They are just the questions that would need to be asked.
What follows are my questions by area. Based on the level of psychological safety in your organization, you may need to tread lightly.
How much work or time is required for:
What areas or questions would you add?
Using the slope intercept equation where X is time, Y is debt, m is slope and b is the y intercept, we could then track progress assuming you could parameterize the questions. While there is some work to parameterize and capture this information, it could be valuable to do so. I do want to point out that I’m not suggesting using this for measuring progress, just as something to help provide a level of understanding around transparency and technical debt.
For me, working software is always the measure of success. However, if we did this, it would allow us to then set a goal of reducing the y intercept (the earliest point in time where debt can be re-mediated).
Does a linear equation work for this or would I need something else like a logarithmic curve?
I’d love to get some feedback on the questions and approach. Send feedback to tony at growsmethod dot com
— Tony Brill
Follow @growsmethod in the Fediverse, or subscribe to our mailing list:
Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.