Disciplined Agile

In the Vendor management in the Disciplined Agile enterprise blog post, we overviewed a Disciplined Agile (DA) approach to vendor management, including procurement. In this post, we look closer at how to use lean and agile techniques to procure goods and services in complex situations.

Context counts, also in procurement

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

Table 1. Common procurement situations

Figure 1 depicts the goal diagram for Vendor management (click here to view a larger version of the diagram) and table 2 maps the situations summarized in table 1 to the choices and strategies from the goal diagram. How we work matters and it has a dramatic impact on the result of our work. Matching our way of working to the context we face is the cornerstone of success at work.

Figure 1. The vendor management goal diagram

Table 2. Mapping common procurement situations to potential procurement strategies

When it comes to developing a complex product or service, we have learned that working in an agile and lean way brings better results faster, more reliably, and with higher quality. The agile and lean way of working (WoW) takes an incremental approach with short feedback loops. The short loops act as learning points where we can adjust to new information and changes that inherently are a part of doing complex work. 

It turns out that the same is true for procuring goods and services. When we set out to procure complex goods or services, or are faced with a complex situation, applying agile and lean techniques is more successful than using traditional procurement approaches. 

How do you apply agile and lean practices to procurement?

Generically speaking, procurement follows the flow of: Initialize, Analyze & prepare, Select & sign, and Execute & beyond as shown in figure 2.

Figure 2. Generic procurement flow

Lean Agile Procurement (LAP) follows the same flow and takes advantage of agile and lean practices along the way to deliver more successful results in a complex procurement situation. Table 3 summarizes some of the agile and lean techniques that LAP applies in procurement.

Table 3. Lean Agile Procurement Flow Steps

In summary, context counts and the DA tool kit for vendor management guide you in tailoring your WoW (way of working) to better match your situation increasing your chances of success. When faced with a complex procurement situation, Lean Agile Procurement (LAP) is a more successful approach. 

Authors: Klaus Boedker and Mirko Kleiner

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. 

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.

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.

Essence was created by the  Software Engineering Method and Theory (SEMAT) community and approved by The Object Management Group as a standard in 2014. The basic of Essence is that “provides the common ground for defining software development practices” (see [R1-ES]) and also is intended to build and maintain an open library and marketplace of software engineering practices and education materials (see [R3-SMMS] ).

Essence is important, (see specification [R1-ES]), because:

• “Provide a common base that is useful for software engineering endeavors of all sizes (small, medium, and large)”
• “Enable method building by the composition of practices, so that methods can be quickly assembled by a project team to match their needs, experiences, and aspirations. Allowing the method to start small and grow as needed”
• “Support method agility, so that practices and methods can be refined and modified during a project to reflect experiences, lessons learned, and changing needs”
• “Support scalability including from one product to many, from one team to many, and from one method to many”

In this article I show how to describe DAD Essentials. Essentializing DAD is different from similar endeavors because Disciplined Agile (DA) is not a prescriptive method/framework like Scrum/SAFe. Instead, DA is a toolkit based on similar goals as Essence in that it is generative – both provide building blocks from which you can tailor and evolve a process that meets your needs.

The role of this Essentials is to provide an overview of the DAD guidance and over the capabilities that could be developed for each significant aspect (“Alphas”) of an Agile & Lean process. What is really happening on Agile/Lean adoption (and in any process improvement) is developing & exercising of new capabilities. What is specific to Disciplined Agile is that it provides guidance for developing the capabilities that team & organizations needs for their specific context.

DAD Essentials are presented here in cards format using the OMG/SEMAT Essence Language constructs as Alphas, Patterns, Resources, Activities, Work Products (see Glossary section below). Each “card” has a name, a description, and a list of capabilities for your team or organization to develop.

The following terms are used in Essence.

	Alpha	An essential element that is relevant to an assessment of the progress and health of the software engineering endeavor.
	Patterns	A generic mechanism / complex concepts that are made up of several other elements
	Resources	A source of information or content.
	Activities	One or more approaches for carrying out some work to be performed and can recommend actions on alphas and/or work products in order to and relevance this work.
	Work Products	An artifact of value and relevance for a software engineering endeavor.

Full delivery life-cycles

Full, beginning-to-end, delivery life-cycle it is an explicit representation of how a software release will progress in time. The pragmatism and effectiveness of Agile (<> Waterfall) are based on realistic progress milestones with the evolution of working software toward a consumable solution.  A team could have a reference lifecycle, but in a different context, they may need to use also other types of life-cycles.

Capabilities to develop:

• A reference life-cycle
• Support for Iterative-Agile, Lean, Continuous Delivery life-cycles
• Support for high incertitude deliveries
• Support for long term roadmaps (product, business, technology)

Consumable Solution

Consumable solution is more than working software. Consumable means that we meet stakeholder needs in the context constraints and it is usable, desirable, and functional. A solution implies that, as needed, we:  

• Develop high-quality software
• Provide new or upgraded hardware/platform
• Change the business/operational processes which the stakeholders follow
• Change the organizational structure in which our stakeholders work
• Update supporting documentation

Capabilities to develop:

• Understand Consumable Solution
• Build using DAD guidance the Consumable Solution across life-cycle milestones, considering various life-cycle and practices options depending on context

Adapt to Context

DA supports two principles that motivate you to adapt your approach to your context:

