Disciplined Agile

DAD incorporates a number of milestones into its lifecycles to gauge the progress and health of your DAD projects/releases.

Why does DAD have milestones?

Governance is largely absent from mainstream agile methods and many believe that agile does not need milestones.   Scrum orders its backlog with highest value work at the top of the stack.  At the end of each sprint (iteration) a decision is intended to be made whether or not the next sprint of work in the backlog provides sufficient value to fund another sprint.  If not, the project stops.  While in principle this strategy makes sense, as a replacement for governance it is flawed for several reasons:

• Not sufficient.  There is much more to effective governance than deciding when to cease the funding of a project.  How did it get started in the first place for instance?
• Not realistic.  In reality most organizations tend to fund releases comprised of many iterations rather than make explicit funding decisions at the end of each sprint.
• Effectively a milestone.  While Scrum claims to not have milestones, pausing to consider if sufficient functionality exists to deploy, and to determine a go-forward strategy is implicitly a milestone.  DAD makes them explicit with guidance for how to effectively apply them.

Why do we need agile governance?

Contrary to what many believe, the need for governance does not disappear for agile initiatives.  Sponsors and other stakeholders deserve and indeed demand periodic updates on the status of their investments.  They want answers to questions like:

• What will I get from my investment and will it be worthwhile?
• Is what is being delivered consistent with the initial funding request?
• What is the status of the outstanding risks and what is being done to mitigate them?
• Is the current release timeline consistent with the original projection?
• When will we have sufficient functionality to go live?
• Are all stakeholders prepared to receive the release?
• When will the project be finished?

Claims that agile is “different” and does not need to provide these answers is one of the reasons that agile is sometimes seen as being undisciplined.  In fact these claims are often used by some as an excuse why agile won’t work for them.  Fortunately, since DAD has built in mechanisms to facilitate answering these questions many organizations are extending their agile implementations to incorporate DAD’s guidance.  Indeed DAD is very appealing to those looking for a way to govern projects while still remaining agile.

Milestone Reviews Should Be Kept Informal

Consistent with the strategy recommended in the DAD goal Govern Delivery Team, milestone reviews should be done in a light manner.  They typically coincide with the end of iterations or phases when when using the Agile/Basic lifecycle.  If you are unsure why DAD has phases you might find the blog posting on the rationale interesting.

Milestone Dates Should Be Communicated

It is a good practice to provide a calendar to stakeholders with milestone dates for each DAD project so that they can plan to attend iteration reviews that coincide with milestone reviews that they are interested in.  While milestone dates may change, it is very useful to have target milestones across a portfolio of projects visible as a roadmap to all stakeholders.

The DAD Milestones

Stakeholder Vision.  The goal of the Inception phase is to spend a short yet sufficient amount of time, typically one to four weeks in order gain stakeholder agreement that the initiative makes sense and to therefore continue into the Construction phase.  By addressing each of the DAD Inception goals the delivery team will capture traditional project information related to initial scope, technology, schedule, budget, risks, and other information albeit in as lightweight a fashion as possible.  This information is consolidated and presented to stakeholders as a Vision statement as described by the Develop Common Vision goal.  The format of the vision and formality of review with vary according to your situation.  A typical practice is to review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.

Proven Architecture.  Early risk mitigation on a project is a part of any good project management discipline.  As the Prove Architecture Early process goal indicates, there are several strategies you may choose to adopt to do so.  The most effective of which is to build an end-to-end skeleton of working code that implements technically risky business requirements.  A key responsibility of DAD’s Architecture Owner role is to identify risks in the Inception phase.  It is expected that these risks will have been reduced or eliminated by implementing related functionality somewhere between one and three iterations into the Construction phase.  As a result of applying this approach early iteration reviews/demos often show the ability of the solution to support non-functional requirements in addition to, or instead of functional requirements.  For this reason it is important that architecture related stakeholders are given the opportunity to participate in these milestone reviews.

