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

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?

PMI and Disciplined Agile at Agile20Reflect

Vendor Management in the Disciplined Agile Enterprise

The overarching goal of the Disciplined Agile (DA) is to guide organizations on their path to business agility, sometimes called organizational agility. When organizations increase their overall agility, they are able to rapidly adapt to market and environmental changes in productive and cost-effective ways. This enables organizations to deliver more value in a shorter amount of time, predictably, sustainably, and with high quality.

Looking at the Disciplined Agile (DA) tool kit in figure 1, we get an idea of the organizational areas that are involved in pursuing business agility.

Figure 1: The Disciplined Agile (DA) tool kit

The DA tool kit shows us that it is not enough to focus on delivery-level agility represented by the Disciplined DevOps layer. To achieve business agility, the organization must pursue agile and lean ways of working at the Disciplined Agile Enterprise layer; like legal, finance, and vendor management.

In this post, we focus on the role of vendor management and how it can contribute to the overall agility in the DA enterprise.

The mindset of vendor management: partnerships are key

Vendor management is a process blade in the DA tool kit. In other words, it represents a functional area inside the organization that serves a specific purpose. The purpose of vendor management is to help obtain products and services from other organizations. 

To do that successfully in a disciplined agile way, vendor management follows a set of philosophies that extend the DA mindset:

Figure 2: A Disciplined Agile mindset for vendor management

1. Value through partnerships. We increase value through partnerships with other organizations. 

2. Collaborative partnerships. We seek to build collaborative partnerships with other organizations, even when those organizations are our competitors or competitors to each other.

3. Mutually beneficial partnerships. We seek to build, maintain, and evolve mutually beneficial relationships with our suppliers and partners.

4. We co-create with our partners. We co-create throughout the entire vendor management life cycle, including procurement. This means that we may even have both our own experts and vendor experts actively involved in the procurement process. 

5. We are trusted advisors. We are a trusted advisor inside the organization to present and guide both supplier and partnering options.

6. Organizational outcomes come first. We pursue organizational outcomes over local process conveniences, working in an enterprise aware manner.

7. We protect our organization. We have a fiduciary responsibility to protect the organization.

8. We address risk holistically. We address risk in an appropriate, proactive, and holistic manner. 

The flow of Vendor management: context counts

One of the DA principles is that "context counts". This principle is also applicable to the area of vendor management. Table 1 lists three different types of procurement situations.

Table 1: Different procurement situations

Each of the situations requires a different flow or approach to successfully find the right partners that can deliver the good or service to the organization. 

The practices of vendor management: choice is good

Another DA principle states that “choice is good”. In vendor management, we see this manifested in its goal diagram. Click here to see a larger version of the goal diagram.

Figure 3: Vendor management goal diagram

The diagram covers the key decision points of vendor management: from how to manage intake requests, and how to select a procurement strategy, to ways of governing partnerships. Most of the decision points’ options are non-ordered, meaning they are equally preferrable. It is worth noting the two areas that have ordered options: select procurement strategy, and capture working agreements. The ordered options are called out with an upwards arrow, meaning the choices at the top are more desirable than the choices at the bottom from an agility standpoint.

With the goal diagram, you have access to a suite of options, choices and strategies that are presented in architected way for easy access and navigation. The suite of options, choices and strategies allows you first of all to find your baseline today: what is our existing way of working (WoW) in procurement? Secondly, the suite of options, choices and strategies allows you to find areas where you can improve and tailor your way of procuring to better match the given context. 

Let’s look at an example. One of the vendor management decision points is to select potential partners.

Figure 4: Decision point for "select potential partners"

The decision point offers a suite of options, ranging from short-listing potential partners, comparing submitted proposals, and holding a big-room event for multiple vendors.

 In our example, you are part of the company’s procurement team. Up until this point, your team has solely been relying on the option of “compare submitted proposals” to select vendors regardless of what you are procuring. That is your baseline way of working (WoW). If your team procures goods or services that less straightforward than, say printer paper and toner, you have likely come across some challenges in finding the right vendor. Taking advantage of the information in the vendor management goal diagram, you can now pick a more tailored WoW depending on your procurement context. 

For example, procuring a commodity (new paper and toner for the office printers), a straightforward comparison of submitted proposals will likely be sufficient. In fact, you may even go so far as to automate the buying decision completely, such as with printers placing an order for toner when it runs low. But faced with a more complicated context, such as procuring a new fleet of delivery trucks, you have the option to employ additional strategies to increase your chances of success. These strategies could be: shortlisting potential partners, interviewing potential partners, and then comparing submitted proposals. You may even hold a vendor bake off where the shortlisted vendors demonstrate their vehicles.

In summary, context counts. The DA tool kit guides you in tailoring your WoW for vendor management to better match your context increasing your chances of success. 

Posted by Klaus Boedker on: March 15, 2021 03:01 PM | Permalink | Comments (1)

Update: Scaling Factors of Tactical Agility

Categories: Context, scaling

Scaling Factors Update

