Project Management

Disciplined Agile

by , , , , , ,
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Hybrid | Improvement | inception | Inception phase | Kanban | Large Teams | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | Workflow | show all posts

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Failure Bow: Choosing Between Life Cycles Flowchart Update

Evolving Disciplined Agile: Guidelines of the DA Mindset

Evolving Disciplined Agile: Promises of the DA Mindset

Evolving Disciplined Agile: Principles of the DA Mindset

Evolving Disciplined Agile: The DA Mindset

Exploring Initial Scope on Disciplined Agile Teams

When a disciplined agile project or product team starts one of the process goals which they will likely need to address is Explore Initial Scope.  This is sometimes referred to as initially populating the backlog in the Scrum community, but as you’ll soon see there is far more to it than just doing that.  This is an important goal for several reasons.  First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding.  Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of the scope of your effort is important input into answering those sorts of questions.

The process goal diagram for Explore Initial Scope is shown below.  The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues.  The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom.  The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now.  Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

Explore Initial Scope Process Goal

Let’s consider each process issue:

  • Choose the level of detail.  How much effort should you put into capturing the requirements, if any at all.  A small co-located team may find that capturing user stories on index cards to be sufficient, whereas a team that is geographically distributed across several locations will find that it needs to capture point-form notes about each story using an electronic tool, and a team in a life-critical regulatory environment may need to capture even more detail to the point of doing big requirements up front (BRUF).
  • Explore usage. Although much ado has been made of user stories, and they can be applied quite effectively in a range of situations, the fact is that they’re only one of several options for your team to explore usage of the solution (scenarios, personas, and use cases being other options).
  • Explore the domain. Some teams will choose to do some domain modeling via a data model or class diagram, as well as address other views as appropriate.
  • Explore the process. Many teams will discover that they need to explore the overall workflow, or business process, supported by their solution so as to help them better understand their usage requirements.
  • Explore user interface (UI) needs. Many agile teams will also choose to create user interface prototypes, either low-fidelity UI prototypes using paper or even high-fidelity UI prototypes using a prototyping tool or code, particularly when they face a complex domain.
  • Explore general requirements.  There are several types of functional requirements modeling techniques that can be valuable that don’t fit well into the previous categories.
  • Explore non-functional requirements.  How will non-functional requirements pertaining to availablity, security, performance, and many other issues be addressed?  Teams in straightforward situations may find that capturing them as technical stories may be sufficient.  Teams facing technical complexity, and sometimes even domain complexity, soon discover that they need a more sophisticated strategy.
  • Apply modeling strategy(ies).  How will your team go about working with stakeholders to elicit/discover their perceived needs?  Will they hold informal modeling sessions in an agile modeling space?  Will they hold formal modeling sessions, perhaps following a Joint Application Design (JAD) strategy?  Will they interview people one-on-one?  Combinations thereof?
  • Choose a work item management strategy.  Early in the project you will want to determine how you intend to address changing stakeholder needs throughout the project as this will affect how you address the other process issues in this list.  For example, do you intend to adopt Scrum’s value-driven product backlog strategy, DAD’s risk-value driven work item list, a lean work item pool strategy (as followed by DAD’s lean lifecycle), or even a formal approach?  A team in a strict regulatory environment may be required to have a more formal approach to change management than a team without this restriction.

I wanted to share two important observations about this goal.  First, this goal, along with Identify Initial Technical Strategy, Coordinate Activities, and Move Closer to a Deployable Release seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  As you saw in the discussion of the process issues, the process tailoring decisions that you make regarding this goal will vary greatly based on the various scaling factors.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

I’m a firm believer that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DA process decision framework provides this guidance.

Posted by Scott Ambler on: July 17, 2013 07:34 AM | Permalink | Comments (0)

Scaling Agile: The Software Development Context Framework

Categories: Context, Scaling

M31_hallas

The Software Development Context Framework (SDCF) defines how to select and tailor a situation-dependent strategy for software development.  The SDCF is used to provide context for organizing your people, process, and tools for a software-based solution delivery team.   Figure 1 below depicts how several selection factors drive the choice and tailoring of your team organization (people), delivery process,  and tooling configuration.  Of course initial selection is just the first step, you will also need to tailor these choices to reflect the situation that you face – hence the scaling factors.

