Getting Punched in the Mouth - The Second Agile Manifesto Principle
Estimation. Story points. Hours, Refinement, Guesstimate, Velocity. In my experience, technology businesses that use these types of metrics rarely get a clear picture of software delivery timelines. An excellent plan, full of all the best discovery work, can get roadblocked for any number of reasons.
The second principle in the Manifesto for Agile Software Development defines the required change in mindset in order to maintain and increase agility as a technology team:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
– Principle 2 of the Manifesto for Agile Software Development
Getting Punched in the Mouth
We’ve all been there - working our committed story points, aiming for that smooth burndown line for the sprint. And then, a sprint buster task or idea comes in, and derails the entire sprint. The sprint buster can look like a lot of things - new knowledge, change in business priorities, a bug, a customer complaint, etc. The planned sprint goal may be thrown out, or modified, and the timeline suddenly slips.
Agile process management, such as scrum, tends to set an expectation with the team, individuals, and the business that software development is a predictable process. Sometimes that’s true – more often, it’s not. What this principle is asking us to do is thinking differently about requirement changes as the project unfolds. We should welcome the changes, review them, and adapt the plan in a way that best increases value to the system. The changing requirements are an opportunity to improve the software and hopefully, builds the business’ competitive advantage.
A rebuttal to this mindset that I’ve heard before is “what’s to stop the business from constantly shifting the goalpost, in turn, stopping the app from ever producing value?” I’ve seen this actual circumstance happen on more than one occasion and it frustrates everyone on the project. This principle doesn’t provide a solution on its own - instead, later on in the manifesto, there are several principles that aid in the solution.
HOWTO Change The Team’s Mindset
I don’t know what will work for your particular team - mindset shifting your entire team has to be addressed per individual. Here are some tactics that I have used in the past:
- Address the workflow process as a group and make sure to set clear expectations of how changing requirements are vetted and addressed. Focus on attaching value to changing requirements from the get go and empowering the team to iterate on their process as needed to improve delivery cadence of working software. The outcome of this conversation should be a shared explicit understanding of how to deal with changing requirements. Revisit this shared understanding regularly and assess if it’s still applicable – modify, explicitly, as needed.
- Don’t conflate metrics like velocity with outcomes. Your primary measure as a leader shouldn’t be team velocity, or some other process metric. Instead focus on your team’s outcomes. Make sure that your team understands exactly what you mean when you say “outcome” and stick to that definition.
- Acknowledge the negative emotions that come with changing requirements, but don’t dwell on them – adapt by integrating as required, and move on. The reality is that changing requirements won’t end, especially if the business is building competitive advantage with the technology. Recognize that the business cares about providing value to customers and partner with them to realize that value with technology.
- Empower focused conversations between the business and engineers with the intention of getting to the right answer for addressing changing requirements. Help the business understand the technical impact of a changing requirement – that understanding may change what the right approach is to satisfy a requirement, what the timeline on delivering that approach may be, and what the next steps are.
Wrapping Up
Changing software requirements are a function of a healthy business building competitive advantage. Customer feedback, changing business landscape, and evolving strategies are all drivers for change. Shed the negative mindset of changing requirements – instead, welcome that change, investigate, adapt, and move forward. That’s the mindset of a truly agile software development team.