We've have recently updated our thinking around the tactical scaling factors that we apply in DA to help understand the context faced by a team or organization. Figure 1 depicts the original scaling factors and Figure 2 the new scaling factors.  Below we discuss what changed and how this can affect anyone taking a Disciplined Agile (DA) certification exam.


Figure 1. The (original) scaling factors of the SDCF.

Scaling factors of the Software Development Context Framework (SDCF).


Figure 2. The scaling factors of the SCF.

Scaling Factors of the Situation Context Framework (SCF)

What's Changed?

The changes we made were motivated by our experiences applying the scaling factors outside of IT teams.  Originally these scaling factors were described by the Software Development Context Framework (SDCF) which we evolved into the Situation Context Framework (SCF) in late 2020.  Here is what has changed:

  1. Renamed Technical Complexity to Solution Complexity so as to generalize the concept.
  2. Added Skill Availability as a scaling factor. 
  3. Reworked the naming of several options for the scaling factors to make the spectrum of choices clearer and more general.


Implications for DA Certification Exams

As you can see in Scaling Factors we have made it clear that the exam will test you for knowledge about the original version for now (in Figure 1) and that when we update the courseware and exam to reflect this update we will let you know. In general our intent is that whenever material on the web gets ahead of what is being tested for that we'll make it clear that this has happened.  More on this in a future blog posting.


Further Reading

  1. The blog posting Choosing Your WoW: The Situation Context Framework (SCF) overviews the SCF in detail, including descriptions of each scaling factor.
  2. The article Scaling Factors provides a good summary of the scaling factors portion of the SCF.
  3. The article Tactical Agility at Scale: Scaling Agile at the Team Level provides a summary for how DA applies the SCF.








Posted by Scott Ambler on: January 19, 2021 03:59 PM | Permalink | Comments (2)

Does your team own its process or merely rent it?

Process ownership

An important philosophy within both the agile and lean communities is that a team should own its process. In fact, one of the principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The idea is that teams should be empowered to choose their way of working (WoW), to "own their process," including both their team structure and the process that they follow, to meet the unique needs of the situation that they find themselves in. Teams that own their process will tailor it over time as they learn how to work together, adopting new techniques and tweaking existing ones to increase their effectiveness.

As with most philosophies this one is easy to proselytize but not so easy to actually adopt. When it comes to process improvement, teams will exhibit a range of behavior in practice. Some teams see process as a problem and actively seek to ignore process-related issues. Some teams are ambivalent towards process improvement and generally stick with what they’ve been told to do. And some teams see process improvement as an opportunity to become more effective both as a team and as individuals. This range of behaviors isn’t surprising from a psychology point of view although it can be a bit disappointing from an agile or lean point of view. It has led me to think that perhaps some teams choose to “own” their process but many more still seem to prefer to simple rent it.

The behaviors of people who rent something are generally different than those who own something. Take flats for example. When you rent a flat (called an apartment in North America) you might do a bit of cosmetic work, such as painting and hanging curtains, to make it suitable for your needs. But people rarely put much more effort than that into tailoring their rental flat because they don’t want to invest money in something that isn’t theirs, even though they may live in the flat for several years. It isn’t perfect but it’s good enough. When you own a flat (called a condo in North America) you are much more likely to tailor it to meet your needs. Painting and window dressings are a good start, but you may also choose to renovate the kitchen and bathroom, update the flooring, and even reconfigure the layout by knocking down or moving some walls. One of the reasons why you choose to own a flat is so that you can modify it to meet your specific needs and taste.

You can observe similar behaviors when it comes to software process. Teams that are merely “process renters” will invest a bit of time to adopt a process, perhaps taking a two-day course where they’re taught a few basic concepts. They may make a few initial tailorings of the process, adopt some new role names, and even rework their workspace to better fit the situation that they face. From then on they do little to change the way that they work together. They rarely hold process improvement sessions such as retrospectives, and if they do they typically adopt changes that require minimal effort. Harder improvements, particularly those requiring new skills that require time and effort to learn, are put off to some point in the distant future which never seems to come. Such behavior may be a sign that this “team” is not even be a team at all, but instead a group of individuals who are marginally working together on the same solution. They adopt the trappings of the method, perhaps they spout new terminology and hold the right meetings, but few meaningful changes are actually made.

Process owners behave much differently. Teams that own their process will regularly reflect on how well they’re working and actively seek to get better. They experiment with new techniques and some teams will even measure how successful they are implementing the change. Teams that are process owners will often get coaching to help them improve, both at the individual and at the team level. Process owners strive to understand their process options, even the ones that are not perfectly agile or lean, and choose the ones that are best for the situation they find themselves in.

The Disciplined Agile (DA) tool kit is geared for teams that want to own their process. The DA tool kit is process goal-driven, not prescriptive, making your process choices explicit and more importantly providing guidance for selecting the options that make the most sense for your team. This guidance helps your team to get going in the right direction and provides options when you realize that you need to improve. DA also supports multiple life cycles because we realize that teams find themselves in a range of situations – sometimes a Scrum-based life cycle makes sense, sometimes a lean life cycle is a better fit, sometimes a continuous delivery approach is best, and sometimes you find yourself in a situation where an exploratory (or “Lean Startup”) life cycle is the way to go.

