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

RSS

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

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)

DA and Enterprise Risk Management

Risks are inherent with projects. They are an attribute of doing something new or novel that distinguishes projects from regular operational work. How well we navigate risk often decides the success of not just a project but also an organization.

In a recent blog post, we looked at how Disciplined Agile (DA) teams can effectively navigate risk, both threats and opportunities, at the project level. This post examines DA’s Enterprise view of risks at the program and portfolio level.

Often team members and project managers focussing on the success of their project may not see how their efforts at project optimization can be misaligned at an enterprise level. In Lean terms, this is known as local vs. global optimization.

Program Risks Can Compound

We know that breaking large endeavors into smaller ones helps reduce risk. Reducing complexity, the number of stakeholders involved, and the project’s duration (horizon of risk) all help increase the likelihood of success.  

However, risks compound when the overall benefit is contingent on the success of multiple dependant projects.  If a business outcome depends upon “Project” A completing, followed by “Project B,” “C,” and “D” each at 75% of success, the overall program only has a .75 X .75 X.75  X.75= 32% chance of a successful outcome. Working on our endeavor, it is sometimes difficult to appreciate the dependency implications of connected chains.

Downstream Risks

Project teams are often incented to take a limited view of success based on how they are measured. Did we complete it on time? Was all the scope signed off? Did we finish within budget? Again, putting on our Lean hat and taking a global vs. local optimization view, how did we really do?

The DA Governance process blade looks beyond the project for possible downstream risks. Project teams may ignore risks associated with increased operational load or sustainability. Sure, we shipped on time, but if we created increased maintenance costs, the organization might be worse off rather than better off as a result.

Aggregate Risks

Knowledge sharing is critical. Individually, a risk exposure may seem acceptable, but if it is common to 50 inflight projects, the aggregate risk may exceed the organization’s risk appetite. Likewise, if many different risks could be triggered by a single event, then that aggregate risk may not be fully appreciated at a project or product level.

Sharing risk information allows for better steering at an organizational level. However, it takes a culture of support for bad-news communications as well as good-new communications for this to work. Creating psychological safety where leaders demonstrate the desired behavior is a good starting point. Then encourage information sharing throughout the organization and help rather than punish the messenger.

The upside is that opportunities aggregate also. The time or cost savings for buying a tool or improving a process may not make economic sense for a single team, but it may be viable if applied to all teams.

Ongoing Risk Governance

We should make sure teams are actively managing the risks on their projects. Check that the appropriate risk tolerances and response strategies are being applied. For instance, one team lead’s view of an acceptable risk might be very different from another’s.

Check that teams understand and are applying the basics of risk management. Have they established risk thresholds for recording risks and escalating them? Are they identifying and acting on risks and opportunities? Are they engaging the right stakeholders and with review and response actions?  In short, are they following the advice captured in the Address Risk process goal?

Reviews can seem like micromanagement and lead to a lack of trust and resentment. To avoid this, explain why risk management is essential and look for evidence of understanding and intent-based actions over compliance to rigid standards unless those standards are required for your industry.

At the enterprise level, check risk tolerances are normalized, and teams are sharing their threats and opportunities across the organization appropriately. When teams are focused on delivering features or meeting a deadline, they may lose sight of risk management work.

Risks as a Positive Sign of Progress and Growth

It is important to recognize risks are a sign of healthy activity. By their very nature, projects are risky because they try new things. They create or change products and services which carry a risk of problems and failure. However, there is an ever-present opposing-risk of enterprise-inertia.

Organizations that do not innovate, improve or even just keep pace with the speed of their industry’s evolution are moving backward compared to their competitors. The risk of reduced competitiveness, loss of market share, or market presence in new communication channels have real consequences. Innovation and evolution through projects counter-act this risk.

“A ship in harbor is safe, but that is not what ships are built for.” This quote parallels the need for projects and some risk-taking. Organizations need project development, product development and other initiatives to stimulate change and to keep moving forward. They carry risk, but so too does standing still. DA provides Lean inspired guidance for applying global as well as local suggestions to help exploit opportunities and avoid or reduce the inevitable threats associated with innovation.