Continued Viability.  An optional milestone to include in your release schedule is related to project viability.  At certain times during the project stakeholders may request a checkpoint to ensure that the project is progressing consistent with the vision agreed to at the end of Inception.  Scheduling these milestones ensures that stakeholders are aware of key dates wherein they should get together with the team to assess the project status and agree to changes if necessary.  These changes could include anything such as funding levels, team makeup, scope, risk assessment, or even potentially cancelling the project.  There could be several of these milestones.  If the stakeholders agree to changes the Vision may be updated at this time.  Scrum implicitly has this milestone at the end of each sprint.  DAD makes this an explicit choice and makes it’s frequency optional.

Sufficient Functionality.  While it is worthwhile pursuing a goal of a consumable solution (what Scrum calls a potentially shippable increment) at the end of each iteration, it is more common to require a number of iterations of Construction before the team has implemented enough functionality to deploy.  While this is sometimes referred to as a minimally viable product (MVP) this not technically accurate as classically an MVP is meant to test the viability of a product rather than an indication of minimal deployable functionality.  The more accurate term to compare to this milestone would be “minimum feature set”.  Regardless, many use the acronym to mean the latter.

DAD’s sufficient functionality milestone is reached at the end of the Construction phase when a sufficient functionality is available plus the cost of transitioning the release to stakeholders is justified.  As an example, while an increment of a consumable solution may be available every two week iteration, it may take two weeks to actually deploy it in a high compliance environment so the cost of transitioning the functionality may not be justified until a greater amount of functionality is completed.

Production Ready.  For non-trivial situations a formal Transition phase is often required to do final preparations as part of delivery of the solution to stakeholders.  Once sufficient functionality has been developed and tested, transition related activities such as data conversions, final acceptance testing, production and support related documentation normally need to be completed. Ideally much of the work has been done continuously during the Construction phase as part of completing each increment of functionality. At some point a decision needs to be made that the solution is ready for production.  Of course, if you’re following the continuous delivery lifecycle then the “Transition phase” has evolved into a “Transition activity” – regardless, someone still needs to ensure that the solution is consumable before you deploy the solution.

Delighted Stakeholders.  Governance bodies and other stakeholders obviously like to know when the initiative is officially over so that they can begin another release or direct funds elsewhere.  The initiative doesn’t end the day after deploying a solution to stakeholders.  There are often project closeout activities such as training, deployment tuning, support handoffs, post implementation reviews, or even warranty periods before the project is considered completed.  Lean has a term “delighted customers” which suggests that “satisfied” customers is setting the bar too low.  While DAD agrees, there are more stakeholders than just customers such as production support that we need to delight before we consider the project complete, thus the milestone name “delighted stakeholders”.

Give Milestones a Try

Agile promotes transparency and accountability to our stakeholders.  Take this to the next level by sharing and celebrating achievement of key milestones on your projects.

When we describe DAD we remind people that it is not another agile method as we clearly have enough of those already.  Rather, DAD is a process decision framework that enables better decision making when customizing approaches for adopting agile within the context of your organization and projects.  Popular agile methods can be quite prescriptive.  Sometimes their agile rules – work collocated in one room, use teams less than nine people, or don’t do fixed price projects – are not practical.  Rather than discounting such projects as not agile, why not take a pragmatic approach to dealing with these realities while striving to still be as agile as possible?  DAD provides the guidance that enables you to easily tailor, and later evolve, your agile approach to effectively address the context of the situation that you find yourself in.  Hence the term process decision framework.

