Software Delivery - The Same Problem Again And Again
From time to time I hear people say their teams are encountering the same problems over and over again. It happens with teams our company is coaching and with our own teams. People mention the same pattern at various user group meetings. People raise the issue on discussion lists, as in this recent thread. I've had participants at workshops mention the same pattern, as described here.
No project runs perfectly. I doubt anyone really expects that. In cases like these, I think the problem is that teams are experiencing the same issues again and again. They aren't resolving the issues. Obviously, every issue is unique and there's no way to prescribe a universal cure. But there is a key agile principle to keep in mind, and a particular agile practice that provides a good starting point for resolving issues. The principle is the self-organizing team and the practice is the heartbeat retrospective.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
In Scrum terms, this principle is expressed as self-organizing team. Use of the term has broadened beyond Scrum and is now used generally by people interested in agile and lean software development. Scrum also defines Team as a role on projects; it's the role that is accountable for delivery. When you take these two concepts together, the implication is that an agile development team is accountable for delivery of the software and has the responsibility and the authority to see that they get the job done.
When a team is experiencing the same issue over and over again, one has to wonder whether they understand this concept or if they are waiting for someone else to resolve issues for them. What should the team do? Well, the short answer is they should do something rather than nothing. Sure, that's a glib answer; it doesn't offer any concrete suggestions. The team has to decide what "something" means. In keeping with the first value of the Manifesto, there's no process-oriented, mechanical, rote, cookbook answer. The team has to come up with its own answers.
Fortunately, there is an agile practice that teams can use to accomplish this: The heartbeat retrospective. There are many ways to conduct a retrospective and a number of books have been published to describe various approaches. A good one to start with is Agile Retrospectives: Making Good Teams Great by Esther Derby, Diana Larsen, and Ken Schwaber. The Agile principle that applies here is:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I don't intend to describe retrospectives in this post, but I do want to point out that it's the team's responsibility to deal with delivery issues, and there are well-understood tools available to help them do so.
Besides just talking about issues, there are also many ways to mitigate or resolve impediments to delivery. One technique is described in this blog post. I'm sure teams can come up with many more ways to deal with delivery issues, once they recognize and accept that the responsibility lies with them, and their toolbox for issue resolution is well-stocked. For those teams that are experiencing the same problem again and again, maybe the behavior they need to "tune and adjust" is the way they manage delivery risks and impediments.
There's another possibility: A team that is trying to apply agile principles in a non-agile organization may not be granted the level of autonomy called for by agile principles. Team members may understand that they are accountable for delivery and they may be perfectly willing to work with people in other parts of the organization to remove obstacles, but their own management does not allow them to work directly with others in the organization. Instead, any communication with groups outside the team must be done through formal channels. When that is the case, the first problem to solve is the management problem. The team members will be unable to resolve issues if management handcuffs them to their desks. But that is a different story.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)