Figure 1. Strategy selection and tailoring.

SDCF Overview

Selecting A Base Strategy for People, Process, and Tools

When you begin a project you need to identify who will be on the team, how they will work together, and what tools they’re going to use.  These decisions will be driven by factors such as the skill and culture of the people who will potentially be on the team, your organizational culture and policies, the nature of the problem being addressed, and business constraints such as time to market and budget.  Different situations will warrant different solutions to these three factors.

When it comes to team organization you have several issues to consider.  Will the team be composed mostly of specialists such as business analysts, developers, testers, designers and so on or will team members be more along the lines of T-skilled generalizing specialists?   How large will the team need to be?  Where will you find these people?   Will they be located in the same place or spread out?  Will they work for a single organization or several?  The choices you make will be driven by the situation that you face.

Similarly you have several process-related issues to consider?  What paradigm is most appropriate?  For example will you take an agile approach?  A lean approach?  A traditional approach?  An iterative approach?  A hybrid of two or more?  Will your team be able to follow a light, goal-driven process or a prescriptive one?  Will your process be constrained by compliance to frameworks such as CMMI or ISO standards?

When it comes to tooling there is a myriad of options and it seems as if everyone has an opinion as to which tools are best.  However, my experience is that there are several key issues to consider when choosing tools.  Will you adopt open source tools, commercial tools, or a combination thereof?  Will your tools be integrated or stand alone?  Do you prefer to obtain tools from a single source whenever possible, with the potential for better integration and support, or will you strive for best of breed tools regardless of vendor?  Will you host your own tool environment or will it be hosted externally via a SAAS-style approach?  If hosted externally, where will your intellectual property (IP), such as source code, be hosted?

Figure 2 summarizes five selection factors that I recommend you consider when making these people, process, and tool decisions:

  1. Team skills.  The people on a team must have the skills, or must gain the skills, that befit the role they play on that team.  For example, developers on an agile team may need to have test-driven-development (TDD) skills, people-oriented collaboration/communication skills, continuous integration (CI) skills, model storming skills, team-based planning skills, and so on.  Developers on traditional teams may be more focused on programming skills for a specific technology platform.
  2. Team culture.  People who are collaborative and team-focused in nature are better suited for agile/lean environments whereas people who like to work alone are better suited for traditional approaches. Similarly people who are open and flexible in their approach are better suited for agile or lean strategies.
  3. Organizational culture.  Your organization’s culture may vary from that of the team you are putting together, something that is particularly true when you are first learning about new ways of working.  An organizational culture that is very flexible and collaborative will mean that it is easier to take an agile or lean approach, wherease a more rigid, command-and-control culture will make it difficult to do so.
  4. Nature of the problem.  Although some people want to believe that some types of problem can only be solved in one manner that doesn’t seem to be the case in practice.  For example, it’s possible to take an agile or a traditional approach, to data warehousing projects, to web site projects, to mainframe-based projects, and even to embedded software development.  My experience is that the real issue is how decomposable the potential solution is.  For example, it’s possible to decompose a data warehouse into many small releases if you choose.  Same thing can be said of a web site as well as the other types of projects listed earlier.  But, it isn’t very easy to decompose an airplane into several working parts.  Either airplane is complete or it isn’t.  Yes, it’s still possible to apply agile techniques to such a project but the team will never be truly agile, just as agile as it can be given the constraints of the problem.
  5. Business constraints.  The way that the business constrains the endeavor, such as insisting on a certain (always agressive) delivery date, an approach to managing the budget (often a fixed price/bid), and how available business people will be throughout the project certainly has an affect on the process you adopt and the type of people that you include on the team.  It may even influence what tools you use.

Figure 2. Selection factors.

SDCF Selection Factors

In a future blog posting I will take you through how to apply these selection factors in greater detail.

Scaling Your Strategy for People, Process, and Tools

Figure 3 summarizes the six scaling factors, indicating the range of each factor.  On the left-hand side is the simple extreme and on the right-hand side the challenging extreme.  In my various IT surveys over the years I have found evidence that organizations are applying agile at all levels of scale, most recently in the 2012 Agility at Scale survey.