Another way to look at DAD is that is “pragmatic agile”.  In their book The Pragmatic Programmer, Andrew Hunt and David Thomas describe the need for programmers to be inquisitive, critical thinkers who are realistic and jack-of-all-trades (what we call generalizing specialists).  These qualities are consistent with those we describe for all team members on DAD projects.  This pragmatism reflects the need for agilists to abandon dogmatic, purist approaches to implementing agile and recognize the need to adapt for the complexities of most enterprise projects.  We often encounter management that is frustrated with agile teams that ignore organizational standards and resist compliance with any sort of governance that seeks measure things such as the health, risks, and return on investment for these agile projects.  In return, agile teams often say that management just doesn’t get it.  Surely there is a compromise here.  Management needs to understand that they need to adapt their approach to governing agile projects and agile teams need to be flexible in dealing with the realities of building software solutions for the enterprise.

Why is DAD pragmatic agile?  We feel that it is pragmatic to:

• Take a goal-driven approach which describes the agile strategies available to you, the advantages of disadvantages of each, and when to consider using each one.
• Invest a small amount of time prior to beginning construction to get going in the right direction.  We frame this endeavour in terms of the goals described below in the Inception phase section of Figure 1.
• Plan to spend some time after completing the construction of the solution to properly deploy it to your stakeholders.  This is described via a goal-driven strategie as shown in the Transition phase section of Figure 1
• Do some lookahead planning and modeling, often referred to as backlog grooming, on a just-in-time basis to be more effective when implementing work items during each iteration
• Leverage the existing organizational ecosystem to reuse existing services, patterns, templates, code, guidelines and other assets
• Govern the project teams in an agile manner
• Encourage project specific process improvement through self-organization within the constraints that make sense for the organization
• Adapt the types and formality of work products produced for the context of the projects

We have seen that DAD is certainly resonating with companies that have been struggling to create their own flavour of agile with Scrum, Extreme Programming (XP), and other approaches.  This roll-your-own approach can be difficult and expensive for companies to develop and then maintain.  DAD provides a complete and flexible framework that enterprises have been looking for, enabling them to get on with the actual job of delivering business value to their stakeholders.

How do we apply the toolkit to make better decisions and be pragmatic?  DAD is goal-driven.  Figure 1 shows the goals that are consistent with any type of software development effort regardless of type,  whether it be custom development or implementing a package for instance.

Figure 1.  The Process Goals of Disciplined Agile Delivery.

Figure 2 shows an example of a process goal diagram to show how to fulfill a particular goal.  To address the Explore The Initial Scope process goal we need to consider various issues or factors in order to be most effective for the context that we find ourselves in.  This goal is an important part of the Inception phase so that we can move towards obtaining stakeholder consensus that it makes sense to move into the Construction phase and begin building the solution.  For each issue there are a number of choices.  Some choices, such as work item stack, are bolded and italicized indicate good choices as a place to start for a typical DAD project.  Some issues show an arrow beside the options which is an indication that the choices at the top are typically the most effective and the better alternatives to strive for.  A typical project will make hundreds of process decisions and these diagrams can be used to ensure that the various options are considered.  An example of a decision might be what view type might I use to depict my scope?  DAD recommends starting with a combination of usage modeling, domain modeling, and non-functional requirements.  For usage modeling, user stories is the most popular agile approach, but you could also create use case diagrams or personas as needed.  The DAD book describes each of the alternatives, as well as their advantages and disadvantages of each.  In this way, DAD helps us make better decisions.

Figure 2.  Process Goal Diagram: Explore the Initial Scope.

Is pragmatic agile an excuse for taking shortcuts?  Although the DAD philosophy seeks to be as agile as possible, it is not an excuse for being lazy.  We use the term disciplined for a reason.  We often see organizations that are struggling with Scrum, and the root cause turns out to be that the teams are skipping some of the core Scrum practices.  For instance they may have decided that they have a good process and no longer need to do retrospectives.  In situations like these, the teams have abandoned one or more of the goals of a DAD project.  Referring back to Table 1, we can see that an ongoing goal is to Improve team process and environment.  Another example might be that the team does not do regular, end-of-iteration demonstrations.  Here they are not fulling the goal of Produce a potentially consumable solution.  Perhaps the teams says that they always have working software, but how do we know it is consumable?  Who as seen it?  Have the operations and support staff seen it?  Are end users actually eager to work with it?

