PMI Sites
Register
Disciplined Agile
Search

    The Guardrails – Promises we make with each other to achieve business agility

    Guardrails

    guardrailsThe seven promises made across the organization are sometimes called “The Guardrails for creating business agility” (the quick realization of business and customer value predictably, sustainably and with high quality). This set of promises is made by all roles in the organization make with each other  to facilitate working together and achieve their common goals. They also provide a background for asking effective questions that can be used to ensure they are keeping their promises.

    The promises are made in support of what organizations are attempting to achieve – accelerate value realization. To do this, of course, people need to collaborate.  Collaboration requires that all work and workflow be visible. This reduces delays between steps of work, thereby increasing predictability. One of the biggest causes of waste and unpredictability is when people are overloaded and forced to multi-task. Hence, we also agree to keep workloads within capacity. And, of course, we want to improve continuously.

    In order to do the above, we must create psychological safety so that people feel safe to speak up in order to improve things.

     

    Agreements and Promises

    Agreements are promises about how we will work together. Many people have a fear of making a promise. They worry that if they don’t keep it they’ll look bad. So they say things like “I’ll try” which basically avoids commitment. But there is no real collaboration if there is no commitment to working together with accountability.

    We need to rethink what many of us hold a promise to be. I think of a promise to do “x” as:

    • An agreement that I will do ‘x’ unless something beyond my control happens
    • If something beyond my control does happen, I will do everything within my control to counter act it
    • I also agree to let you know at the earliest sign that something beyond my control might happen

    This enables us to work together, do our best, without guilt. Note, that agreements like fidelity, are always within your control. So there is no ‘out’ here for that.

    Agreements with each other are promises about how we are going to act. How we are going to collaborate and work together. About communication and intention. We need to agree with each other what they mean and that we will keep them.

    The promises

    We agree to:

    See the promises by role

     

    The Promises

    Each promise includes a variety of questions that people can ask themselves to assess if they are keeping them.

    Promise: Create psychological safety.

    Working in an Agile manner requires psychological safety. Without it, people will hide bad news and won’t try small changes that might be improvements.  Psychological safety is required in order to make things safe to fail so that we can learn fast. While all of these promises are made as something each person must keep, this one is mostly one for leaders and managers as they are the ones who often create an environment of things not being safe.  But each person in the organization must make it safe for at least their co-workers.  We are not suggesting “fail fast.” We are suggesting to make it safe to fail so we can learn fast. This safety is both about the people and the system.

    Promise: Accelerate value realization

    We agree to work on items that will realize the greatest amount of business and customer value across the enterprise.

    Business value usually comes in the form of adding value to the customer. It is important to realize, however, that business value is distinct from customer value. A clear example is an organization’s enterprise architecture. While it is indirectly related to customer value in that good enterprise architecture enables quicker delivery of customer value, it is not something that individual teams focusing on customer value may be attending to. In addition, part of a business strategy may be to ignore certain customer markets (e.g., Southwest Airlines ignores travelers who want reserved seats).

    The purpose of this promise includes:

    • Realize more value by working on and delivering only those items of greatest value.
    • Enable the creation of alignment across the organization by having people understand what’s of greatest value. This helps people decide what to work on when there are conflicting requests.
    • Use relative value as a way of keeping your work beyond capacity. Do not start things of lesser value that will slow down things of greater value.

    Some questions to consider when trying to follow this guardrail:

    • Are all activities based on having us realize Business value incrementally?
    • Are we using Minimum Business Increments (MBIs) where appropriate?
    • Have we allocated all of the required capacity to work on the most important MBIs?
    • Have we sequenced work so all can align on what is most important?
    • Do we have a clear success criteria?
    • Do we understand why what we are working on is valuable?
    • Do we measure Business value realized after delivery?

    Note: Some of these MBIs may be architectural / technical in nature.

    Promise: Collaborate proactively

    We agree to collaborate with each other to maximize the realization of Business value across the enterprise.

    The purpose of this promise includes:

    • By working together more effectively  people in the organization can focus on realizing the items that will provide the createst value to their customers, thereby supporting the accelerate value guardrail.
    • Delays in work, workflow, feedback and using information are often due to lack of collaboration across groups. These delays create additional, unplanned work that has an adverse cascading effect.
    • Collaboration on a worthwhile goal is fun and helps build trust and respect.

    Some questions to consider when trying to follow this guardrail:

    • Are we collaborating together to remove delays in feedback, workflow and realizing Business value of our MBIs?
    • Do we have the proper ecosystems to allow for collaboration?
    • Are different teams working together for the common goal of Business value realization?

    Is the most common form of communication “talking to” / “meeting with” colleagues?

    Promise: Make all work and workflow visible

    We agree to ensure that all work and workflow is visible.

    Visibility means being able to see these readily:

    • The workflow being used to realize value
    • The work being undertaken, including its size, priority and status (being worked on, waiting, blocked)
    • Any impediments present
    • Dependencies between pieces being built
    • Dependencies between groups that are involved in building the same item
    • Capacity issues
    • Quality issues

    The purpose of this promise includes:

    • Without visibility, collaboration is difficult.
    • Visibility of priorities enables people to make decisions when there is limited capacity and a person who is a constraint on others has to decide what to work on.
    • Visibility enables people to be aware of constraints downstream so they can start work that they’ll have the people they need to realize it
    • Visibility enlarges our view of things and helps avoid local optimization that has an adverse affect on the overall speed of delivery.
    • Visibility of MBIs enables technology clarity on the context and purpose of what they are building.

    Some questions to consider when trying to follow this guardrail:

    • Can everyone see all Work-in-Process?
    • Can everyone see what is and/or will be expected of them?
    • Can everyone see any blockages present?
    • Is the status of everything clear?
    • Can everyone see any risks to delivery dates?
    • Is all work that is being done visible?
    • Do people know what everyone is working on and why?
    • Does everyone know when and why work is getting done?
      • Are additional roles required to ensure this?
      • Are there visual controls that can show this?
    • Is it clear how work activities are interacting?
    • Are all active or scheduled activities visible so that people can see what is happening?

    Promise: Increase predictability

    We agree to take the necessary steps to sustain or increase predictability.

    Predictability does not mean being able to see the future. The essence of Lean and Agile is using feedback and to course correct continuously. However, there are many unpredictable things that can be avoided or at least detected quickly so as to minimize their effect.

    • Many bad estimates are due to poor code quality.
    • Lack of automated testing results in large delays in discovering problems causing additional work.
    • Misunderstanding requirements cause a tremendous amount of unplanned work to be created.
    • Most of unpredictability is due to the delays in feedback loops in the exchange of information and  in validating what we are building.

    The purpose of this promise includes:

    • Unpredictable events typically create additional work, thereby reducing the speed of realization of Business value.
    • Unpredictability fosters an attitude of distrust which causes a loss of respect.

    Some questions to consider when trying to follow this guardrail:

    • Predictability requires sustainability and reliability.
      • Are we working at a sustainable pace?
      • Are we avoiding shortcuts that will lead to problems in the future?
      • Are we using consistent estimation practices and calculations of team capacity to accurately predict throughput?
      • Are we committing to a level of work commensurate with our proven delivery capacity?
    • Are we attending to technical debt, poor communication and bad visibility?
    • Are we managing interruptions?
    • Does all work come through a known work intake process?
    • Are we minimizing our dependencies on other groups?
    • Are we automating all of our testing?
    • Do we have written acceptance tests prior to writing code?
    • Is feedback sufficient?
      • What we are building
      • How we are building it
      • What our rate of progress is
      • Across all roles

    Promise: Keep workloads within capacity

    We agree to keep the work throughout the value stream within capacity.

    Managing Work-in-Process (WIP) is a cornerstone of Lean and Kanban. Scrum manifests it indirectly through the use of sprints, saying that a team should not plan more work than it can accomplish during a sprint. Managing WIP is not merely a way to focus on finishing. It can be used to decide what to start and not start.

    With the combination of sequencing items of value, visibility and predictability, items of value can be started or deferred based on whether the capacity to build, deliver and realize value from it is achievable. Working beyond capacity in any part of the value stream that is a bottleneck creates delays in work flow and creates a large amount of unplanned work.

    The purpose of this promise includes:

    • Avoid working on more things that people should be working on.
    • Create flow of work throughout the value stream.
    • Improve the efficiency of the work being done.
    • Allow for quicker feedback through the elimination of delays.

    Some questions to consider when trying to follow this guardrail:

    • Is WIP visible and appropriately limited?
    • Are we emphasizing completion rather than starting new work?
    • Are we ensuring we know what it means to be “Done” before starting something?
    • Do we know the delivery capacity of the organization? The Portfolio? Teams?

    Promise: Improve Continuously

    We agree to encourage everyone to strive for continuous improvement.

    The purpose of this promise includes:

    • If we are not continuously improving then we are likely to fall back into bad habits.
    • Continuous improvement keeps us engaged and feels good.
    • Knowledge workers like a challenge.
    • Many competitors are continuously improving and we need to do the same to stay competitive.

    Some questions to consider when trying to follow this guardrail:

    • Are teams performing retrospections on a regular basis?
    • Are after action reviews being done at the Program level on a regular basis?
    • Are teams and the Program implementing what is learned in these AARs?
    • Are we measuring the right things?
    • Do we proactively report and review metrics to look for trends / issues and take corrective actions?
    • Do we look at ‘leading’ versus ‘trailing’ indicators to help stay on track?

     

    The mindsets that undergird these promises

    There are a number of mindsets that support the guardrails.

    Systems thinking. The guardrails are based on Lean Thinking, a cornerstone of which is systems thinking. The essence of systems thinking is:

    • All aspects of the system are inter-connected
    • The overwhelming number of challenges individuals face in a system are due to the system
    • The system shapes the behavior exhibited by those in the systemTo change the behavior of people in the system, focus on improving the system

    Faith in quality. The guardrails are also based on another tenet of Lean Thinking, a commitment to quality. This commitment stems from the belief that when one lets quality slide for a short term gain, the net result will be more waste in the long term. Hence, we always attend to achieving fixing challenges.

    Sustainability. There are two aspects to sustainability – short term and long term. Short term sustainability means we don’t attempt to achieve objectives by just having people work overtime. That is, death marches are not allowed. Long term sustainability means we look to see if the actions we are taking will make us less dependent upon outside consultants or even key management. In other words, we can keep going even with losing some key people.

    Respecting culture. Changing organizations is difficult. Doing so without attending to the current culture people have makes it even more difficult. Different organizations change at different rates and cherish different ideals. It is important to respect this when attempting to change it.

     

    Why these promises create a foundation for improving an organization

    How can seven simple promises make such a big difference? There are several important reasons. First, these promises encompass the critical aspects of value delivery. But just as important, because they are promises across all roles, they encompass the entire value stream. This combination provides a context within which all roles can make decisions. Everyone can have confidence that if they take actions that maximize Business value, increase predictability, manage capacity, ensure visibility, collaborate, and continuously improve that they will be adding value to the overall value stream.

     

    The Promises by role

    While the promises are the same for all roles, how they manifest them is different.  For example, “Keep WIP Within Capacity”, is done different for managers and teams. For managers, this means not interrupting teams capriciously or demanding teams work on more than is effective. For teams, it means to have a focus on finishing and not start too many things.

     

    An Imaginary Conversation That Comes Up With Useful Promises

    Working with Agile methods requires different agreements with each other. While exactly what we do depends upon the particulars of our organization, the objectives of what needs to happen are surprisingly similar.  Let’s look at an imaginary conversation between an internal consultant and their CEO:

    Consultant: What is the number one thing you want to achieve?

    CEO: We need to be able to deliver value to our customers more quickly than we do now.

    Consultant: Do you think we’ll need to work together in order to do this? That is, would coming up with a set of agreements on how we work together would be a good idea?

    CEO: Of course, but what would those be?

    Consultant: GIven your goal, it seems the first one would be to agree to only do things that accelerate the value realization to our customers.  This creates the umbrella for everything else.

    CEO: Yes, that makes sense.

    Consultant: So we should look for other promises that support this one, I would think.

    CEO: Yes. But what does that mean really, what actions do people have to do?

    Consultant: Great question.  There are quite a few Lean and Flow practices that support this. But making the promise really means to look to see that any actions are consistent with this. Some of the actions to consider would be to work with small batches and not delays items of greater value for items of lesser value. But this gets into the how. There are no universal rules. The promise “accelerate the value realization to our customers” creates a context for our actions.

    CEO: OK, so what other promises might we need?

    Consultant: I think you can tell me. What would it take to accelerate value?

    CEO: Well, we’d have to collaborate. Getting part of the work done by some of the people won’t get it out the door. Seems to me we’d have to all agree to collaborate with each other.

    Consultant: That sounds good. I think this really means we have to focus on the whole and not just our part of the work. And we’d like to do this proactively – not doing it only when demanded.

    CEO: Yes, so maybe we call this second agreement “collaborate proactively.”

    Consultant: Love it. And to collaborate, people need to see what work is in play and how we’re working on it. So our third agreement should be “make all work and workflow visible.”

    CEO: Yes, agreed. This doesn’t seem like enough however. I can see people focusing on adding value and collaborating and making their work visible. But how can we be sure we predictably get value?

    Consultant: Full predictability is not possible. But a mostly predictability is. We want to look for what causes unpredictability. In product development poor quality often causes unpredictability because some small change has a ripple effect and requires many others. This is particularly true in software development.

    So a promise to increase predictability would focus on improving those things that caused unpredictability.

    CEO: Sounds good. But maybe we should call out the number one cause of unpredictability?

    Consultant: That of course depends on the organization. But we’ve seen that when people get overworked predictability goes out the door. It’s not just the multi-tasking that takes place, it’s the unplanned work that occurs when work is set aside because people have to shift their focus to something else.

    CEO: You mean stop overloading people? I have always felt a bit of pressure is good.

    Consultant: Maybe it is. But “a bit” and “overloaded” are two different things. Do you think your people need motivation? Are they not trying as much as they can?  How does putting pressure on you work? Are you more or less productive?

    CEO: Less, I see your point. So our 5th promise would be to keep our workload within the capacity of people doing it.

    Consultant: Yes.  It seems that we should also be getting better all of the time. So how about we promise to improve continuously?

    CEO: Makes sense. But you know, this is going to require people to speak up and talk more about what’s going on. I like to think I’m a pretty good leader but I know I don’t always take bad news well.  What can we do about that?

    Consultant: I’m sure you’re not alone in this. Sounds like we need a final agreement – to create psychological safety.

    CEO: Exactly what does that mean?

    Consultant: It means that people can work and not have to worry about telling the truth. It makes for both a better working environment and the truth enables us to work better.

    CEO: OK, so I’ve been taking notes. It seems like we’re suggesting that we all promise to do the following:

    1. Accelerate value realization
    2. Collaborate proactively
    3. Make all work and workflow visible
    4. Increase predictability
    5. Keep workloads with capacity
    6. Improve continuously
    7. Create psychological safety

    Consultant: Yes, that’s what I’ve got as well.

    CEO: Although we came up with create psychological safety last, when I look at it, it really seems to crate the umbrella for everything.  Maybe it should be #1?