They are known for rapid responsiveness and swarming behavior.
This is the fourth in a series of posts about building great software using agile techniques. The series started here.
I’ve said before, “Plan less, deliver more.”
Others have said, “Stop starting and start finishing.”
Sounds crazy, right? How can your team deliver more software by doing less planning? How can they finish without starting? People who champion agile software development must be nuts!
Okay, these claims use exaggeration to make a point. Agile developers don’t sacrifice planning as a way to write more software. Nor do they skip project initiation activities and simply throw software over the wall into production. Let’s get serious.
The key point is a simple one. Agile teams respond rapidly. They quickly go from planning to designing to coding to testing to finishing. Then, they do it again — and they keep doing it until the software meets the goals defined by the stakeholders.
Don’t lose the excitement.
I’ve witnessed several cases where business stakeholders were excited by the prospect of a new software application. They cooperated in a lengthy discovery phase where requirements were gathered and documented. They grudgingly reviewed and approved hundreds of pages of documentation. Finally, they were told that the software would be delivered in six, nine or twelve months.
In every case, the stakeholders were disappointed and lost interest. In some cases, they sought out alternatives because the delay was simply too long. Business can’t wait.
Agile teams know that delivering something of value, early and often, is a critical success factor. They are fully aware of the need to respond rapidly both to the initial request and to the ongoing feedback after each delivery. Stakeholders need to experience the software not simply read about it. Incomplete software is okay. Nonexistent software is not.
Great teams swarm.
One technique agile teams use to respond rapidly is swarming. This is simply the act of coming together to solve a problem or get something done quickly. Great teams don’t point fingers at others or engage in blamestorming. They pull together and do whatever it takes to finish the current activities.
Swarming focuses energy at a critical area or key activity so it gets done. Most often, teams swarm when there is a mission-critical problem such as system or customer down. That’s fine though great teams use swarming as a planned activity. They recognize that difficult issues will be encountered during sprints and everyone will have to jump in and assist.
When you reduce the time spent on initial planning and designing, you have to anticipate that unforeseen issues and impediments will surface during the project. You could simply toss them into the backlog and worry about them later but your backlog could grow endlessly. Instead, great teams swarm. They try to resolve the issue or remove the impediment now. If they can’t, fine, move it to the backlog but only as a last resort.
Does your team respond rapidly?
Do you see swarming behavior in your organization?
If you answered no, greatness will elude you. Your team may be good, but it will never be great.
Swarming is a natural, instinctive behavior. It’s been observed in single-cell organisms, insects, wild animals and humans. Take advantage of it.
[The next post in this series is here.]