As you can see, we can refer to the goals table and ask ourselves, “how are we fulfilling each of these goals?”.  Using this goals driven approach can help to ensure that you do not have gaps in your approach to implementing pragmatic agile.

In this posting we explore the goal-driven aspect of the Disciplined Agile (DA) toolkit.   This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods.  For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs.  DAD also indicates that there are several process factors/issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so.  DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for.  Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.

We start by describing how to visualize goals.  We then summarize the goals called out by DAD, a topic we’ve written about in the past so we only cover this topic briefly here.  We end with a summary of the advantages and disadvantages of a goal-driven approach over the more prescriptive approaches of older agile methods.

Visualizing Goals

In the original DAD book we described process goals in a non-visual manner using tables which explored the advantages and disadvantages of the techniques associated with a process factor.  Since we wrote that book both Mark and I have spent a lot of time helping people to understand what a goals-driven approach entails and we’ve found that many people respond well to visual representations of a process goal.  Yes, the process decision tables are very important but a visual overview helps to provide context for the detailed information.

In the second half of 2012 we began developing a way to represent goals in a visual manner using what we call a goals diagram.  A goals diagram, the notation for which is summarized in Figure 1, is in effect a form of decision tree.  In Figure 1 you see that a process goal is indicated using a rounded rectangle and the decision points pertaining to a goal with normal rectangles.  Process goals will have one or more decision points that you need to consider addressing, with most goals having four or five decision points although some have eight or nine.  Each decision point is then addressed by two or more techniques/practices.   Because there may be many techniques to choose from, we indicate “default” techniques in bolded italics.  These defaults are good starting points for teams new to agile – they are almost always strategies from Scrum, XP, or Agile Modelling with a few Rational Unified Process (RUP) ideas thrown in to round things out.  Some decision points you may choose not to address.  Sometimes options are “ordered”, which is indicated by a upwards pointing arrow to the left of the list of techniques.  What we mean by this is that the techniques appearing at the top of the list are more desirable from the point of view of agile and lean thinking and the less desirable techniques are at the bottom of the stack.  Your team of course should strive to adopt the most effective techniques they are capable of performing given the context of the situation that they face.  In Figure 1 the first decision point has an ordered set of options whereas the second one does not.  Typically when the options are ordered you will only choose one of them whereas you MIGHT choose several options in unordered situations.

Figure 1. The notation of goal diagrams.

Let’s work through some examples.  Figure 2 depicts the goal diagram for Explore Initial Scope, a goal that you should address at the beginning of a project during the Inception phase (remember, DAD promotes a full delivery lifecycle, not just a construction lifecycle).  Where some agile methods will simply advise you to populate your product backlog with some initial user stories the goal diagram of Figure 2 makes it clear that you might want to be a bit more sophisticated in your approach.  What level of detail should you capture, if any (a light specification approach of writing up some index cards and a few whiteboard sketches is just one option you should consider)?  What view types should you consider (user stories are one approach to usage modeling, but shouldn’t you consider other views to explore the data or the UI)?  Notice how we suggest that you likely want to default to capturing usage in some way, basic domain concepts (e.g. via a high-level conceptual diagram) in some way, and non-functional requirements in some way.  There are different strategies you may want to consider for going about modeling.  You should also start thinking about your approach to managing your work.  In DAD we make it clear that agile teams do more than just implement new requirements, hence our recommendation to default to a work item stack over Scrum’s simplistic Product Backlog strategy.  Finally Figure 2 makes it clear that when you’re exploring the initial scope of your effort that you should capture non-functional requirements – such as reliability, availability, and security requirements (among many) – in some manner.

Figure 2. Exploring the initial scope.

