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.
Let’s consider each process issue:
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.
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.
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:
Figure 2. 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.
Let’s examine each scaling factor one at a time:
In future postings I will explore the selection process and the implications of each scaling factor in greater detail.
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.
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.
First, let’s examine how DAD provides a better foundation for scaling agile:
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:
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.
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.
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.
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:
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?