by Tony Brill, April 11, 2023

Getting started on the road to sustainable software development

Mind the Gap

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:

  • Executives setting vision and budget relying on summary or roll up information
  • Managers responsible for day to day activities, coordination and status reporting with deadlines looming
  • Teams on the ground trying to make sense of the ask and deliver value as best they can
  • Stakeholders, users, and customers wondering what they will get and when they will get it

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:

  • Delivery Capability
  • Legacy Debt
  • New Functionality Creation
  • Company Culture

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.

Debt contributors to understand or requiring quantifiable metric:


  • What’s important?
  • What does management think?
  • What do the teams think?
  • What do the metrics tell us?

Delivery Capability

  • What is automated in the build, deploy, and test activities?
  • What is your code promotion process?

Legacy Debt

How much work or time is required for:

  • Hardening and manual processes
  • Defects
  • Rework
  • What is the time required to get users operational (new client or release)?
  • How much time is spent running vs. changing the organization?

New functionality creation

  • Does the product road map work?
  • Does the team build in quality or test as a gate?
  • How large are the feature increments and how much time elapses before user feedback or product acceptance?
  • Is new code maintainable and not contributing additional technical debt?

Company Culture

  • Does the organization have a fear of failure?
  • Does the company have a fixed mindset?
  • Does the organization have an over reliance on past performance?
  • Is there attribution bias where success is due to us but failure is explainable as something done to the company?

What areas or questions would you add?

Visualizing Capacity

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.

Technical Debt vs Time

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

Back to All Articles...

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.