Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

Embracing Mindset Diversity in Disciplined Agile

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

Disciplined Agilists Take a Goal-Driven Approach

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.

Process Goal Diagram Notation

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.

Explore Initial Scope Process Goal

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.

Address Changing Stakeholder Needs process goal

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.

The Process Goals of Disciplined Agile Delivery (DAD)

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?

Posted by Scott Ambler on: January 21, 2013 03:51 PM | Permalink | Comments (0)

Adopting Agile Governance Requires 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.

Posted by Scott Ambler on: November 30, 2012 07:50 AM | Permalink | Comments (2)

It Requires Discipline to Evolve Transition From a Phase to an Activity

Because Disciplined Agile Delivery (DAD) addresses the full delivery lifecycle it explicitly addresses the effort required to transition your solution into production, or in the case of product teams into the marketplace.  This transition effort may be referred to as release, deployment, or even the “end game”.  For teams relatively new to agile this transition effort is a phase, or if you don’t like the term phase then an iteration which very likely has a different time frame than construction iterations.  However, as we indicate in the DAD book, as teams gain more experience with agile and lean techniques the “transition phase” can be evolved into a “transition activity” with a little bit of discipline.  That is the focus of this blog posting.

The DA toolkit is goal-driven, not prescriptive, and as a result it describes the transition effort in terms of goals:

  1. Ensure that the solution is ready to deploy.  To achieve this goal you will need to address several issues, such as planning the transition effort, verifying that the solution meets the stakeholder needs for the current release, and validating that the solution is of sufficient quality.  As with other DAD goals, there are several ways each of these issues can be addressed, each with advantages and disadvantages.  There is no single strategy that’s right for all situations.
  2. Ensure that stakeholders are ready to receive the solution.  Similarly, there are several issues you need to consider when addressing this goal, including how you communicate that the release is coming, how to train and educate stakeholders in the new solution, and how to prepare the operations and support environment for the new release (one of the many aspects of a disciplined DevOps strategy built right into DAD).
  3. Deploy the solution.  Issues to consider when achieving this goal is identifying what should be released, how you can back out the release if you run into trouble, and how to determine that the release was successful.  The last issue, determining success, isn’t as obvious as you would think.  Does success mean that the solution is up and running in production?  Or does success mean that you have satisfied, or better yet, delighted stakeholders?

It is straightforward to empirically observe that the complexity of your transition effort can vary depending on the context of your situation.  For example, a simple standalone application such as a website can be easily deployed regularly because it effectively involves copying some files to a server (farm).  Organizations in this sort of situation may choose to deploy their software many times a day.  However, as we showed in the DAD book, for non-trivial enterprise deployments the transition effort can be significant.    In fact, the November 2010 Agile State of the Art survey found that the average agile team spent six weeks in their transition efforts, with some respondents indicating spending one day or less and some indicating twelve weeks or more.  There are several reasons why this happens:

  1. Transition isn’t agile yet. Many organizations are adopting agile techniques for construction but not for other aspects of the delivery lifecycle.  This is often referred to as “Water-Scrum-Fall”.  As a result these organizations are inflicting traditional, labor intensive transition practices on their agile teams.
  2. We’re dealing with more than just software.  It’s often a bit more difficult than simply copying some files onto a production server.  Mainstream agile methods describe the goal of creating “shippable software” at the end of every iteration.   That’s a wonderful, overly simplistic philosophy that doesn’t hit the mark in practice. In DAD we prefer to use the phrase “consumable solution” indicating that shippable does not necessarily mean usable software.  Furthermore, in many situations more needs to be delivered than just software – there may also be hardware upgrades, the business processes surrounding the use of the system may evolve, and even the organization structure of the people using the system may evolve.  In short, disciplined agilists adopt a solutions over software mindset.
  3. Transition occurs infrequently.  Some agile project teams adopt a long release cycle, often six months or more, and as a result don’t have sufficient opportunities or motivation to get good at deployment.  Sometimes this is due to the nature of the solution they’re working on but more often than not it’s because of the cost of transition – the greater the effort to transition into production the greater the cost to do so, therefore you need to spend more time building the solution to add sufficient value to justify the cost of transition.
  4. Lack of vision.  Many IT organizations don’t believe it’s possible that releasing solutions into production can be evolve from a multi-week phase to a multi-hour, or even multi-minute, activity.  Or they realize it’s possible for others to do so but not them (I find it amazing how many people believe they’re in a special situation or blame others, often senior management, for not being able to adopt fundamental strategies that would improve their approach).

