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.

So much of agile teams’ successes depend on collaborative decision-making. Take for example refining the backlog. That is a collaborative decision-making process where the development team, the architecture owner, and the product owner choose the relevant details of each user story. The retrospective is another collaborative undertaking where the team explores and decides how to improve their way of working. Solution modelling, user story estimation, story mapping, and big room planning are more examples of similar processes. The list goes on and on.

If decision-making should be truly collaborative during these processes, how can we encourage everyone to contribute? What can we do to make this work?

First, we need a model that gives us an overview of how group decision-making works. Sam Kaner’s dynamics of group decision-making is a great starting place. The model is split into three parts.

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

Part 1: In the beginning, all ideas are welcome during divergent conversations. We begin with a question or unsolved challenge. As we explore the topic, we easily get to familiar options and opinions. The tricky part is moving past the familiar and uncovering new and fresh perspectives and ideas.

Part 2: Then, with a suite of diverse perspectives and options we enter the groan zone. That is exactly what it sounds like: uncomfortable, awkward, and seemingly dysfunctional. Questions arise. How do we move on? What’s the best idea? Are we stuck? This is the uncomfortable space of moving from “now-we-have-all-these-great-ideas” to, “how-do-we-decide-which-one-to-move-forward-with?” Misunderstanding and miscommunication are normal, natural aspects of the collaborative process. The groan zone is a healthy, unavoidable consequence of the diversity that exists in any group.

Part 3: Eventually, we steer towards the finish line in the convergent stage. This is where we condense the large number of ideas and options to one final decision that we move forward with.

Divergent thinking: ways to keep an open mind

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

The parachute mind (it works best when open)
When starting the divergent stage, think of parachutes. They work best when fully open. The same goes for our minds in the stage of the process which can be easier said than done. Below are some practices that will help you keep your ‘parachute’ open.

Cognitive empathy
Cognitive empathy is the ability to empathize with how others on your team think. Approaching divergent thinking by embracing the fact that we all think differently and that there is no right or wrong way to think about the problem we are solving is a big step in the direction of keeping an open mind. There are a number of short games that illustrate cognitive empathy. One of them is “this is not a stick”.

This is not a stick
To play “this is not a stick” game you need a stick (or something similar, like a broom shaft) and a group of people (between 3-8). Someone starts the game by performing an action with the stick, say pretending to throw a javelin, and says: “this is not a stick, this is a ______”. The other people in the group then has to guess what the stick is. When someone guesses “javelin”, the stick is handed to the next person in the circle and they perform a new action, say, pretending to be fishing, while saying: “this is not a stick, this is a _______”. Playing the game for 8-10 minutes typically allows everyone to go at least twice.

Not only does the “this is a not a stick” game underline the importance of cognitive empathy, it also shows how the group the natural progression in the divergent stage of first coming across familiar options, like javelin and fishing pole, only to move to newer, more diverse perspectives when you build on each other’s ideas.

Yes, and!
Speaking of building off each other’s ideas, the “yes, and!” mindset is a great way to do that. This technique is borrowed from improv theatre where the performers continue each other’s sentences by saying: “yes, and!” The opposite of “yes, and!” is either “no!” (as in, that idea will never work) or the more subversive: “yes, but”. Saying “yes, but” means you cancel out whatever was said before the but and replace it with your own idea or opinion. Take the example of your co-worker, Bob, who presents his idea of selling yellow t-shirts. You know this will never work, so you start your sentence with: “Yes, I like that idea, but we know our customers prefer blue t-shirts”. You have effectively closed down Bob’s idea and replaced it with your own. That is the opposite of a parachute mind.

Using “yes, and!” a different response could be: “Yes, I like the idea of yellow t-shirts, and we can bundle them at a discounted price with our popular blue t-shirts to test the market’s appetite for yellow shirts.”

50 bad ideas
This last technique seems odd at first, and it can really help your team if they are stuck at the “familiar options” state in divergent thinking. Sometimes, you need sheer volume to move on to the newer, more diverse perspectives. Setting yourselves the goal of coming up with “50 bad ideas” can allow you to consider more ideas and move forward.

It works by writing down 50 bad ideas on individual post-it notes. Often it doesn’t take more than 5-7 minutes and it can loosen up the group with some laughs. When done, the group is often energized and has opened up their horizon and can move on to brainstorming newer, more diverse perspectives related to the challenge you are solving.

The groan zone: ways to grit it out

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

In the groan zone, you can use several practices from divergent thinking as well: the parachute mind, cognitive empathy, and “yes, and!” In addition to those practices, there are a number of techniques to help you grit your way through the groan zone.

Active listening
There are three ways to listen: listening to yourself (“I feel like pizza tonight”), listening to others (“I see…”), and listening to others and taking their context into perspective (“It’s okay. I know you were just trying to help”).

Source: http://www.mtbunnies.com/

To move successfully through the groan zone and safely make it to the convergent stage, we need to do our best to stay at level 2, and ideally at level 3.

Emotional intelligence
This state is often uncomfortable, awkward, and seemingly dysfunctional. Questions arise and doubt starts to creep in. How do we move on? How do we find the best idea? Can we even agree on what’s best? Just like misunderstanding and miscommunication are normal aspects of the collaborative process, so are our emotions.

The key is not to ignore and suppress the emotions as they arise in the group, but to deal with them in an intelligent way. So how do we do that?

Source: “Working with Emotional Intelligence” by Daniel Goleman (1998)
Image source: https://positivepsychology.com/emotional-intelligence-frameworks/

Daniel Goleman’s competency framework can help us navigate how to deal with emotions in an intelligent way -as they arise inside ourselves, and as they arise inside the group. It starts with emotional self-awareness and self-management. Once we have dealt with our own emotions, we can focus on the emotions in the group setting (social awareness) and then manage the group emotions in an intelligent way (relationship management), safely guiding us to the last stage.

Convergent thinking: ways to get to the decision

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

We are almost there. So close to the finish line. To get there we need a way to ‘boil down’ our great ideas discussed in the groan zone.

Clustering ideas
Clustering is a really simple way of narrowing down your ideas and options. The technique is exactly what it sounds like: you cluster together the sticky-notes with similar ideas and then give that group a meaningful name.

Some teams prefer to cluster ideas in silence to avoid influencing each other (group think bias). Others prefer to cluster in collaboration and conversation. The choice is yours. Experiment and use what works for your team.

Plotting ideas
Plotting ideas allows you to rank your ideas based on dimensions that are important to your team and context. Let’s say you create a 2x2 grid with these dimensions: “alignment with our team mission (low/high)” and “implementation effort (low/high).” When you plot your ideas into that grid, it will quickly become apparent which ones are highly aligned to your team mission and are low-effort to implement. These are the ideas you pursue first.

Again, some teams prefer to plot the ideas in silence to avoid influencing each other (group think bias), while others prefer to plot in collaboration and conversation. The choice is yours. Experiment and use what works for your team.

Dot voting
The final technique is called dot voting.

Dot voting is a way to ensure that everyone on the team has a say in the final decision. By giving all the team members three votes (represented by three sticky dots) and asking them to place them on the three ideas they most like, we create a fair, transparent, and balanced way of getting to the final decision. If you have a lot of similar ideas, dot voting works even better when you cluster the ideas first.

Dot voting is always done in silence. When finished, one team member tallies the scores, and you can move forward with the winning idea.