Figure 3. Scaling factors.

SDCF Scaling Factors

Let’s examine each scaling factor one at a time:

  1. Team size.  Teams can range in size from two people to twenty to two hundred or more.  Larger teams are typically formed to address more complex problems, and as a result large teams take on the challenges of greater domain complexity and/or greater technical complexity as described below.  Team size tends to directly affect how you organize the team and how you coordinate within the team.  For example, a team of 200 will be organized into subteams and a leadership team will be required for coordination (we described this in detail in Chapter 5 of the DAD book).  A team of 50 will also be organized into subteams, although coordination will likely be simpler and possibly handled by a daily coordination meeting of representatives from each subteam (a techniques referred to as  a Scrum of Scrums).  It is fairly straightforward to coordinate the activities of a team of 10 people.
  2. Geographic distribution.  Agile teams may be co-located, with the team members and key stakeholders in the same room, they may be on the same floor in a single building, on multiple floors, some may work in different buildings, some may work from home, and some may even work in different countries.  A popular misconception is that agile teams need to be co-located, a misconception that I have shown via several surveys over the years to be false.  Granted, it’s a very good idea to get people working as closely as possible, but it doesn’t happen as often as we’d like.  Similar to large teams, coordination of team members throughout the project become more difficult and as a result more sophisticated coordination is required.  A greater investment in initial modeling and planning, but not much more, is required during Inception to mitigate the communication risks associated with distribution.  To increase chance of project success you will need to fly people around at key points in the project, something many organizations are loathe to do because it’s easy to measure travel costs but difficult to quantify the benefit of face-to-face collaboration.  Please read Geographically Distributed Agile Teams for a more detailed discussion.
  3. Organizational distribution.  This refers to the concept of involving people from several organizations on the project.  The easiest situation to be in is to have all of your team members from the same group/division within a single organization.  It’s a little harder when people from several groups are involved.  Hiring contractors adds to the complexity.  Outsourcing a portion of the work to an external service provider is harder yet.  Outsourcing to several vendors harder yet.  Outsourcing to one or more service providers with a very different culture than your own harder yet.  Organizationally distributed projects tend to take on the challenges associated with large teams and geographically distributed teams.  When outsourcing is involved they take on the risks associated with procurement and then the governance of the outsourced effort.
  4. Compliance.  There are two forms of compliance.  Generally the simpler form of compliance is self-imposed, perhaps your organization chooses to be CMMI or ISO compliant.  The second, and potentially harder, form of compliance is regulatory compliances.  A team may need to conform to financial regulations, privacy regulations, or even life-critical regulations.  Although every regulation has different requirements, from a process point of view they typically require extra documentation (but keep it light), reviews (keep them streamlined), and sometimes a documented process (we suggest DAD).
  5. Domain complexity.  The complexity of the domain, or the problem space, being tackled by a team can vary widely.  An informational website site, such as this one, is fairly straightforward.  An e-commerce site is more difficult.  An air traffic control system even more difficult.  The greater the domain complexity that you face the more you want to invest in up-front modeling and planning.  Not much more, mind you, but still more.  Similarly as domain complexity rises it motivates greater sophistication in your agile testing strategy.  As domain complexity increases it puts a greater burden on your Product Owner, requiring more sophsticated agile modeling skills and potentially the support of agile business analysts.
  6. Technical complexity.  Disicplined agile teams will face varying levels of technical complexity.  On the simple end of the spectrum you’ll have the development of a brand-new, stand-alone application built with new technologies.  Things get more difficult if you need to take advantage of existing services or data sources.  Things get more difficult if you need to support several technology platforms.  Things get more difficult if you need to implement using several languages.  Things are more difficult yet if you need to refactor existing infrastructure (including legacy data sources).  As with domain complexity, the greater the technical complexity the greater the need for a bit more up-front modeling and more sophisticated testing throughout the lifecycle.  Greater techncial complexity puts a burden on your Architecture Owner, requiring great agile architecture and agile design skills of them.

In future postings I will explore the selection process and the implications of each scaling factor in greater detail.

Some Background

