Disciplined Agile

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.

Figure 2. The scaling factors of the 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.

February 2021 will be the 20th Anniversary of the meeting from which the Manifesto for Agile Software Development, or more colloquially the Agile Manifesto, emerged.  To celebrate this, the Agile20Reflect Festival will be held around the world during the month of February.  The festival is a collection of agile learning events around the world, where each event is run by a local group such as a PMI chapter. This is a great opportunity for PMI members to learn more about agile, and for PMI Chapters to host an event for their members as part of the festival.

This blog is organized into the following topics:

1. The events
2. Potential ideas for an event
3. How to organize an event
4. Let's work together

The Events

Good things to know:

1. You choose the theme of your event. The events and activities are to be focused on the past, present or possible future of agile. I've provided a list of potential ideas below that will hopefully get you thinking about what you can do.
2. Events are recorded. All events are recorded and those recordings become part of a lasting research data set like Agile Ted Talks. In the future people can use the recordings to self learn and create their own learning paths. Access to the recordings is free for everyone.
3. The festival organizers really hope PMI chapters will get involved.  They hope that all chapters take part and unlock their creativity to put really interesting creative experiences into the programme.
4. Keep it local. Hosting events and activities on local languages and culturally appropriate to wherever they are happening.

Potential Ideas for an Event

Here is a list of event ideas that should get you thinking about what your chapter can do:

1. Disciplined Agile overview.  Your DA Champion has access to standard decks and can present them to your group.  You may also want to reach out to a DA instructor and ask them to present.  See the Let's Work Together section for how to reach out to instructors.
2. Teach an agile technique. This is particularly well suited for a DA instructor - ask them to run an agile training exercise where they teach a specific agile technique.  Better yet, ask them to teach a specific Disciplined Agile technique that you normally wouldn't learn in commodity agile certification workshops.
3. Case study presentation. Many chapters have members who work in organizations that have gone through agile transformations, or are in the process of doing so.  Ask them to share their experiences.
4. Agile project management topics. I can easily see PMI chapters hosting presentations about Agile PMOs, agile project management, agile portfolio management, agile governance, and so on. These are important topics that aren't covered as well as they should be at agile conferences and events.  So here's an opportunity to get the word out.
5. Agile panel. Panel sessions where people share their experiences adoption agile ways of working, and then answer questions posed by the audience, can be a valuable way to share knowledge.
6. Open space. Adventurous chapters might want to run an open space event where people suggest topics that they want to talk about and then gather in small groups to do so.  This will require an experienced facilitator to run the session. Perhaps now is the time for your chapter to learn about a new technique, open space, to run learning events.  BTW, open space has been part of the DA tool kit for years.

The above list is just a start. If you have other ideas that you'd like to share, please do so (see below).

How to Organize an Event

This is what I suggest you do:

1. Reach out to your chapter's DA Champion. This is exactly the type of thing that a DA Champion should take the lead for (we're in the process of reaching out the champions, so hopefully they've heard about this opportunity already). If you don't know who your champion is then ask your chapter leadership.  If your chapter doesn't have a champion yet then work with your chapter leadership to get an event going anyway, and better yet to get a DA champion.  
2. Reach out to a festival ambassador. There are ambassadors across the world to work locally with groups such as PMI chapters to host events. To find your local ambassador go to the Regional Agile20Reflect Hub list on the festival's home page (it's about half way down the page), select the hub that is applicable to you, and on that page will be the ambassadors for that area of the world.  They're eager to hear from you.
3. Identify what you'd like to do for your chapter.  We've listed some great ideas above, but you're not limited to what we've suggested.
4. Weave this into your existing February 2021 schedule.  We appreciate that this is a last minute request and that you very likely already have a lot scheduled for February.  Please try to find room for this as it really is a great opportunity to get involved with the agile community.
5. Register the event with the festival.  Go to the festival's Add An Event page.
6. Get the word out to your members. Work with your chapter leadership, they're good at this.
7. Consider partnering with your local agile user group(s) or nearby chapters.  This may be a great opportunity to make inroads with other groups, and of course to pool your resources.

Let's Work Together

Time is short, so we need to collaborate to make this successful. Let's take advantage of the Disciplined Agile  discussion forum on LinkedIn to collaborate.  Here's how we can use it:

1. Post ideas for potential events. Please share what you're thinking even if your idea isn't fully baked yet, as I'm sure the community will provide feedback.
2. Post calls for DA presentations.  There are many people qualified to present about DA, particularly DA instructors, who would love the opportunity to speak at your chapter.
3. Post offers to present.  If you've got a DA presentation or case study that you'd like to present to a chapter, please volunteer.
4. Ask questions.  We can help.

This blog posting has been replaced with Risk-Based Milestones.

You may also be interested in How Disciplined Agile Teams Address Risk.

Quick answer

The term predictive is deceptive.

Detailed answer

In the Disciplined Agile (DA) tool kit we use the term traditional or serial, rather than predictive or waterfall, to refer to the classic/linear ways of working.  We feel that predictive is deceptive, more on this in a minute, and waterfall to be insulting (albeit still in common use within the IT community).  Furthermore, we're starting to move away from using traditional as we're now seeing a generation of practitioners who feel that some of the older agile approaches, in particular Scrum, are traditional ways of working.

There are several reasons for why we feel the term "predictive" to be deceptive:

