The Discipline of Agile (followed from a post on Mr. Appelo’s blog) made me pause and think. Mr. Ambler’s article does an excellent job of breaking down agile into some key disciplines:
- Regular Delivery
- Quality
- Active Stakeholder Involvement
- Scale
- Teamwork
I was thinking, though, that the list was far too specific. Some of these things are results of similar disciplines—for instance, Active Stakeholder Involvement and Teamwork are both principles of good communication. Others are esoteric, such as Scale.
I decided to reorganize these disciplines a bit and change them around, hopefully making them more broadly applicable to agile processes. Below are what I believe to be the disciplines of an effective agile/lean project.1
The Discipline of Adaptability
How can you talk about agile and not mention adaptability?
The bottom line is that for agile to work, your stakeholders and your team must (willingly) be flexible. No set-in-stone product design, no hard deadlines, no non-negotiable items. An agile project is a conversation, not a lecture.
The hard truth is that everything changes, especially software. If people are not willing to adapt to a changing environment, then agile will fail before it even starts. The team and the customers must be open to receiving change and handling it appropriately.
The Discipline of Intervals
One of the foundations of an agile process is the idea of time-boxing. Time-boxes are important because they allow us to control the pace of development even as we are constantly responding to change. Iterations and releases are often time-boxed to 30 days. The daily stand-up meeting is time-boxed to 15 minutes. Research and discovery tasks can be time-boxed to a few hours so that they remain focused.
When you stick to regular intervals, it assures your stakeholders that even without deadlines they will get something they can use in a reasonable time frame. Every 30 days, you will get some piece of functionality. It also increases developer productivity by setting a pace for development rather than racing to meet an arbitrary future date. When you produce incrementally, you can avoid the impending death march of waterfall projects.
The Discipline of Completeness
Hand-in-hand with intervals, completeness is an important factor in delivering functionality to your stakeholders. Each interval, the team commits to complete a predetermined set of features. At the end of the interval, the team does not deliver partial functionality or a bunch of mock-ups2; they deliver working software.
The duty to completeness is not just for the developers, however. The product owner is also responsible, and thus he must be willing to de-feature when appropriate. If it looks like a commitment will be missed, this should be communicated to the stakeholders and the feature moved to a future iteration. The product owner should never3 force the team to deliver more than it is capable of in a single iteration, and the team should never arrive at the review meeting and have to tell the stakeholders that they could not get something done.
It is also important on an individual level that each team member not claim that a feature is done until it is truly done—that is, it has been coded, tested, signed off by the product owner, and delivered to the customers.
The Discipline of Quality
One thing that agile development will uncover very quickly in a software project is any sort of fragility. In order to respond to constant change (see “The Discipline of Adaptability,” above), the code must be resilient enough to withstand it… or it must be brought up to that level if it is not.
A common misconception of quality assurance is that QA’s job is to find bugs. On the contrary, it is actually there to prevent them. Many products have a very long QA cycle because so much time is spent fixing defects that have been identified. Imagine how much simpler it would be if there were no defects to find!
This requires a great deal of discipline from your engineers, since they must be mindful of QA from the beginning. As the saying goes, “Do it right the first time.” Developing in increments and utilizing practices such as Test-Driven Development will help achieve this goal.
The Discipline of Communication and Transparency
Communication and transparency are absolutely critical to an agile project. Since there are fewer document artifacts moving around than in a waterfall environment, it is very easy for an agile project to operate “under the radar” if the team is not careful. This is why processes like Scrum have the important core meetings: the daily stand-up, the review, the retrospective, and planning. The task board is also a great visibility tool.
It is important that the Scrum Master and the product owner work together to ensure that communication flows freely between the team and the stakeholders. Without this channel, the stakeholders will feel left in the dark about the project’s status, and the team will feel like they have no guidance or feedback.
The Discipline of Innovation
The final discipline on my list (but certainly not the least) is innovation. In order for an agile project to succeed, the team and the process must constantly improve. The retrospective allows us to reflect on our past performance and adjust for the future. The team’s velocity is a tool to help us measure and increase throughput.
The most important thing to keep in mind is that no process is sacred. You may have read all the books on Scrum, but if “pure” Scrum is not working for your team, change it. Maybe you need shorter/longer iterations? That’s fine. Maybe you need a traditional project manager in addition to the Scrum Master and product owner? That’s fine too. Do what feels right for your organization. Experiment. Learn. Grow. Innovate.
1With the concession that when I’m talking about agile in this article, I’m using Scrum as my frame of reference.
2Unless the agreed-to deliverable was a mock-up, of course.
3As usual, never is a very strong word. Agile does not preclude crunches when needed, but the product owner should make every effort to avoid them.
posted on January 22nd, 2009 at 2:22 pm
← Back to articles