The while you’re in there approach says that if you’re working on some code for a user story that happens to have technical debt in it, pay off that technical debt during the course of implementing the feature described in the user story.
Over the years, I had moved from favoring the tech story approach to supporting the while you’re in their approach. The reason is that every user story must result in value being delivered to the stakeholder. The stakeholder mentioned in the previous sentence is, of course, the end user as represented by a persona, and the end user doesn’t directly see any value in a tech story. So we pay off the technical debt in our code while we’re in there implementing a user story.
Most businesses have the same view as most software projects with respect to stakeholders: there is one type of stakeholder. For software projects, it is the end user, and for businesses, it is the shareholder. Is there really just one type of stakeholder for software projects and businesses? One of the core tenets of Conscious Capitalism is that by recognizing that a company has multiple types of stakeholders and by delivering value to all of them, businesses can achieve greater success and have a more positive impact on the world.
I’m not going to provide a thesis on Conscious Capitalism here, but I am going to mention that the company I work for, Improving, practices Conscious Capitalism, and our CEO Curtis Hite is on the board of directors. It’s worth listing its core beliefs:
1. Higher Purpose. Businesses should exist for a higher purpose, not just for making a profit.
2. Stakeholder Orientation. Recognize that a business has multiple types of stakeholders, and it needs to create value for all of them.
3. Conscious Leadership. Conscious leaders understand and embrace the higher purpose of a business and focus on harmonizing the interests of all stakeholders.
4. Conscious Culture. A business needs to intentionally develop a culture that promotes its values and purpose in a way that connects its people and stakeholders.
What would happen if we applied the principles of Conscious Capitalism to a Scrum project? Let’s call it Conscious Scrum.
A Conscious Scrum project has a higher purpose, aligned with the business, that drives its existence and creates enthusiasm among the people who work on it. My last project at NASA was a space operations planning toolset whose purpose was to enable human deep space missions that would ultimately lead to permanent human habitation of other worlds. Too grandiose? Perhaps. But did it make me look forward to going to work every day? Dang right it did!
Have you ever worked on a project that was led by someone who could communicate its higher purpose in a way that inspired people, and who created a culture in which everyone involved with the project felt like an important part of something much bigger than themselves? Wasn’t that your all-time favorite project? The aforementioned space operations planning toolset project had such a leader, and it was and always will be my favorite project.
A Conscious Scrum project recognizes multiple types of stakeholders. Which types of stakeholders does a software project have? There can be many, such as:
End users
The manager who is paying for the project
Software developers
The Quality Assurance team
The Scrum Master and Product Owner
Sales and marketing
Suppliers of software libraries, frameworks, and tools used in the project
That’s seven stakeholders off the top of my head, and you can probably think of more. A project needs to provide value for all of them.
What does Conscious Scrum tell us about how to handle technical debt? Though the while you’re in there approach has value for small amounts of technical debt that can be paid off in an hour or two, the tech story approach is the best way to pay off significant technical debt. Documenting technical debt in this way facilitates discussions with all affected project stakeholders in order to properly prioritize it.
We don’t have to get into technical discussions to do this; we merely have to weigh the cost of paying off technical debt with the cost of not doing so. How do tech stories result in value for multiple types of project stakeholders? They save money for the manager who’s paying for the project. Up to ninety percent of project expenditures occur during the maintenance phase (after the initial release to production). Spending a little extra money now to pay off technical debt will pay dividends later.
End users continue receiving a stream of new features because paying down technical debt on a regular basis keeps the codebase in better shape and flexible enough to support new requirements, including features we can’t even think of yet.
Software developers have a better codebase to work with, making it easier to add new features. Working with a good codebase every day increases job satisfaction, and makes it easier to retain talented developers and attract new developers to join the team in the future.
The QA team faces less pressure to increase their testing throughput in order to get user stories released prior to the end of the sprint because flawed code resulting from technical debt may have difficulties in passing its tests and may need to be fixed up until the last minute.
The Scrum Master and Product Owner get more visibility into the work that’s being done, enabling them to calculate more meaningful velocity values and get a better sense of the project’s actual status.
The sales and marketing team also sees value in tech stories because a steady stream of new delivered features maintains their competitive advantage, and results in a better product to sell and advertise.
Conscious Scrum leads us to recognize and generate value for multiple types of stakeholders in a software project, and tech stories are a part of that. It also encourages us to find a higher purpose for our work, which gives us a greater sense of achievement and fulfillment.
Want to learn more about Scrum? Contact us or check out the numerous courses we provide on the topic every month!