You have choices, and DA helps guide you to making the choices that are right for you in your given context. By providing process guidance DAD enables your team to more easily own its own process and thereby increase the benefit of following agile or lean approaches.

Posted by Scott Ambler on: March 03, 2014 07:37 AM | Permalink | Comments (1)

Exploring 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 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 Scope process goal diagram

Let’s consider each process intent/decision point:

  • 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 Architecture Strategy, Coordinate Activities, and Accelerate Value Delivery 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 choose their own way of working, 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 tool kit provides this guidance.


Related Reading

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

Choosing Your WoW: The Situation Context Framework (SCF)


The Situation Context Framework (SCF), an evolution of the Software Development Context Framework (SDCF), defines the contextual factors to consider when selecting and tailoring a situation-dependent way of working (WoW).  The SCF is used to provide context for making decisions about how to organize your WoW to be fit-for-purpose.  Figure 1 overviews how several selection factors drive the initial choice and tailoring of your team high-level WoW, in particular your choice of lifecycle.  Of course initial selection is just the first step, you will also need to tailor your detailed choices to reflect the situation that you face - these decisions are driven by the complexity factors that you face.

Figure 1. Context factors for selection and tailoring your way of working (WoW).

Situational Context Framework Factors

Selecting an Initial WoW 

When you initiate a team you need to identify key aspects of your WoW, in particular:

  1. Your team organization. When it comes to team organization you have several issues to consider.  Will the team be composed mostly of specialists such as business analysts, user experience (UX) designers, implementers 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.
  2. How you will work together. 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?  A hybrid approach?  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?
  3. What tools you’re going to use. With respect to tooling there is a myriad of options and it seems as if everyone has an opinion as to which tools are best.  However, our 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?

The choices that you make initially will change over time as you learn and as your situation evolves, the point is that you will make some broad choices at first to get going.


The Selection Factors

The decisions about your initial WoW 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. Figure 2 overviews these selection factors, indicating the range of the extremes for each one - On the left-hand side is the simple extreme and on the right-hand side the challenging extreme. .

Figure 2. Selection factors.

Situation Context Framework Selection Factors


The selection factors are:

  1. Team member 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 software 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 serial/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 certain 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 marketing projects, and to procuring services from an external partner.  Our 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 the development and execution of a marketing campaign.  But, it isn’t very easy to decompose an airplane into several working parts.  Either the airplane is complete or it isn’t.  Yes, it’s still possible to apply agile techniques to the building of the airplane, and very likely to it's design as well, but the airplane team will never be as agile as a software development team due to the physical and regulatory constraints that they face.
  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, particularly those for communication and collaboration.


The Complexity Factors Pertinent for Choosing Your WoW

The complexity factors of the SCF affect your decisions when choosing techniques/practices when you choose and evolve your WoW. Figure 3 explores these complexity 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.  

Figure 3. Complexity factors.

Situation Context Framework Complexity 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 large agile team of 600 will be organized into subteams and a leadership team will be required for coordination, something we capture in DA's Program life cycle.  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, often the situation of a startup company or new product team within an enterprise.  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.  Partnering with several vendors even harder.  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. Skill availability. Your team needs the right people with the right skills to fulfill the outcomes that you've taken on.  At the ideal end of the spectrum you have skilled people "sitting on the bench" waiting to get going, at the other end it may take many months and potentially lots of money to build the team that you need. The availability of skilled people, or at least people with the ability to quickly gain the skills that they need, is a driver of organization distribution.  When your immediate organization doesn't have easy access to the required skills you may need to start partnering with other groups or even external organizations to gain them.
  5. Compliance.  There are two forms of compliance.  Generally the simpler form of compliance is self-imposed, perhaps your organization chooses to be CMMI or ITIL compliant.  The second, and potentially harder, form of compliance is regulatory.  A team may need to conform to financial regulations, privacy regulations, or even existential/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.
  6. 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.
  7. Solution complexity.  Disicplined agile teams will face varying levels of solution complexity.  On the simple end of the spectrum you’ll have the development of a brand-new, stand-alone solutions built with new technologies.  Things get more difficult if you need to take advantage of existing assets, including software, data sources, or business services.  Things get more difficult if you need to support several technology platforms.  Things are more difficult yet if you need to refactor existing infrastructure (including legacy data sources).  As with domain complexity, the greater the solution 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.


History of the SCF

Where do these ideas come from?  The primary source is something called the Agile Scaling Model (ASM) which I led the development of in 2008-2009 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 Mark Lines and I began thinking about how to combine and evolve these two frameworks into one, something we originally called the Process Context Framework (PCF).  We moved away from that name because the strategy was clearly applicable to more than just software process, hence we adopted the name Software Development Context Framework (SDCF) which is inclusive of people, process, and tools.  Then of course, over the years, we applied this to far more than just software development, so we evolved this to become the Situation Context Framework (SCF) in 2020.


Related Reading

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

"The rule is perfect: In all matters of opinion, our adversaries are insane."

- Mark Twain