A common question we get regarding Disciplined Agile (DA) is “What makes DA more disciplined than other approaches to agile?” It’s a fair question, particularly from someone who is new to DA. This blog posting explores this question, explicitly summarizing the critical strategies that exhibit the greater levels of discipline in DA as compared with what we see in many agile teams today.
It is clear that many common agile practices require discipline. For example, agile teams it takes discipline to hold concise, streamlined coordination/Scrum meetings; to consistently deliver business value every iteration; to test continuously throughout the lifecycle; to improve your process “in flight”; to work closely with stakeholders and many more things. Discipline is very important to the success of agile teams, see The Discipline of Agile for a detailed discussion, and DA takes it to the next level in the following ways:
- Reducing the feedback cycle. Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles. Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations. There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by DA. These techniques, listed in order of immediacy, include non-solo development (e.g. pair programming), active stakeholder participation, continuous integration (CI), continuous deployment (CD), short iterations/sprints, and short release cycles.
- Continual learning. Continual learning is an important aspect of agile software development in general, not just DA. However, DA explicitly addresses the need for three levels of learning: individual, team, and organizational/enterprise. It also addresses the need for three categories of learning: domain, technical, and process. Continual learning strategies include active stakeholder participation, coaching, mentoring, individual learning, non-solo development, experimenting via minimum viable products (MVPs), spikes, retrospectives/reflections, sharing lessons learned between teams, and stakeholder demonstrations.
- Incremental delivery of consumable solutions. Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline. DA goes one step further and advises you to explicitly produce a potentially consumable solution every iteration, something that requires even greater discipline. Every construction iteration your team requires the discipline to create working software that is “done”, to write deliverable documentation such as operations manuals and user documentation, to address consumability (usability), to consider organizational change issues pertaining to your solution, and operations and support issues (an aspect of DevOps).
- Being process goal-driven. The DA tool kit promotes a process goal-driven approach. For each goal we describe the issues pertaining to that the goal. For example, with initial planning you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.
- Enterprise awareness. Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly. It takes discipline to be enterprise aware and to work with enterprise folks who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a “DevOps” manner throughout the lifecycle, particularly when they may not be motivated to do so. Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DA adoption, or they may be your greatest allies, these authorities serve important functions in any large enterprise. Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.
- Adopting a full delivery lifecycle. Despite some agilists reluctance to admit that projects go through phases, DA explicitly recognizes that they do. Building serious solutions requires a lot more than just doing the cool construction stuff. It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle. The two project-based life cycles explicitly depict pre-delivery activities, a three-phase delivery lifecycle, and post-delivery activities (operations and support).
- Streamlining inception activities. The project life cycles include an Inception phase, known as Sprint 0 in Scrum, where you perform fundamental project initiation work. Unfortunately in our experience we have seen many organizations treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications. Some people have referred to the practice of doing too much transitory documentation up front on an agile project as Water-Scrum-Fall. We cannot stress enough that this is NOT the intent of the Inception phase. While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to the Inception phase and strive to reach the stakeholder consensus milestone as quickly as possible. If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach. It takes discipline to be aware of this trap and to streamline your approach as much as possible.
- Streamlining transition activities. In most mid-to-large sized organizations the deployment of solutions is carefully controlled, particularly when the solutions share architectures and have project interdependencies. For these reasons release cycles to your stakeholders are less frequent that you would like because of existing complexities within the environment. However, the ability to frequently deploy value to your stakeholders is a competitive advantage; therefore you should reduce the release cycle as much as possible. This requires a great degree of discipline in areas such as pre-production integration and deployment testing; regular coordination between project teams and with operations and support staff; Change management around both technology and requirements; and adoption of continuous deployment practices to such a degree that very frequent deployments are the norm and the Transition “phase” becomes an automated transition activity.
- Adopting agile governance. It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams. Every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives. It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.
- Moving to lean. For all of the process goals we describe a range of options to address the issues pertaining to that goal. These options ranged from traditional/heavier approaches that we generally advised against except in very specific situations to agile strategies to very lean strategies. Generally, the leaner the strategy the greater the discipline it requires.
Adopting a disciplined approach to agile delivery requires the courage to rethink some of the agile rhetoric and make compromises where necessary for the benefit of the “whole enterprise” and not just the whole team. In our experience most agile projects make certain compromises that are not classically agile in order to get the job done. Rather than hiding this and fearing reprisals from those who would accuse you of regressing to a traditional approach, it is better to have the courage to take a pragmatic approach to using agile in your situation.
Effective application of DA certainly requires discipline and skill, but in our experience the key determinant of success is the ability and willingness of the team to work well together and with stakeholders, both within and external to the team.