September 05, 2007
The Discipline of AgileThe Discipline of Teamwork
Agilists, when given the opportunity, will rarely work alone because they know it is too risky to do so. It requires discipline to follow non-solo practices such as pair programming and modeling with others because it's too easy to assume that you're smart enough to get the job done quickly by yourself. It also requires discipline to be responsible for the entire system, not just your little part of it, motivating you to work closely with and thereby learn from people with different backgrounds than your own.
It requires discipline on the part of management to stay out of people's way and allow them to self organize, even when it's clear that the team is likely making a mistake, and not try to plan everything in detail for the team. Providing people with learning opportunities such as this can be frustrating at times but is absolutely critical for growing your staff. Another aspect of agile project management discipline is the act of holding a daily stand up meeting to promote communication within the team about issues that really matter, such as what everyone is doing and what problems they're running into. This forces you to confront and deal with problems as they arise, instead of papering them over with overly optimistic status reports.
Agile software development, when done properly, is highly disciplined. Agile is much more highly disciplined than traditional development, which in turn is more disciplined than code-and-fix development. If anyone tells you that Agile isn't disciplined, then ask if they have ever been involved with an Agile project, and if so, whether it met the criteria defined earlier. I have yet to meet someone with both real-world Agile and traditional experience who claims that traditional is more disciplined, and it appears to me that traditionalists are clearly throwing stones in their glass house by claiming otherwise.
I'd like to thank Ted Rivera of IBM for his detailed feedback regarding the initial draft of this column and Bill Krebs, also of IBM, for the various insights that I gleaned from him in the conversations that we've had around this topic.
|
|
|||||||||||||||||||||||||||||||
|
|
|
|