• Context counts. People, teams, and organizations are all unique – leads us to a critical idea that your process and organization structure must be tailored for the situation that you currently face.
• Choice is good. Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA framework presents people with choices through the application of process goal diagrams.

Capabilities to develop:

• Understanding Agile Scaling/Tailoring Factors
• Tailor WoW in context using DA Guidance
  • Select life-cycles
  • Select practices per process goals in a given context and life-cycle
  • Use DAD Library of practices & context options guidance
  • Make experiments to see what works in your context

Core Agile Practices

Core Agile Practices will help you have a Lean process: they address the main sources of waste and have multiple benefits at the same time. It is not a coincidence that XP is based on some of them, Disciplined Agile and Agile Modeling refer them as critical practices. (See also references from Mary Poppendieck / Tom Poppendieck in “Lean Software Development”). Some core practices are:

• XP practices: Small Releases, Pair Programming, Simple Design, Refactoring, TDD, Coding Standards, and more.
• DA/Agile Modeling practices: Requirements/Architecture Envisioning, Architecture Handbook, Model Storming, Rolling Wave Planning, and many more.
• Method free practices: Clean Code/Architecture.

Interestingly, Essence describes in detail several dozen core agile practices in detail whereas Disciplined Agile puts several hundred agile, lean, and even traditional core practices into context. This is one of several reasons why Essence and DA are complementary to one another.

Capabilities to develop:

• Understand how and why you will eliminate waste
• Context usage: Core Agile Practices are not “best practices” and we still need to know the trade-offs and options for different context (See Adapt to Context alpha). Make experiments to see what works in your context

Teal Teams and Organizations

Optimize the whole: the Organization (and its constituents teams) represents that “whole” where the work optimization really makes sense. In Reinventing Organizations, Frederick Laloux presents the historical evolution of organizations from tribal to modern agile approaches:

• Red (Magic/Tribal): Impulsive, survival urgency
• Amber (Traditional/Agrarian): Authoritarian, formal hierarchy
• Orange (Scientific/Industrial): Task-oriented, profit/grow focus
• Green (Post-Modern/Information): Value-based, consensus/participative style
• Teal (Self-Organizing/Adaptive): Cellular organism with evolutionary purpose

Disciplined Agile use this model and propose as a goal the Teal organization (or at least Green): cellular, self-organizing, adaptive, aware, with evolutionary purposes. Most likely, your organization is a “rainbow” (e.g. Orange/Green/Teal). Context counts, different teams faced different situations and you can choose your strategy. You want to be at least Green because that will provide – through a participative & collaborative style – a solid foundation for further process improvement. Also, the DA Principle, Be Awesome has some expectations:

• Treat people with respect, honesty, be reliable and open
• Willingly collaborate with others

Capabilities to develop:

• Teams will offer psychological safety with clarity about roles and responsibilities
• Cross-functional skills teams, where T-skilled “generalizing specialist” is the most pragmatic, effective, efficient approach.
• Use collaborative work to envision, look ahead and just-in-time clarifications.
• Collaborative and continuous process tailoring and improvement, not only on retrospectives
• Inter-teams’ collaboration: Communities of Practices and Centers of Excellence, etc.
• Individual, team, enterprise and community level awareness
• Use pragmatic agile roles
• Address team and organization level scaling factors

Guided Process Improvement

The purpose of the Continuous Improvement process blade is to enable people within your organization to easily share their improvement learnings with one another in a systematic way. The technique of Guided Continuous Improvement (GCI) shows teams how to leverage the DA toolkit to speed up their process improvement efforts.

Capabilities to develop:

• Continuous improvement must be explicit and fundamental
• A base support for improvement should be running: life-cycles, collaborative work, retrospectives
• Kaizen strategy: continuous improvement should always be running in small steps and experiments. This lean strategy is fundamental for addressing problems complexity & incertitude.
• Guided Continuous Improvement (GCI)
  • apply the DAD toolkit to adapt to context (see corresponding alpha) for process goals as: selecting a life-cycle, forming the team, addressing changing stakeholders needs.
  • hire/listen experienced coaches
  • make progress on adopting Core Agile Practices
  • have explicit goal/guidance for Evolving your WoW

An Agile method such as Scrum, or a framework such as SAFe, can be a good start but it will have too few guidelines for choosing your way of working (WoW) in context or too little guidance for core Agile practices. DA provides the guidance for evolving your WoW and Essence the details regarding core practices. As Ivar Jacobson likes to say, this will enable you to break out of “method prison.”

Patterns

Resources

Work Products

Activities

I want to thank Scott Ambler who started this Essentializing DA initiative and collaborated with SEMAT from 2009. Scott helped me with feedback and review of current materials. DA Essentialization began with the example of the DB Refactoring technique earlier this year.

• [R1-ES] Essence Specification 1.2 – https://www.omg.org/spec/Essence/1.2/
• [R2-SM] SEMAT (Software Engineering Method and Theory) – http://semat.org/
• [R3-SMMS] SEMAT mission statement: http://semat.org/mission-statement
• [R4-ESSDB] Essentialize DB refactoring –  Database Refactoring
• [R5] DA approach for organizations – Teal is the New Black

Copyright statement

Use of Essence – Kernel and Language for Software Engineering Methods Specifications is the subject of Term and conditions & Notices found at https://www.omg.org/spec/Essence/1.2