Figure 3 depicts one of the goals that you should address during the construction phase, in this case Address Changing Stakeholder Needs.  This is an iteresting example for two reasons.  First, it captures the key decisions surrounding the second of the 15 principles  of the Disciplined Agile Manifesto, that of welcoming changing requirements.  Second, it has a decision point that overlaps with that of another goal, in this case we indicate that your Work Item Management Strategy is important to consider for both this goal and Explore Initial Scope (see Figure 2).

Figure 3 makes the process factors surrounding how to address changing stakeholder needs very explicit.  How are you going to prioritize changes?  A business value approach is one option, the approach popularized by Scrum, but we’ve found that the risk-value approach promoted by Unified Process (UP) to be a more robust strategy that leads to greater chance of agile project success.  There’s advantages and disadvantages to each technique so you’ll want to choose the one best for you.  When are you going to accept the change?  During the current iteration as Extreme Programming (XP) suggests or a future iteration as Scrum suggests?  Do changes come directly from stakeholders or via a proxy such as a product owner or business analyst?  How will your team elicit changes (via modeling, demos, …)?

Figure 3. Addressing changing stakeholder needs.

The advantage of visualizing goals as we’ve shown in Figures 2 and 3 is that it makes it very clear what process-related decisions you need to make and what options you have available to you. The disadvantage of this sort of diagram is that they get fairly big at times, as you can see.  This effectively prevents us from taking the diagrams one step further to indicate the trade-offs associated with each technique and as a result you’ll still need the text tables we included in the DAD book for that.

The Goals of DAD

In the previous section we indicated that there are many goals called out by DAD,  Figure 4 summarizes these goals, which have evolved slightly from what we published in the book (we refactored a few to make them more consumable).  Notice how each of the three phases (Inception, Construction, and Transition) are described by specific goals.  Also notice how some goals, such as Grow Team Members and Address Risk, are applicable throughout the entire lifecycle.

Figure 4. Goals throughout the lifecycle.

Mark Lines’ post Being Goal-Driven Requires Discipline explores the history of the figure above if you’re interested in how the goals have evolved since the DAD book was published.

The Advantage of Goals Over Prescription

First and foremost, DAD is a process decision framework.   One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face.  Our experience is that there are several fundamental advantages to taking a goal driven approach to agile solution delivery.  A goal-driven approach:

1. Supports process tailoring. I think that Figures 2 and 3 make it very clear how DAD enables people to make intelligent process decisions.  I think that this is a huge improvement over previous process frameworks, particularly Rational Unified Process (RUP) that provided a lot of great process advice (regardless of what some agilists may claim) but struggled to provide consumable process tailoring advice.
2. Enables effective scaling.  DAD provides a foundation from which to scale agile approaches.  An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face.  For example, consider your approach to exploring the initial scope of your effort (the goal captured in Figure 2).  A large agile team or a geographically distributed team will make different tailoring decisions than a small co-located team.  A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments.  These are just three of several scaling factors (more on this in a future blog posting, although you may postings in my agility at scale blog to be of interest).
3. Makes your process options very clear.  Figure 4, in combination with the more detailed goals diagrams (such as in Figures 2 and 3) make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.
4. Takes the guesswork out of extending agile methods.  Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs.  Yes, we suppose this claim is true but how do you do so?  Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the toolkit cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues?  In short, shouldn’t it be a hybrid?   Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?
5. Makes it clear what risks you’re taking on.  By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on.  Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so.  DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it  is likely time to rethink your approach.  Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach.  Since the first DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects.  In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.
6. It hints at an agile maturity model.  We have written about how DAD and CMMI potentially fit together.  In that article I suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication.  Having said that I have no desire to wade into the agile maturity model morass, but I think it’s an important observation nonetheless.

So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations.  First, it makes the complexities of solution delivery explicit.  Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice.  Second, some people just want to be told what to do and actually prefer a prescriptive approach.  DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people.  Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.

We hope that this blog posting has given you some food for thought that you can leverage on your next agile project.  Got Discipline?

