I took inspiration from this week’s stream about Refactoring vs. Rewrite. In this issue of 🔮 Crafting Tech Teams we explore why requirements change and how you can use that to your advantage. You can ignore this and hope to get lucky as your project evolves. Or you can keep reading and form a plan.
- Why do requirements change? What requirements are and what they are not. Explore the root cause for scope, feature and priority changes.
- A team that cannot act to change stagnates. Death by a thousand cuts caused by technical debt and outdated market insights.
- Good change and bad change. Align economic incentives with your compass. Vision, clarity and roadmaps are vague concepts for seeking certainty. What they provide is a set-in-stone view of the future. How do we adapt this way of thinking to be change aware?
Why do requirements change?
Software is called soft because it is meant to be malleable. Easy to mold. Reshape. Unlike structural engineering and construction where things are irreversible and long-lived. A building when erected has to face the test of time for at least 50 years. Software barely has to survive a quarter.
But yet, most software outlives the companies that built them. Most code that ends up being written gets written off once the company goes bankrupt, gets acquired or—requirements change significantly.
Why does it happen? Simple—because it can. Software is soft. And if it can, it will.
The motivation is clear: changing requirements is sometimes—but not always—the sign of someone in product or senior management correcting course for market trends. In short, improving the product.
But that’s not the most common reason for requirements to change. Reading the book Implementing Lean Software Development in our last month’s book club I cam to a realisation that I was always aware of for two decades but didn’t have the words for. In the book’s chapters on Value-stream mapping and Waste light is shed on a simpler, more pervasive reason for requirements to change: taking too long to ship. Often the desire the ship later comes from an unbridled need of perfectionism.
Humans have expectations, you see, and stakeholders need feedback. The longer the feedback loops—ie. the dark swamp of “nothing being deployed”—the more stakeholders will be incentivised to manage this problem. This is where dark agile and faux-scrum originate: trying to manage and bureaucratise a state of uncertainty.
The entire flow behind agile practices isn’t so much that productivity increases, instead it gives clear market-driven signals on a minimal feedback loop that matches the expectations of stakeholders. That is what defines a sprint length in scrum. That is the process and cadence that needs to be established when the agile manifesto mentions interactions over processes.
Bryan Finster had a great take on this a few hours ago regarding CI/CD and teams who struggle adopting trunk-based development. Trunk-based development is the quickest form of feedback you can have for any value-stream change that requires software development.
Overall, we as engineering leaders want requirements to change. We want to promote healthy change and act on them the same way as if you had changed your order in a restaurant. Calmly and without needless ceremony or drama.
A team that cannot act to change stagnates
You may also describe “cannot act to change” as lack of agility. Though agile is quite a loaded term nowadays, I still like to think that there is nuance to the usage. You see—adopting agile or adopting scrum or adopting SAFe was never the goal of agile. The goal of agile is to achieve continuous delivery.
Because you want to get feedback pro-actively. Build a team of professional product engineers. Don’t wait for the hammer to drop and the management team to step in and start micro-managing via remote control by fragmenting the roadmap. This is by far the most common stress-response I see in organisations where the engineering department’s release cadence is detached from feedback loops.
They change the roadmap, the roadmap invites another cycle along with unfinished work from the previous one. Things obviously don’t go according to plan because they never do, and the cycle repeats.
Teams stuck in this loop suffer from a severe lack of market-feedback as their features rarely make it out to users on time. Even if they got feedback, they would have no time, focus or energy to act on it. This may lead to burnout and other negative side-effects that make managing your team challenging and unpredictable.
But let’s not dwell on the negatives.
What’s the opposite of stagnation? Movement. Rise. Growth!
Talking about technical debt and lack of feedback is only one side of the coin. Your team needs to be inspired by their growth potential. Not neutrality. Not stillness. That is the last-line of defence before the bad decisions and tech debt kick in again.
Asses your priorities as a leader and help your team get back on track on their growth potential:
- What do you wish to learn and outgrow?
- What kind of team do they wish to become in the next year?
- What’s next for them and how to prepare for that?
- What are the constraints on the project?
- How do we do more with or go around constraints?
Good change and bad change
Transformations, digital or agile, fail for one reason primarily: taking on to large steps without solid foundations.
A good change in requirements is something the team can agree needs to be addressed and does so without waiting for permission or oversight. The team should either ask for permission or review, but not both. Good requirements are the permission-side. Bad requirements lead to several rounds of review—possibly in each step of the process. This is where the major waste may happen.
A bad change is something the team is mandated to respond to without understanding or having the knowledge to analyze why this decision was made. This creates knowledge silos, often between a product and sales and engineering departments. A curative solution to the symptoms is more process. More review. More waste. A holistic approach is going back to embracing good change—learning, growing, asking hard questions.
- Look to remove as much needless procedure as possible
- Rather than documentation, specs and roadmaps, focus on short decision records (a few sentences).
- Shift important conversations into the beginning of a cycle and help your team scope things into smaller-than-comfortable increments. Ideally days. Don’t plan to spend the entire budget from the get-go.
Requirements are best reviewed and accepted by all parties, not merely handed off. Roadmap meetings often have this negative downstream effect as the engineering department can easily mistake the stakeholders for the domain experts. That’s where you as the leader come in to iron out the communication channels and make sure your team are talking to the right people at the right time in the product cycle.
"A team that invests into failures in order to grow can reach the stars"
Having a coach and mentor is You taking control of Your Growth. In my two decades in the tech industry my biggest learning moments were my biggest mistakes and investment. Making mistakes is easy. Maximizing learning is the hard part.
This is where a coach can help you most.
👉 Are you a Software Developer on your Journey to become a Senior?
👉 Are you an aspiring Tech Lead struggling with the burden of Leadership?
I have been there; I have done that–let’s have a chat 🤝
I got your back. Book a call.