Posted by Mike Griffiths on: December 18, 2020 12:22 PM | Permalink | Comments (6)

PMI Chapter Opportunity: The Agile20Reflect Festival

#Agile20Reflect banner

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.
Posted by Scott Ambler on: December 16, 2020 10:32 AM | Permalink | Comments (12)

The Fallacy of Instant Self-Organization: What Team Development Models Can Teach Us

Right from the outset, agile teams are expected to self-organize. Let’s take a team that just started practicing Scrum. To do Scrum well, they must self-organize how they plan the next two weeks’ worth of work during the iteration planning. They must self-organize how to coordinate today’s work during their standups. They must also self-organize how to solicit feedback on what they built (iteration demo) and how they built it (iteration retrospective). On top of that is the matter of actually self-organizing the work of building the actual solution they are working towards. 

That is a lot to ask any team, especially one that is newly formed, or one that has recently changed from their old way of working (WoW) to an agile WoW. I, for one, would venture that it is impossible. A newly formed team, or a team that recently changed WoW, have to normalize first before they can carry out those tasks in a self-organizing manner.

The fact that Scrum and other agile ways of working expect this from the outset is what I call the fallacy of instant self-organization.

What is team development?

Team development and team building often get mixed up. Let’s be clear, team development is not team building. Rather, team building can be a part of team development. Team building is a catch-all phrase for activities where colleagues get to know each other better as fellow humans, not just people at work. Team building can be anything from quick social games (like Pecha Kucha or two truths and a lie) or getting away from the office for a celebratory meal, drink or game of bowling.

Team development on the other hand is a deliberate process in which a team takes time to explore its potential; how it can become even greater than it’s been before. Team development is a journey.

What is a team development model?

There are plenty of team development models to pick from. How teams form and develop has been the fascination and research of many people.

Before we move on, let’s recall the wise aphorism by George Box: that “all models are wrong, but some are useful.” Models are like a pair of spectacles. They help us see the world with more clarity to make better sense of it. But they are all inherently “wrong” because they are not the world itself.

That said, models can be very useful and provide insight and guidance for our world of agile teams. As an agile practitioner, I find three models useful: Bruce Tuckman’s stages of team development model, the Drexler/Sibbet team performance model, and Patrick Lencioni’s five beaviors model.

What can we learn from team development models when it comes to self-organization?

Looking across all three models, we can extract some key points about team development.

First, there are no shortcuts to high performance. In all the models, the team has to travel a journey of set steps or stages before reaching high performance. The steps start out very basic, like building trust and getting to know each other, and progresses to something more advanced where we learn to solve work tasks together. This all seems like a given, but it is often overlooked or forgotten.

Secondly, even though the models all lay out the road to high performance as a neat step-by-step journey, the journey is not linear. We are dealing with people, not printers. People and their interactions are messy, complex and to a large degree unpredictable.

Thirdly, regression can happen anytime. As I discussed above, the scenario of a team that has recently changed their WoW is a prime example of team development regression. The abrupt change of their way of working (say, from a traditional approach to an agile WoW) can likely cause the team members to be unsure of their role on the team, how they are supposed to work together now, and can even erode some of the trust inside the team. Regression can also occur when team members come and go, and in the case of significant external changes, regression is always something to be on the lookout for, and it is always a question that leaders should ask themselves when they make changes. Can this change adversely impact the team’s journey to high performance?

The last and most important point seen from an agile practitioner’s perspective is that the models all offer guidance for the team’s journey. Take the Drexler/Sibbet model for example:

Source: http://www.robertmcneil.com/2016/02/12/the-drexler-sibbet-team-performance-model/

Not only does it tell you what’s going on in each stage (by naming the stage intuitively), it also describes how to move to the next step. If you look closely at the first step (Orientation: why am I here?), you see that if left unresolved, you will get patterns (or rather anti-patterns) of: disorientation, uncertainty, and fear. The tools that we as team leaders have to resolve this step and help the team onwards are: providing purpose, team identity and membership.

