The Discipline of Agile

Scott argues that Agile is a discipline that requires discipline.


September 05, 2007
URL:http://www.drdobbs.com/architecture-and-design/the-discipline-of-agile/201804241

Scott is a DDJ Senior Contributing Editor, Practice Leader Agile Development with IBM Rational, and author of several best-selling books. He can be contacted at www.ambysoft.com/scottAmbler.html.


Lately, it has become common for traditionalists to claim that Agile software development isn't disciplined, a harsh criticism that needs to be addressed because nothing could be further from the truth. I suspect that the people who are making these claims either misunderstand Agile or they're for excuses to not adopt Agile techniques. This month, I describe the discipline required of Agile developers, share my criteria for determining whether a team is Agile, and argue that traditional development provides a false sense of discipline.

Many traditionalists mistake code-and-fix approaches for Agile approaches, and they're correct that the code-and-fix crowd isn't very disciplined. Compounding the problem is that the code-and-fixers often claim to be agile because they're not writing documentation or not doing code inspections. When traditionalists know how to distinguish Agile teams from code-and-fix teams, the criteria described in the accompanying sidebar "How to Tell the Agilists from the Code-and-Fixers" should help, they'll see that they're mistaken on Agile being undisciplined. This is important because it will enable them to consider Agile in a fair light, and more importantly it may make them start to question how disciplined traditional approaches are in practice.

The Discipline of Regular Delivery

The greatest motivator of discipline within Agile approaches is the regular delivery of working software. The shorter the iteration the greater the discipline required to make it work, and interestingly Dr. Dobb's 2007 Agile Adoption survey (www.ddj.com/architect/200001986) showed that 85 percent of Agile teams prefer iterations between one and four weeks in length. Providing concrete, measurable business value in the form of working software each iteration is incredibly tough because you actually have to do your job. Undisciplined IT professionals hide behind detailed documentation, reviews, or other questionable forms of traditional "earned value," which are little more than promises to deliver something at some point in the future.

There are several agile techniques that you can adopt to get yourself out of the undisciplined rut of traditional "earned value". First, do just a little bit of initial, high-level modeling up front to give you the information that you need for initial planning and architectural decisions (www.agilemodeling.com/essays/amdd.htm). This is often on the order of hours or days, not weeks or months, because your focus is on modeling and not on writing extensive documentation. Second, don't overbuild your software to support some mythical future requirements that may never be applicable but instead work in the priority order as defined by your stakeholders (more on this below). Third, adopt a just-in-time (JIT) approach to planning instead of the false security of a detailed, up-front planning. Mike Cohn's Planning Poker (www.planningpoker.com) is a perfect example of this because it easily enables people who are doing the work to plan it out on a JIT basis. Interestingly, the Agile Adoption survey also showed that the fourth most useful work product on agile projects is a detailed iteration plan yet the least useful was a detailed Gantt chart.

The Discipline of Quality

Agile developers take a test-first approach to development where you iteratively write a single test and then just enough production code to fulfill that test. This is easy to say but in practice requires significant discipline because it's very easy to assume that you, or someone else, will do the testing later. It's also very easy to assume that you're writing great code and that you don't really need to write a test for this "obviously simple" code that very clearly could have nothing wrong with it.

As I described in Agile Testing Strategies (www.ddj.com/development-tools/196603549), many agile teams choose to have an independent test team doing investigative testing in parallel to the construction efforts. This requires discipline on the part of the development team because the tester(s) will regularly provide defect stories that should be treated like new requirements to be prioritized and put on their work stack appropriately. True defects, as opposed to potential new features, should be addressed by the team quickly to avoid increasing their technical debt. Traditional teams often let defects build up throughout the project, if they even detect them at all, with the intention of addressing them at some mythical point later, a very risky, expensive, and undisciplined way to work. Following this approach, developers very likely will not provide them with detailed specifications, as it's not required for investigative testing. Instead, testers are provided with a new build on a regular basis, at least once an iteration although nightly is even better, so that they can work with the most recent version of the system available. Handling this sort of "chaos" requires significant discipline on the part of investigative testers.

There are several quality-related development techniques that require significant discipline. First, it is common for agilists to follow shared coding conventions, database standards, and even documentation guidelines, requiring agile developers to conform to the agreed to norm instead of simply following their own preferred approach. Second, it requires great discipline to refactor only what is needed right now for the task at hand and not fixing a lot of stuff that should be done at some point. Third, the discipline of requiring that builds be successful before continuing on with the development of new functionality is absolutely critical because it promotes code convergence within the team and a continual focus on quality.

The Discipline of Active Stakeholder Involvement

Stakeholders—including business stakeholders, operations and support staff, and other enterprise IT professionals—are actively involved on Agile projects. Ideally, stakeholders are involved every single day throughout the life of your project, actively participating in modeling and testing efforts and sometimes even in development (yes, stakeholders can learn to prototype and even to write production code). This level of involvement enables them to see the inner workings of your software development efforts, motivating developers to act in a more professional and disciplined manner. It also motivates developers to focus on the actual priorities of their stakeholders and not their own personal priorities.

Effective active stakeholder involvement requires a clear definition of rights and responsibilities within the team. Stakeholders are commonly responsible for providing information and making decisions in a timely manner, and for prioritizing requirements. Developers must provide accurate estimates in a timely manner, commit to and honor those estimates, and explain the technical trade-offs associated with various decisions. Stakeholders and developers must respect the decisions made by others on the team, even when they disagree For example, a developer might not like how the requirements are prioritized but must still work on them in that order, and a stakeholder may not like the estimate given by a developer for a specific work item but must still respect it. As you can imagine, following these philosophies requires discipline at all times by everyone involved.

It is interesting to observe that by providing working software every iteration and supporting active stakeholder participation, stakeholders are given insight into the actual status of a software development project. This enables business stakeholders to effectively govern IT, the topic of next month's column.

Discipline at Scale

There are several "Agile at Scale" practices that require a level of discipline rarely seen on traditional teams. First, Agile teams not only do a bit of initial architecture modeling at the beginning of a project, they also do the work necessary to prove that the architecture works early in the lifecycle. This practice, common in the Unified Process, reduces technical risk because it doesn't assume that the architecture works simply because the architects say that it will. It requires greater discipline than the traditional approach of detailed up front modeling because it becomes very clear very quickly whether the team actually has what it takes to deliver a working system.

Second, identifying quality of service (QoS) requirements, such as security and usability issues, and then convincing business stakeholders to weave them into their prioritized work item stack requires significant skill and discipline. It would be undisciplined not to address these requirements at all, but almost as bad would be to invest months at the beginning of a project to address them before delivering anything of business value. Yes, it's a lot of fun to work on cool technical frameworks, but that isn't what our business stakeholders are actually paying us for.

The third scalability issue surrounds software process improvement (SPI). The Agile approach is to regularly, at least once an iteration, take the time to consider how effectively the team is working together and whether something can be done to improve things. This continuous SPI approach enables Agile teams to take advantage of their insights right away, improving their productivity throughout the project. It would be undisciplined not to attempt SPI at all or to wait until the end of a project to identify "lessons learned" in project postmortems that do little more than give people a sense of closure after their traditional death march.

The 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.

How to Tell the Agilists from the Code-and-Fixers

Sadly, there is no official definition for "Agile Software Development" against which you can determine whether a team is agile. However, I've found true Agile teams:

• Take a test-driven approach to development.

• Work very closely with their stakeholders on a daily basis, and the stakeholders have active roles on the team.

• Produce working software on a regular basis and can show a clear track record of doing so throughout the project.

• Work in an open, collaborative, and self-organizing manner.

—SWA

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.