Because of the potential complexities of releasing a solution in most mid-to-large sized organizations the deployment of solutions is carefully controlled.  This is particularly true when the solutions share architectures and have project interdependencies, one of the reasons why DAD promotes the need for enterprise awareness within agile teams.  For many 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.  To do so requires a great degree of discipline in areas such as:

  1. Quality practices.  First and foremost, testing and any related fixing should be done as much as possible during construction iterations.  Transition is not a “stabilization phase” nor is it a “test phase”, it’s a deployment effort.  Granted, you should still run your regression test suite(s) one last time as part of your overall deployment effort, with the potential that if tests fail you will need to do some fixing, but this should be a minimal effort.  The implication is that quality practices – including testing, refactoring, reviews, code analysis, and so on – be performed continually throughout construction.
  2. Pre-production integration and deployment testing.   These are two of the most challenging types of testing, and sadly they’re often given short-shrift in the agile literature.   The goal of pre-production integration testing, sometimes called production testing, is to test the solution in the best approximation of the production environment as possible.  This can be particularly challenging in larger organizations where hundreds of systems are already running in production and dozens are being worked on at any given time.  To make this testing economical during construction many organizations find that they need to go beyond the “whole team testing” approach with a parallel independent testing team that focuses on complex forms of testing that development teams can struggle with.  Similarly deployment testing can also be a challenge because its goal is to determine whether you can successfully deploy into production.
  3. Regular coordination between project teams and with operations and support staff. Throughout construction you will want to ensure that the development, operations, and support teams are all aligned.   One aspect of DAD’s enterprise awareness is to include DevOps strategies, such as treating operations and support staff as key stakeholders that you need to work closely with throughout the lifecycle, in the process itself.  The better the coordination the smoother, and therefore quicker, transition will go.
  4. Adoption of continuous deployment practices.  The fundamental idea behind continuous deployment is that the more often you choose to deploy the better at it you will get.  This happens because you have more opportunities to hone your deployment skills and also because you’re motivated to find ways to simplify or automate deployment activities.

I’ve seen teams evolve transition phases of several weeks down to several hours through adoption of the disciplined strategies mentioned above.   A disciplined agile team may start with relatively long Inception, Construction, and Transition phases and over time shrink all three down.   Over time the Inception phase mostly disappears, particularly if you maintain team consistency between releases, and as I’ve argued in this posting the Transition phase shrinks to a very small activity.  When deployment becomes inexpensive it enables you to have shorter construction phases and thus more regular releases – teams go from annual releases to bi-annual, then to quarterly releases, then monthly, weekly, and yes, sometimes even daily.  Your team will need to choose a release cadence that makes sense for you.

These days it is fairly easy to observe multi-billion dollar companies, particularly e-commerce companies but even staid organizations such as financial institutions, deploy on a monthly, weekly, and even daily basis.  If other organizations choose to work this way then why can’t you?

Posted by Scott Ambler on: September 21, 2012 12:15 PM | Permalink | Comments (0)

It Requires Discipline to Keep Inception Short

The Disciplined Agile Delivery (DAD) process framework includes an explicit Inception phase – sometimes called a project initiation phase, startup phase, or iteration/sprint zero – which is conducted before actually starting to build a solution.  The goals of this phase include: clarifying the business problem that needs to be solved; identifying a viable technical solution; planning your approach; setting up your work environment and team; and gaining stakeholder concurrence that it makes sense to proceed with investing in the implementation of the chosen strategy.  These goals are listed in the following diagram.

Inception goals

Form Initial Team Develop Common Vision Align With Enterprise Direction Explore Initial Scope Identify Initial Technical Strategy Develop Initial Release Plan Secure Funding Form Work Environment Identify Risks

In the Disciplined Agile Delivery book we devoted a lot space to describing how to effectively initiate a DAD project.  Unfortunately in our experience we have seen many organizations that are still new to agile 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 temporary 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 this phase and strive to reach the stakeholder consensus milestone as quickly as possible.