Continue your learning journey

The Disciplined Agile People Management process blade contains an overview of how to manage people in an agile enterprise.

The Disciplined Agile Grow Team Members process goal contains a collection of tools and practices of how to continuously grow our team members.

Posted by Klaus Boedker on: December 08, 2020 12:52 PM | Permalink | Comments (5)

DA For Remote Agile Teams

Remote agile teams typically use more video conferencing and extra written communication than collocated teams to stay synchronized. While perhaps not as effective as direct face-to-face communication, these approaches make up some of what is lost from sitting together and provide the advantage of being easily recorded for later access.

This asynchronous access to information is especially valuable for globally remote teams that may not share the same work hours. By accessing content on-demand, people can contribute when works best for them and sync up with the rest of the team at preset events.

Remote Onboarding Challenges

Onboarding new team members can be a challenge for remote teams. Introducing team members, explaining agreed to norms around process and tools are traditionally done in-person. Writing all of this information down along with the justifications and discussions around the decision process is a significant undertaking.

GitLab, one of the most successful all-remote agile development organizations, has onboarding materials that would occupy over 8,000 pages if printed. As organizations transition to more remote-friendly structures, documenting how teams work is becoming more critical.

Disciplined Agile for Onboarding

Fortunately, Disciplined Agile (DA) can help. It contains a vast tool kit of approaches accompanied by industry vetted analysis of when they add value when they do not, along with the pros and cons of implementing them. Teams can use the DA tool kit as the starting point for describing their way of working.

Using the upcoming DA Profiler tool, teams can debate, discuss and decide on their ways of working. The tool captures the goals, decision points and trade-off tables of each selected process or technique. Then, when new team members join, they can be pointed to the saved profile representing the team’s way of working. This saves creating lengthy onboarding materials and descriptions of processes.

Of course, processes should not remain static but instead, continue to evolve as teams and businesses learn and develop. So, at regular intervals, teams are encouraged to review and update their way of working and create a new definition. DA provides a robust strategy to support this and the goal “Evolve Way of Working.”

Keeping it Real

A strength of DA is its realism and pragmatism towards how organizations work. Not all organizations are fully agile yet, nor perhaps want to be. So, if some traditional, serial practices are still in use, that is OK; DA supports it. If Team A uses Scrum with two-week Sprints, Team B uses Kanban with continuous flow, and Team C uses SAFe, that works too.

DA is approach agnostic and capable of supporting a variety of popular techniques along with custom hybrid solutions. It also embraces a set of principles that make building guidance for remote agile teams more successful. These include: “Be pragmatic,” “Context counts,” “Choice is good” and “Enterprise awareness.”  These principles provide practical advice teams can apply to define their remote ways of working.

Mind Your Toes

Returning to the GitLab onboarding process, they promote a fun principle called “Short toes,” which comes from when people join the company and frequently say, “I don’t want to step on anyone’s toes.”

At GitLab, they aim to be accepting of people taking the initiative in trying to improve things. They recognize that as organizations grow, their decision-making speed often slows since more people are involved. However, this can be counteracted by having short toes and feeling comfortable letting others contribute to their domain.

Short toes is a great concept that is required if organizations are to scale and evolve successfully. It aligns well with another of DA’s principles, “Be awesome,” which is all about striving to be the best that we can and to always get better.

Summary

Adapting to the challenges of more remote team members and new all-remote teams creates the need for better onboarding resources.

DA provides great scaffolding to build onboarding handbooks that document how teams have selected to work without making manuals with thousands of pages.  It supports group-based discussion and selection of techniques, ongoing refinement and offline access. Perfect for onboarding today’s increasingly remote workforce.

Posted by Mike Griffiths on: December 01, 2020 04:21 PM | Permalink | Comments (5)
ADVERTISEMENTS

"A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty."

- Winston Churchill