1. "Predictive" implies predictable.  Predictive is defined as "relating to the ability to predict" whereas predictable is "something that happens in a way or at a time that you know about before it happens."  Something that is predictable is a sure thing, yet something that is predictive is not. This is an important difference, particularly given that we know that projects aren't completely predictable - otherwise we wouldn't need risk management.
2. "Predictive" approaches to IT projects are a poor choice in most cases.  Years ago I led a study for Dr. Dobb's Journal that investigated the effectiveness of different approaches (agile, lean, iterative, ad hoc, and traditional) to IT projects.  We found that traditional strategies were less effective in practice than agile and lean approaches, and we weren't the only ones to have found this.  We also investigated what was initially predicted at the beginning of the project and what actually happened by the end of the project, and once again traditional approaches didn't do as well as agile & lean.  BUT, I must stress that the study focus was on IT projects only, not on projects in general.  
3. "Predictive" approaches to intangible projects are likely a poor choice  DDJ found, in several studies in fact, that "predictive" strategies were less predictable in practice than agile/lean approaches in IT.  I highly suspect that this is true of intangible projects in general although do not have hard data to back up that claim.  We need to investigate this.
4. "Predictive" approaches to tangible projects are likely a good choice, but I suspect we can do better.  I suspect that "predictive" approaches are more appropriate for tangible projects, such as building houses or buildings, than agile/lean approaches.  I also believe that a hybrid approach combining the best from traditional, agile, and lean strategies is likely better than traditional alone. Having said this, as with the previous point, I don't know of any research that has compared the various project management paradigms for tangible projects, so this too is something we need to investigate.

In short, we know that "predictive" is a deceptive term for a large category of projects and suspect this to be true for other project types.  As a result the only use of the term predictive in DA is to tell you that we don't use it.

A Disciplined Agile Enterprise (DAE) is able to sense and respond swiftly to changes in the marketplace. It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces. Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

The DAE layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the DAE layer.

Figure 1. The layers of the DA tool kit.

The Disciplined Agile Enterprise (DAE) layer encompasses the capabilities required to guide your organization, to coordinate the teams/groups within your organization, and to support the value streams offered by it.  Figure 2 summarizes the DA tool kit and Figure 3 overviews the process blades that are specific to the DAE layer.  Several process blades of the DAE layer - Research & Development, Business Operations, Strategy, Governance, Marketing, Continuous Improvement, and Sales  - are shared with the value streams layer. The are "shared" in that the scope of these process blades may focus on both the entire organization and specifically on individual value streams.  For example, a financial institution may execute an organization-wide marketing strategy as well as specific strategies for their retail and corporate value streams.

Figure 2. The Disciplined Agile (DA) tool kit.

Figure 3. The process blades specific to the DAE layer.

Expanding upon the value streams layer, the DAE layer adds the following blades:

• Asset management
• Enterprise architecture
• Finance
• Information technology
• Legal
• People management
• Transformation
• Vendor management

Asset management

The asset management process blade addresses the purposeful creation (or rescue), management, support, and governance of organizational assets.  This includes financial, inventory, contractual, risk management, and strategic decisions of these organizational assets. 

Enterprise architecture

The enterprise architecture (EA) process blade overviews how a Disciplined Agile EA team will work. An agile enterprise architecture is flexible, easily extended, and easily evolved collection of structures and processes upon which your organization is built. The act of agile enterprise architecture is the collaborative and evolutionary exploration and potential capture of an organization’s architectural ecosystem in a context-sensitive manner. The implications are that enterprise architects must be willing to work in a collaborative and flexible manner and that delivery teams must be willing to work closely with enterprise architects.

Finance

The finance process blade addresses a collection of potentially competing goals, such as ensuring cash flow within your organization, ensuring your money is being spent well, taxes are minimized, spending is properly tracked and recorded, and legal financial reporting is being performed properly. All of this will be performed in a manner that is compliant with applicable financial regulations, such as Financial Accounting Standards Board (FASB) and International Accounting Standards Board (IASB) guidelines.

Information technology

The information technology (IT) process blade encapsulates the activities required to provide IT capabilities to the rest of the organization.  This includes managing information technologies, data resources, applications, and IT infrastructure.

Legal

The aim of the Legal process blade is to ensure that your organization works within the parameters of the law of any and all legal territories in which you operate. Your legal team will work closely with your vendor management people on (Agile) contracts; with your people management team to ensure that their strategies reflect the local statutes and to help educate staff in legal concerns; with your marketing team to guide what they’re legally able to promise; with your strategy team to ensure the direction they're taking the organization is legally viable; and with governance to understand the legal implications of applicable regulations.

People management

The aim of the people management process blade is to attract and retain great people who work on awesome teams.  People management goes by many names, including human resource (HR) management, human relations (HR) management, talent management, staff management, people operations, and work force management to name a few. This process blade addresses strategies for forming teams; helping people to manage their careers; training, coaching, and educating people; human resource planning within your organization; managing movement of people within your organization; reward structures; and governing people management efforts.

Transformation

The transformation process blade captures advice for how to redefine, and then reengineer, your organization.  This includes understand the current context, identifying the desired future, identifying how to measure the success of the transformation, identifying a likely strategy for moving towards the desired state, and then executing on that strategy.  Throughout a transformation you will constantly gauge your progress and the desired target state and adjust according.  This process blade leverages the advice of PMI's Brightline Initiative.

Vendor management

The aim of the vendor management process blade, sometimes called supplier management, is to help obtain and then manage offerings (products, services, and intellectual property) from other organizations. To do this your vendor management team will collaborate with other parts of the organization to help them understand their needs (if any), identify potential vendors that can fulfill those needs, work with legal to develop appropriate contracts, address vendor-related risks, help monitor and manage vendors, and eventually close out any contracts.