According to the 2013 Agile Project Initiation survey the average agile team invests about 4 weeks performing project initiation activities, including initial requirements envisioning, initial architecture envisioning, forming the team, initial release planning, and so on.  Of course this is just an average, some respondents reported investing less than a week to do so and some reporting investing more than two months – the amount of time required varies depending on the complexity of the effort, your stakeholders’ understanding of their requirements, your team’s understanding of the solution architecture, whether this is a new solution or merely a new release of an existing solution, and many others.

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.  You can do this in several ways:

  1. Recognize that the goal is to get going in the right direction.  For any project or product of reasonable complexity you want to spend a bit of time up front ensuring that you understand the problem and have what you believe to be a viable strategy to addressing that problem.  This doesn’t imply that you need a comprehensive requirements specification, a detailed project plan, nor a comprehensive architecture model but it does mean you need to do a bit of initial thinking and organizing.  In a small handful of cases, typically at scale, you may find that your team does require detailed models and plans but this is a very uncommon exception (regardless of what traditional THEORY may claim).
  2. Educate people that details can safely come later.  If you have the ability to plan or model something in detail today, won’t you also have that same ability a few months from now when you actually need those details?  Of course you do.   In lean software development they recommend deferring decisions – including planning decisions,  detailed design decisions, and even requirements – until the most appropriate moment.  The observation is that by waiting you can make a better decision because you have better information at hand.  This strategy of course assumes that you’re able to overcome basic logistical problems such as having the appropriate people available at the time to help explore an issue, provide requisite information, and make the decision.   It’s far less risky, and far less expensive, in most cases to address basic logistical issues than it is to apply the process band-aid of writing detailed documentation at the beginning of a project.
  3. Promote a sense of urgency.  This is the most important thing that you can do.  Just as there is risk associated with not sufficiently thinking about your strategy for approaching a new project or product there are also risks associated with doing too much up front work.  My experience is that far too many IT professionals are complacent regarding the risks associated with the project initiation activities of the Inception phase.   The longer you put off building a consumable solution the greater the risk that you’re building the wrong thing.
  4. Keep your modeling efforts as light as possible.  You very likely need to do some initial requirements envisioning and architecture envisioning early in the project lifecycle to help you think through what you’re doing.  But in most cases this modeling should be high level and light, not detailed and heavy.  In every project I’ve ever been involved with the team has been asked to identify what they’re going to deliver (at least giving a rough sense of the scope) and how they’re going to do it (at least providing a rough idea of the technical strategy) to secure funding for construction.  In short, they need to do a bit of up front thinking.  You will often find that you need to reign-in some of your staff who are experienced with traditional approaches to modeling and specification.  These people have a lot of value to add to your project, modeling is an important skill needed on disciplined agile teams, but they may need help keeping their approach light-weight and incremental.   The details can come later.  See the process goals Identify Scope and Identify Technical Strategy for more thoughts on this subject.
  5. Keep your planning efforts as light as possible.  Similarly you need to invest some time in high-level release planning to answer basic questions such as how long do you believe (roughly) it will take to get a release of your solution deployed and how much (roughly) this will cost.  Planning details can come throughout the Construction phase when it’s more appropriate to invest in such decisions.

I think that it’s very clear that the secret to keeping Inception short is to have the discipline to know that you need to invest some time thinking your approach through but that you want to avoid getting bogged down in too many details.  You need the discipline to do some planning but not too much.  You need the discipline to do some modeling but not too much.  You need the discipline to get going in the right direction knowing that the details will come out in time.

Posted by Scott Ambler on: September 07, 2012 03:15 PM | Permalink | Comments (0)

Reducing the Feedback Cycle Requires Discipline

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 the DAD process framework.  These techniques, listed in order of immediacy, are:

  1. Non-solo development.  Non-solo development strategies such as pair programming and modeling with others provide feedback within seconds.  These techniques are great strategies for reducing the feedback cycle within your team but they often require initial discipline to adopt because it can be difficult to break your former solo working habits.
  2. Active stakeholder participation.  It can require significant discipline to work closely with your stakeholders, to seek and then respect their opinions, and to allow them to set important aspects of your project direction.  Working closely with stakeholders typically has a feedback cycle on the order of seconds when they are co-located with your to hours or days when you need to wait to interact with them.
  3. Continuous integration.  Building, regression testing, and potentially running your work through code analysis on a continuous basis is a fairly straightforward concept which provides feedback on the order of minutes.  Doing it in practice, and more importantly the habit acting on the feedback provided from the tests and code analysis requires discipline to adopt at first because you often want to work on the next thing instead of cleaning up the work on what you’re currently doing.
  4. Continuous deployment. By regularly deploying into more complex environments – to your project integration environment from your individual environment, from your project environment to your demo or independent testing environments – you put yourself in a position to receive more meaningful feedback.  Continuous deployment requires you to have the discipline to have multiple environments, to work with people external to your team (such as stakeholders and independent testers), and to seek and act on their feedback.
  5. Short iterations. The length of an iteration defines the feedback cycle between promising your stakeholders you would do a bundle of work, the end result of your iteration planning session, to demonstrating what you actually got done.  It requires significant discipline to work in short iterations.  The average agile team has construction iterations of two weeks, although some teams have shorter iterations and some advanced teams have evolved beyond iterations to take a lean approach.  Then again some agile teams, particularly those at scale, may have slightly longer iterations.  The shorter the iteration the greater the discipline required to make it work because you will need to adopt many, if not all, of the techniques listed in this section.  You will also require the discipline to identify, and then address, wasteful activities that add little or no value in your current process.
  6. Short release cycles.  The length of your release cycle defines the feedback cycle from promising stakeholders to deliver a new release of a solution to actual use by end users in production.  The feedback from real users is the key information to determine if you’ve delivered the right thing for them.  All other stakeholder feedback is merely an approximation up until that point.  As with short iterations, it requires increasing discipline to move from annual to bi-annual to quarterly to monthly to weekly or even daily releases into production.

This posting was modified from Chapter 21 of the forthcoming book Disciplined Agile Delivery to be published in June by IBM Press.

Posted by Scott Ambler on: March 30, 2012 02:20 PM | Permalink | Comments (0)

"We don't like their sound, and guitar music is on the way out."

- Decca Recording Company, rejecting the Beatles, 1961