Home > Context, Scaling > Scaling Agile: The Software Development Context Framework

Scaling Agile: The Software Development Context Framework


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

About these ads
Categories: Context, Scaling
  1. mashalalqudah
    March 15, 2013 at 9:16 am

    Thanks a lot Prof. Scott
    Wonderful explanation and it really helps in understanding many unclear issues.

  2. Anonymous
    November 8, 2013 at 7:32 pm

    i don’t understand the need to keep inventing new buzzwords to capture what is essentially decades old established theory…the RUP process captured it all; unfortunately no one understood it. I guess you need to dumb this stuff down before people will get it.

  3. November 9, 2013 at 3:33 am

    Although the RUP process captured a lot of great ideas, some of which were adopted in the DAD framework, it also missed a lot of great ideas that were captured elsewhere. Part of this was due to how RUP was scoped, some was due to the underlying mental model, and some was due to lack of investment in evolving RUP to reflect new ideas being developed outside of IBM Rational.

  4. Anonymous
    November 9, 2013 at 5:00 am

    DAD differs from RUP in many ways, Thanks a lot for your regular feedback Prof Scott.

  5. Anonymous
    June 23, 2014 at 9:32 am

    Hi Scott, good post. I personally believe there are very few who believe in one size fits all methodology yet we continue to operate as if this is the case. We’ve even had methodology frameworks such as RUP which are explicitly tailorable, yet few ever followed through, e.g. the RUP development case which no one ever seem to write. Or Alistair Cockburn’s Crystal which was suppose to be a scalable methodology but it never went anywhere really. So in your opinion, what are the impediments to constructing the appropriate methodology for a project? My observation is a project’s methodology is often some mixture of the corporate SDLC (usually) and whatever situational expedient practices the project thought leaders deem appropriate to get the job done….While you could argue this is an example of project methodology construction, it often appears reactionary and wasteful because the resulting practices don’t address the project’s contextual needs.

  1. July 12, 2013 at 9:43 am
  2. July 17, 2013 at 7:35 am
  3. August 7, 2013 at 6:23 pm
  4. August 13, 2013 at 2:55 am
  5. October 9, 2013 at 5:59 am
  6. February 10, 2014 at 7:28 am
  7. February 22, 2014 at 5:11 am
  8. March 3, 2014 at 7:37 am
  9. July 7, 2014 at 5:47 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 555 other followers