Disciplined Agile

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

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

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.

Clearly mainstream agile practices such as Scrum and Extreme Programming (XP) require discipline.  For example, effective Agile teams have the discipline to:

• Hold short, focused, and to the point daily coordination meetings rather than infrequent and time consuming status meetings.  It requires discipline to keep these meetings focused on coordination activities and thereby short and to the point.
• Commit to delivering a set of work items each iteration rather than letting deadlines slip.  It requires discipline to consistently fulfill the promises that you make to your stakeholders.
• Remove impediments in a timely fashion rather than procrastinating in pursuing a solution.  It requires discipline to tackle tough issues that are easier to ignore in the short term.
• Take the time to write tests before code rather than writing code,  It takes discipline to consistently work in a test-first manner instead of leaving testing to some time in the (distant) future.
• Test to the best of their ability instead of throwing artifacts over the wall to testers or reviewers.  It takes discipline to actively take responsibility for the quality of your own work.
• Reflect on the team’s experiences and improve their processes proactively rather than relying on process dictated by project managers or external governance bodies.  It takes discipline to stop and take time to reflect on how well your team is working and then act to improve it.
• Have a continuously working, integrated, and tested solution rather than waiting to do so when you’re “done” at the end of the lifecycle.  It takes discipline to stop all work when the build is broken so that it is repaired and the state of working, high quality solution is restored.
• Work together in a common area rather than in comfortable but isolated workspaces. It takes discipline to work effectively in a team, to do so in a respectful and trusting manner.
• Collaborate constantly with the stakeholders or their representative(s) to ensure that their expectations are met.  It takes discipline to accept that it isn’t your place to define the requirements or set priorities, particularly when you believe that you know better.
• Create and evolve deliverable documentation continuously throughout the project.  It takes discipline to accept that there’s more to successfully solution delivery than producing potentially shippable software.
• Self organize and plan the team’s work amongst themselves rather than relying on a traditional project manager to define, estimate, and assign work. It takes discipline to take responsibility for your own work and to respect the collective decisions of your team.

In our next few blogs we’ll discuss how Disciplined Agile Delivery builds on these practices to take discipline to the next level within the Enterprise.

Why does DAD not have an explicit role for an Analyst?  Without question classically trained analysts bring much needed soft skills and a structured approach to requirements elicitation and negotiation which may not be present in the other roles such as a product owner or a developer.  However, having these skills alone is not enough in an agile and lean world.

Unfortunately, professional organizations tend to encourage us to seek specialization and certifications over being cross-functional team members, which will be far more effective and valuable in the future.  This is not to say that these organizations do not deliver value in developing and maintaining standards of professional conduct and capability.  Attaining certifications (that require some degree of commitment and experience beyond a 2-day workshop) demonstrate commitment to a professional specialty.  This is admirable but I would suggest that this base of knowledge is just the start of being an effective team member on an agile project.  We should look outside our area of specialty to learn all we can about other aspects of software development.

It is my belief that in the near future, analysts will need to be competent testers if they intend to prosper in their profession.  An increasingly important skill is the ability to write requirements as executable tests.  My advice to analysts is to learn as much as you can about agile testing and seek opportunities to write your requirements as tests wherever possible.

For Business Analysts that are not interested in moving more toward the testing end of the spectrum there is another way to go.  Analysts can be good Product Owners, representing the customer on the project and by managing the scope and priorities.  In this role they can use their elicitation and facilitation skills to gain a clear understanding of what the customer needs (vs. wants).

Another potential career path is for the BA to move more into the area of traditional management consulting.  Often it is the business process that needs to be fixed, and this is where traditional Business Analysis skills will always be needed.

In my opinion, one career path for analysts is going the way of the dinosaur though.  And unfortunately this career path is often the status quo.  Traditional projects expect Business Analysts to document business processes and requirements in batch up-front in a linear, waterfall fashion.  They then must obtain sign-offs before actually proceeding with implementing any of the requirements.  Subsequent changes to those requirements are discouraged, unless through a formal, time consuming and wasteful Change Request process.  This model clearly is flawed, and eventually most companies will change their approach.  High ceremony and bureaucratic organizations such as government will be the slowest to adapt, but private companies in a competitive environment will adapt their requirements capture approach to a more agile alternative or risk being left behind by their competitors that will be more “agile” in adapting both their business processes and the solutions that support them.

In writing the book on DAD, Scott and I focused on a describing a pragmatic approach to being agile.  An alternative approach could have been to describe “how to do agile” planning, modeling, requirements, etc. which could have come off as dogmatic and prescriptive.  Or we could have shown all the agile practices described elsewhere, and said “you choose”.  Other methods that have tried to provide guidance to every possible situation have in the past proven to be overwhelming and difficult to adapt.

Instead, based on what really happens in enterprises that adopt agile we chose to describe different strategies to achieve your solution goals and where different, sometimes non-agile practices might make sense.  Sometimes there are situations that require us to use strategies that are not particularly agile.  How do we adapt to be as agile as we can to achieve our goals while dealing with enterprise realities such as compliance and vendor management?

We do have opinions about which strategy is most effective in certain situations and we realize that your approach might need to be different depending on your circumstances.  While we do suggest a path to maximizing your agility capability, DAD provides a flexible framework to adopt agile practices accordingly.  In this way we feel that our book is different than the other agile books out there that may paint an idealistic picture that is not realistic for your organization or project.  As an example, here is an excerpt from the upcoming book where we describe various strategies for choosing a your release cadences:

—

Table 10-5. Comparing production release cadences.

We recommend aiming for a release cadence of no more than six months, with a goal of getting it down to three months or shorter.  We recognize that organizations new to agile may find the concept of releasing every six months difficult at first, particularly when length release processes during the Transition phase still exist.  Strive to keep your Inception phase to two weeks or less, which can be hard if key stakeholders are unavailable or your organization still has lengthy milestone review processes.  During Construction, we recommend aiming for iterations of two weeks for co-located teams and of no more than four weeks DAD teams working at scale. We also recommend that construction iteration lengths remain the same, although if you’re a team new to agile that you should consider longer iterations at first and then as you gain experience with agile techniques and learn to collaborate effectively that you shorten your iterations over time.  We prefer having an internal release at the end of each iteration, although once you’ve fully adopted the practice of continuous deployment (CD) we recommend making your builds available to others whenever they’re successful.  Finally, strive to keep the Transition phase to be less than or equal to the length of a single Construction iteration, ideally shorter.

—–

We hope that you find that this approach to covering DAD gives you practical, actionable guidance for adapting agile to your organization.