Discipline & Formality - is there a difference?

When I'm mentoring teams for the first time on agile methods and practices, as an introductory discussion, I sometimes ask team members to tell me what they know about agile development or what they've heard about it. If I'm not getting any negative perceptions I encourage them by asking that they tell me what they've heard regarding challenges in using agile or to describe things they've heard that don' t work, or even better how agile won't work in their environment.  Some of the typical responses are:

• Agile means no documentation
• In agile you can do what you want however you want
• It's about cowboy coding & hacking
• No reviews
• You change requirements whenever you want and as often as you want
• We can't use agile, because the product owner will change the requirements and if we don't have a signed off requirements document before we begin our design and planning we'll never finish on time

These negative answers speak to a perception that agile methods are both informal & undisciplined in their approach to software development. 
If an agile team has no documentation, does whatever they want when they want, just hacks out a bunch of code, does no reviews or demos, and constantly changes requirements within iterations, I'll show you a team that really isn't very agile at all. In fact they will likely be a very poor performing team, no better than other teams and possibly worse.

Great agile teams tend to be highly disciplined using just the right amount of formality in their quest to frequently deliver working software. In speaking about the Culture of Discipline, Jim Collins in his book "Good to Great" says: "The good-to-great companies built a consistent system with clear constraints, but they also gave people the freedom and responsibility within the framework of that system. They hired self-disciplined people who didn't need to be managed, and then managed the system, not the people."  Now that's what agile is all about.

When I think of discipline I think of consistent individual and team behavior where the team is self-organizing and self managing. When I think of formality I think of a high-ceremony process focused on producing documentation. We want discipline with just the right amount of formality. What is the right amount of formality? Since requirements tend to be a common concern for teams, let's use that as an example. 

Instead of writing a detailed requirements document upfront, we opt to progressively elaborate our requirements, writing details for items that have been prioritized to the top of the backlog with items near the bottom only being described at a high-level.  Items at the top of the backlog will have a description of the story, acceptance criteria with the associated executable requirements and possibly even mockups for UI's. Items at the bottom of the backlog will have a high-level description and possibly some high level acceptance criteria. Based on the results I've seen, it's easy to argue that this approach to requirements definition provides more clarity and understanding than traditional methods of documenting requirements, thus producing better results.

Another difference in formality is the approach to reviews. Code reviews may take the form of pair programming where code is constantly under review with one person driving and the other observing. Demos may be conducted in an informal manner without any elaborate slide presentations, but the product owner gets to see working software instead of a completed 150 page document.

As for discipline it shows up in many ways. It's as simple as the daily standup starting on time with everyone present and everyone answering the standard questions. It's as simple as development team members updating their time at the end of each day in order to produce a daily version of the iteration burn down chart to track progress. It includes having a demo with the product owner every iteration. It includes clarifying user stories with associated executable requirements. These are just a few examples of disciplined behavior. Discipline is about the consistent application of the process by self-disciplined team members. Discipline also includes regular retrospectives to adjust aspects of the process approach when needed.

 If the behavior of the team and its team members is not disciplined the results the team achieves may be good, but they're unlikely to be consistently great.