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.]
Leave a comment
- May 2013 (10)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)