When Agility Becomes Senility
Agile Team Effectiveness Deteriorates Without A Meeting of the Minds
Things change fast when you work at a startup. The feature you start building today may be obsolete by the time you finish. The common solution is to iterate. Sprint, fail fast, get feedback, and sprint again! All the while being responsive: deliver features continuously, fix bugs immediately, and above all stay agile.
Agility is the ability to move quickly and easily, changing directions as needed. However, all this intense activity and relentless pivoting can waste a lot of energy.
The purpose of agile methodologies is to deliver valuable software that meet customers’ changing needs. Unfortunately, this is sometimes treated as an excuse to fail to define those needs in the first place. Development becomes the tool by which the requirements are discovered. The process goes something like this:
- Someone has a vague idea.
- Something resembling the idea is developed.
- People see it and want changes.
- Iterate.
It looks like an agile process, but is missing one key component: collaboration. The team must come to a meeting of the minds regarding the features to be built. Otherwise development will be unfocused. Rather than an agile team, you’ll have a meandering one: changing directions but never really understanding where they are going. Senility has set in.
One Team, One Mind
In some ways collaboration is a double-edged sword. Without collaboration between developers and stakeholders the team will not understand what it should build. However, developers must also be insulated from stakeholder input so they can focus on implementing user stories. Continuously modifying requirements is detrimental to developer efficiency.
Scrum’s solution to this problem is time-boxed sprints. During a sprint developers are insulated from changing requirements. The end of a sprint is the time to reassess priorities and pivot. Developers can more efficiently implement features, while business people have frequent opportunities to review the results and ask for changes.
This does not mean developers and business stakeholders should not collaborate during the sprint. Collaboration should be continuous. Working on user stories for future sprints is fine. Also, it may turn out that a user story is not defined well enough to implement. This usually means the team did not come to a meeting of the minds.
In this case, you should consider delaying the story’s implementation to the next sprint. This keeps developers focused and encourages the team to better define stories in the future. Sometimes the poorly defined user story is a critical one, other times not. The sprint plan should be changed only in critical, and hopefully rare, situations.
Therefore, care and effort should be put into sprint planning and user story creation. Simply sending a feature request to a developer is not collaboration and does not create a shared understanding of what is to be built. The goal of collaboration is to create a meeting of the minds within your team.
Only when your team is of one mind, can you avoid senility and maintain agility.
Got feedback? Tweet at me: @ruliosity