Where do these ideas come from?  The primary source is something called the Agile Scaling Model (ASM) which I led the development of while working for IBM.  In parallel to my work on the ASM Philippe Kruchten was working on something he calls “situational agility”, the heart of which was eight (8) factors often referred to as the “Octopus model”.  In the Autumn of 2012 I began thinking about how to combine and evolve these two frameworks into one, something I originally called the Process Context Framework (PCF).  I moved away from that name because the toolkit was clearly applicable to more than just software process, hence adopted the name Software Development Context Framework (SDCF) which is inclusive of people, process, and tools.

Posted by Scott Ambler on: March 15, 2013 08:14 AM | Permalink | Comments (0)

Scaling Agile: Start With a Disciplined Foundation

Categories: Context, Scaling

allsky_planck

One of the claims that we make in the Disciplined Agile Delivery (DAD) book is that DAD provides a solid foundation from which to scale agile.  In this blog posting I thought I would expand upon that idea.

Figure 1 overviews the basic strategy that I led the development of when I was with IBM Rational.  The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum.  We felt that the first step was to identify how to successfully develop a solution from end-to-end.  Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) putting it all together.  This is where DAD comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.

Figure 1: DAD provides a foundation for agility at scale.

Scaling Agile

First, let’s examine how DAD provides a better foundation for scaling agile:

  1. Risk and value driven lifecycle.  Scrum has what is called a value driven lifecycle.  Work is prioritized by value to the business and is performed in priority order.  This is a pretty good approach, but it’s possible to do better.  Disciplined agile teams recognize that it’s a pretty good idea to tackle the riskier work early in an endeavor in order to help eliminate some or all of the risk.  Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of  succeeding early.  A risk-value approach to work prioritization, and better yet explicit risk-based milestones (such as reaching stakeholder agreement early and proving the architecture with working code early), can increase your chance of project success.
  2. Self organization with effective governance.  There has been much ado made over the strategy of self organizing teams with the agile community and rightfully so as it is an effective strategy.  But, agile project teams don’t work in a vacuum but instead work within the scope and constraints of a larger, organizational ecosystem.   Instead of optimizing the project part as many agile methods imply that you should do in DAD we recommend that you adopt an effective governance strategy that guides and enables agile teams.
  3. Delivery of consumable solutions over construction of working software.  There are two issues here, a delivery focus over a construction focus and a solution focus over a software focus.  First, disciplined agile teams recognize that there is some up-front project initiation/inception work that occurs early in a project.   DAD also recognizes that there is often some deployment/transition effort that occurs towards the end of a project.  The end result is that DAD promotes the idea that you need to adopt a full delivery lifecycle, not just a construction-focused lifecycle, if you’re to successfully avoid common mistakes such as a Water-Scrum-Fall approach.  Futhermore, because DAD isn’t prescriptive it suggests several versions (agile, lean, continuous delivery) of the lifecycle.  Second, agile teams do far more than produce software.  We create supporting documentation.  The software runs on hardware that may need to be upgraded and/or redeployed.  We potentially change the business process around the usage of the system we’re producing.  We may even affect changes to the organization structure of the people using the system.  In short, it is blatantly obvious that we’re not just producing “potentially shippable software” but instead are producing “potentially shippable solutions”.  Moreover, producing something that is just “potentially shippable” isn’t what our stakeholders actually want.  What they really desire is something that’s consumable, something that they can easily understand and adopt to help them achieve their goals.  The rhetoric “potentially shippable software” plays well to some developers, but it isn’t a sufficient goal.
  4. Enterprise awareness over team awareness.  I alluded to this in point #2.  Disciplined agile teams recognize that they work in a larger organizational ecosystem.  This enterprise awareness  motivates them to leverage existing assets; enhance existing assets; work closely with enterprise professionals such as enterprise architects, reuse engineers, portfolio managers, and data adminstrators; and produce solutions that reflect the technology and business roadmaps of your organization.  Done right this increases a team’s ability to deliver.
  5. Context-sensitive and goal driven over prescriptive.  One process size does not fit all.  It’s comfortable to think that prescriptive strategies such as managing changing requirements in the form of a product backlog, holding a daily meeting where everyone answers three questions, having a single source of requirements and thereby a neck to wring, and other ideas will get the job done.  But we all know that this isn’t true.  There are many strategies for managing requirements change, there are different ways to coordinate within a team, there are different ways to explore stakeholder needs, and so on.  Each of these strategies has advantages and disadvantages and each has a range of situations where they are appropriate.  A strategy that works for a small co-located team will put a large geographically distributed team at risk.  A strategy that works well in a non-regulatory environment may result in people’s deaths in a regulatory one (or more likely fines because hopefully you’ll be caught before you ship).  So, if you want to build an effective team you need to be able to select the right strategy for the situation you find yourself in.  DAD describes a straightforward, easy to consume strategy that is goal-driven.  This strategy has a visual component, the goals diagrams which summarize the fundamental process decision points, and a textual component (goals tables) which capture the details.

