Being Goal-Driven Requires Discipline

The DAD process framework uses a goal-driven approach as we illustrate in Figure 1 below.  Throughout our book we  described each of the DAD phases in turn and suggested strategies for addressing the goals of that phase. For each goal we described the issues pertaining to that the goal.  For example, in Chapter 10 when we discussed initial project planning we indicated that 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.

Figure 1. Goals addressed throughout a DAD project (updated).

Since the book was published in June 2012 Mark and I have made a few minor refactorings to the DAD goals to increase their consumability.  Figure 2 presents the goals as they were originally described in the book, whereas Figure 1 shows our refactoring.  As you can see there has been a few minor rewordings but the actual content remains effectively the same.  We apologize for any confusion, but process improvement happens. 

Figue 2. Goals addressed throughout a DAD project (original as published in the DAD book).

DAD lays out a set of milestones across the lifecycle that are common across most projects regardless of what agile practices you use.  It takes discipline to use a goal-driven approach to reach those milestones.  This means that you do not use a cookbook approach to deliver your solutions but rather adapt your techniques to follow the path that is best suited to you.  Prescriptive guidance and rules are common in many agile methods and people can easily fall into a trap of doing exactly what is dictated by a particular method without challenging how appropriate it is for their own situation.

Efficiencies gained from permanent dedicated teams with continuous funding.

Hi Mark,

Are you guys able to quote any studies in your book on the increase in effectiveness that can be achieved by establishing permanent dedicated cross-functional teams as opposed to teams that get torn down and re-assembled for each project? I am looking for a solid industry study that is widely excepted. Our company currently has a mix of both types of teams and I am looking for some industry data to compare against.

regards,

Bob

Webcast: Achieving Large-Scale Distributed Agile Delivery

Julian is presenting to the world-wide Rational User Community on Thursday 26th April at 12EDT.

The presentation shares his experiences of using DAD practices to enable his clients to achieve agility in their software delivery, even when their projects are large, complex and distributed.

To find out more and to register visit the Rational User Community site.

Incremental Delivery of Consumable Solutions Requires Discipline

Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline.  The Disciplined Agile Delivery (DAD) process framework 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 which your team executes requires the discipline to address:

• Working software that is “done”.  Your software should be tested to the best of your ability.  Ideally this includes pre-production integration testing and acceptance testing of the functionality delivered to date.  The software should not only fulfill the functional requirements but appropriate non-functional requirements (NFRs) as well.  Some of this testing may require the help of an independent test team, particularly at scale.
• Continuous documentation.  Deliverable documentation, such as operations and support, system overview, and end user documentation are part of your overall solution. Evolving this documentation in sync with the software requires greater discipline than simply leaving this documentation to the end of the lifecycle.
• Consumability. Your solution should be more than potentially shippable, it should also be consumable.  This requires investing some effort in user experience (UX) design throughout the lifecycle, particularly early in the project.
• Organizational change.  The business processes around using your system, and potentially even the organizational structure of the stakeholders involved with it, may need to evolve.  The implication is that your team needs the discipline to recognize and explore these issues throughout the project so that your stakeholders are prepared to receive your solution.
• Operations and support issues.  Your solution should be consumable by all stakeholders, not just end users.  Your operations and support staff should be able to work with the solution efficiently.  To understand these needs your team needs the discipline to work closely with operations and support staff throughout the lifecycle, an important aspect of your overall DevOps strategy.