Let us start by identifying an Agile change to “requirements.” In the Agile Manifesto it does say that responding to change is more valued than following a plan. However, that does not mean that Agile is changing for the sake of changing. So what is the source of that change? And what changes do we want?
The answer is in the 2nd principle
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
So the customer’s competitive advantage is what we change for.
The competitive advantage does not change on a daily basis. Not even on a weekly basis. Opportunities do arise sometimes, and the opportunity should be significant enough to drop all what we are working on to pursue it.
If your requirements are changing on a daily basis, these are not requirements, these are whims. There are three main costs to this rapid switching:
- Costs of task switching
- Lack of clarity of what is needed
- Inability to deliver consistently
I prefer to approach product development (or even service development) based on the maturity level. Early, implementation, and improvement. In the early stage you are looking for main hypothesis validation, no actual development is needed. There are many resources on how to approach this such as lean startup and design thinking. I would recommend Sprint as a good book and approach to that level of validation. Development starts in the implementation and improvement. Starting development too soon is a major reason for extreme changing requirements.
The second reason I wish to focus on is Founder’s syndrome. It affects founders, product owners and managers alike. In short it is an organizational problem that the symptoms show such as:
- The organization is largely associated with one key person
- Strategy and planning are limited, infrastructure is weak or undefined
- Decisions are made reactively, often in a vacuum, and with a lack of collaboration and buy-in
What can be done? Depends who you are.
If you are the manager:
- Allow your ideas to be validated through a framework with the team. I recommend the ICE-RICE framework.
- Create a validation team that you can work with to generate requirements from proven hypotheses.
- If all fails, turn the team to Kanban with limiting the work in progress. Have a place where you track how many requirements (or stories) are interrupted, and aim to reduce that number overtime.
If you are the employee /scrum master/ Agile Coach:
- After talking to the manager and understanding why. Try to explain the value of focus and the cost of task switching.
- Shorter sprints (1 week)
- Work with the team that one person can work on her ideas
- Have a story that is empty on the bottom of the sprint backlog that the owner can fill at any time and have an agreement on what that means.
- If all fails, recommend the same Kanban idea mentioned above for managers.
