One of the mantras of the agile community is that you need to "be agile," that you need to adopt an agile mindset. Agilists will often point to the Manifesto for Agile Software Development, commonly referred to as the Agile Manifesto, as a good starting point to understand this mindset, which it is. Other mantras within the agile community include respecting others and having a safe environment that embraces diversity. All wonderful ideas, but what do you do when they collide with one another?
The Disciplined Agile Mindset
Figure 1 depicts the Disciplined Agile (DA) mindset, which is captured in the form of principles, promises, and guidelines. Disciplined agilists believe in the DA principles, so we promise to adopt these behaviours and follow these guidelines when doing so. Where the Agile Manifesto addressed the environment faced by software developers 20 years ago, the DA mindset addresses the environment faced by organizations today. The DA mindset reflects our learnings over these past 20 years, adopting great ideas from a wide range of sources, in particular ideas around lean and flow, to describe concepts that enable enterprise agility.
Embracing Different Mindsets in the DA Tool Kit
One of the promises of the DA mindset is to create psychological safety and embrace diversity. Interestingly, when you do that you soon realize that people often have very different mindsets and that this is a very desirable thing. Yes,we want people to embrace an agile mindset so that we all share a similar point of view, but that's only one of many points of view. There are still noticeable differences between the way that you approach something and the ways that others do, even when everyone involved has an agile mindset. This happens because we are all unique people with unique experiences and backgrounds, and as a result you have other points of view than just the agile mindset.
I'm sure that you've noticed that finance people have a different perspective than people from marketing, whose perspective differs from data management professionals, which is different yet again than research and development people, and so on. Each business function tends to attract, and then reinforce, people of a certain mindset. Some people find legal work incredibly interesting, whereas others find it spectacularly boring. To each their own.
This is where it gets interesting. Remember that DA is a tool kit that supports improvement across all aspects of your organization, not just software development. One aspect of the architecture of the DA tool kit is that we've captured the different business functions within your organization as process blades, which in turn are described in terms of mindset, people, flow, and practices. Process blades include Finance, Strategy, Legal, Marketing, Security, IT Operations, Portfolio Management, and many more. Regarding mindset, for a given process blade, we extend the base DA mindset with philosophies that are applicable to that process blade. For example, Figure 2 depicts DA's People Management (Human Resources) mindset and Figure 3 DA's Security mindset.
There are several important points to this strategy:
Just like one process does not fit all situations, one mindset doesn't either. The Disciplined Agile (DA) tool kit explicitly embraces mindset diversity. Do you?
We used to say that software is eating the world, but the fact is today software is the world. Gone are the days where IT could be treated like a utility, one that more often than not was outsourced in the belief that you needed to focus on your core competencies and IT didn’t make it onto that list. These days being competent at IT is mere table stakes at best, you need to excel at IT if you hope to become an industry leader. Today business executives must focus on disruptors, new competitors entering their market space using technologies in new ways. Becoming an agile business – an adaptive, responsive, and learning organization – is the true goal. Business agility requires true agility across all of your organization, not just software development, not just DevOps, and not just IT. There isn’t a single industry now that either isn’t dominated by agile businesses or isn’t under threat of disruption by new agile competitors.
The Disciplined Agile (DA) tool kit was created to apply agile in complex enterprise agile implementations. DA has been well received and implemented in organizations around the world. According to Gartner, Disciplined Agile is also the only available agile process explicitly allowing enterprises to customise agile for their unique enterprise challenges at both the organization and project levels. In their research report, Adopt Disciplined Agile Delivery for a Comprehensive and Scalable Agile IT Approach, Gartner reported:
In this article, we address several common questions executives have about Disciplined Agile (DA):
The Disciplined Agile (DA) tool kit provides straightforward guidance to help organizations streamline their processes in a context-sensitive manner, providing a solid foundation for business agility. The figure below provides a high-level overview of the scope of DA (click on the diagram to zoom in).
DA provides a foundation for business agility does this by showing how the various activities such as Finance, Portfolio Management, Solution Delivery (software development), IT Operations, Enterprise Architecture, Vendor Management and many others work together. DA also describes what these activities should address, provides a range of options for doing so, and describes the trade-offs associated with each option.
DA also provides a straightforward strategy for implementing value streams, overviewed in the following diagram (click on it to zoom in).
You can read more about DA in Introduction to Disciplined Agile.
There are several reasons why your organization should adopt the Disciplined Agile (DA) tool kit:
You can read more about why you should consider DA at Why Disciplined Agile?
DA is being used in numerous organizations, in a wide range of industries, around the world. You can see a list of a subset of the organizations using Disciplined Agile.
Yes. We have published several Disciplined Agile success stories with more on the way.
The answer to this question depends on what you're trying to achieve:
There are several ways that you can learn more about DA, and we recommend following the one(s) that seem best for you:
There are also several options for getting a team going with Disciplined Agile, we recommend considering all three:
Our fundamental advice is to start where you are, do the best that you can given the situation that you face, and always strive to get better. To succeed, there are three key concepts to understand:
Although every organization's journey is unique, we have found that at a high-level they all follow a similar 3-step transformation path:
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.
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.
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.
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.
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.