Governance establishes chains of responsibil­ity, authority and communication in support of the overall enterprise’s goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles that people play with and within the department.

Governance and management are two different things. Governance looks at a team from the outside, treating it as a system that needs to have the appropriate structure and processes in place to provide a stream of value. Management, on the other hand, occurs inside the team and ensures that the structure and processes are implemented effectively.  The Disciplined Agile Delivery (DAD) process framework characterizes governance as an element of enterprise awareness from the team’s point of view because governance looks at the team from the outside.

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.  As we described in the book 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.

Our experience is that the most effective way to govern agile teams is to focus on collaborative strategies that strive to enable and motivate team members implicitly. For example, the traditional approach to motivating a team to provide good ROI would be to force them to develop and commit to an “accurate” project budget, and then periodically review their spending to ensure they’re on track. An agile approach would be to ask the team to provide a ranged estimate of what they believe the cost will be so as to set expectations about future funding requirements.  Then the team works in priority order as defined by their stakeholders, visibly providing real business value through the incremental delivery of a potentially consumable solution.  Costs are tracked via the team’s burn rate (the fully burdened cost of the people on the team plus any capital outlays for equipment or facilities) and value is tracked by the stakeholders’ continuing satisfaction (hopefully) with what the team is delivering for that cost.  In short, a traditional approach often measures financial progress against a budget whereas an agile approach seeks to maximize stakeholder value for their investment by always working on the most valuable functionality at the time.

The DA toolkit includes several important agile governance strategies:

• Adopting a risk-value driven lifecycle
• Explicit, light-weight milestone reviews
• Agile enterprise teams that work closely with agile teams
• Regular coordination meetings (daily standups in Scrum)
• Iteration/sprint demos
• All-hands demos
• Follow enterprise guidelines (coding standards, UI standards, data conventions, …)
• Retrospectives, and better yet measured improvement
• Increased stakeholder visibility
• Development intelligences (BI for IT)
• Aligning agile team governance with other governance (operations, security, data, …) strategies
• Agile measurement/metrics programs
• Active risk mitigation
• Named phases
• Robust role definitions

Many of the strategies described above are “standard” agile governance strategies, and a few are unique to DAD.  It requires discipline to adopt and then execute on effective governance strategies, particularly in organizations where you already have a strong traditional governance program in place.

Last week I was in Moscow to do a workshop on DAD.  Askhat Urazbaev, known for starting the first Agile User Group in Russia attended.  He asked some good questions, including “Why is it called the Disciplined Agile (DA) toolkit?  Are you suggesting that existing agile techniques are not disciplined?”  I have heard this question a lot.  As we describe in our book, clearly existing agile methods such as Scrum and XP require discipline to be effective, in fact more discipline than traditional approaches.  However, this discipline is focused on practices used within the team to improve quality and meet the commitments made to the customer.  For example, it certainly requires discipline to do test-driven development, continuous integration, to optimize team performance, and to recognize and deal with technical debt via refactoring.

In DAD, we support all these practices, but in addition we suggest that discipline needs to extend to other areas such as:

• giving adequate attention to forming an overall project vision before beginning Construction iterations
• framing the project within a lifecycle
• agreeing on appropriate lightweight milestones
• building enterprise awareness, not just team awareness
• adopting agile metrics and governance at the enterprise level

This week Scott and I are speaking at Agile East in Orlando and I just attended an excellent talk by Jim Highsmith regarding adaptive leadership on agile projects.  He referred to mainstream agile as “Agile 101” and addressing some of these larger issues as “Mature Agile”.  This is very similar to the concept that we are trying to get across with the term Disciplined.  Mainstream agile methods address the discipline required to deliver value via Construction iterations (or without iterations with lean).  DAD extends that discipline to the full lifecycle and the enterprise.

We have written a number of posts on this blog in the “Discipline” category that you may find interesting which discuss some of these topics in more detail.