Now let’s examine what it means to scale agile.  When many people hear “scaling” they often think about large teams that may be geographically distributed in some way.  This clearly happens, and people are clearly succeeding at applying agile in these sorts of situations (see some of the more recent evidence I’ve gathered that agile scales, as well as some of the older evidence), but there’s often more to scaling than this.  Organizations are also applying agile in compliance situations, either regulatory compliance that is imposed upon them or self selected compliance (such as CMMI and ISO).  They are also applying agile in a range of problem and solution complexities, and even when multiple organizations are involved (as in outsourcing).  As Figure 1 indicates, there are several scaling factors which you need to consider when tailoring your agile strategy.

So how does DAD provide a foundation from which to scale agile?  When one considers how scaling factors can potentially affect your strategy it becomes a lot clearer.  Consider some examples:

  • Geographic distribution.  When a team is geographically distributed they will likely need to to a bit more requirements envisioning up front (but not too much more), a bit more architecture envisioning up front (but not too much more), a bit more release planning up front (but not too much more), and so on.  In other words you clearly need to tailor your inception efforts.  The way the team coordinates will change (your 15 minute stand up meeting becomes one or more conference calls), the way that you coordinate requirements changes (you’re likely to have several product owners that need to negotiate dependencies), and the way that you coordinate architectural issues changes (your architecture owners will need to coordinate somehow).  In short, you need strategies that are a bit more sophisticated than having a discussion standing up around a whiteboard with some sticky notes on it.  By the way, I’ve found in several surveys over the years that the majority of agile teams are geographically distributed in some way.
  • Compliance.  A few years ago I worked with an agile team that was working on FDA-compliant software.  Because of the need to be FDA compliant, they were working on a key software component of a life-critical solution, their approach to documentation, reviews, and testing was a bit more sophisticated than what you would find in a non-compliancy situation.  They needed a defined process (an early version of DAD) that met the documentation and quality constraints of FDA regulations.  This meant more documentation than most agile teams would normally create, more formal reviews, the inclusion of an independent test team on top of their whole team testing efforts, and documented proof thereof.  The point is that they were still doing documentation, reviews, and testing (amongst other activities) but doing so in a different way than if they didn’t need to be compliant.
  • Technical complexity.   As technical complexity rises the sophistication of the techniques, and sometimes the tooling, needed to deal with that complexity increases.  For example, if you’re building a brand new, stand alone application your team is in a position to write clean code, create a clean UI, and create clean data storage that is fully tested from the outset.  If you’re working with a legacy system the code… may not be so clean.  It may not have a full regression test suite (making continuous integration challenging).  You may need to fix these assets, thereby requiring a more sophisticated approach to refactoring, testing, debugging, and so on than what you’re used to.  Once again, this scaling factor will affect your strategy.

The good news is that there is a growing collection of techniques for scaling agile projects.  This includes Dean Leffingwell’s Scaled Agile Framework (SAFe) as well as the continuing writings of Craig Larman and Bas Vodde.  In future blog postings we’ll discuss the scaling factors in greater detail as well as how DAD and SAFe fit together.

Posted by Scott Ambler on: February 22, 2013 03:05 PM | Permalink | Comments (0)

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)
ADVERTISEMENTS

"The illegal we do immediately. The unconstitutional takes a little longer."

- Henry Kissinger

ADVERTISEMENT

Sponsors