1 comment on “How to use culture change to build sustainable agility”

How to use culture change to build sustainable agility

In Part 1 of this series we explained why you shouldn’t apply agile frameworks and industry best practices blindly in your organization.

There are serious downsides to prescribing agile practices

It is because they generally come with what, why, and how but the how doesn’t always work in your company’s or team’s context. When the standard approach jams up against your current way of working it actually reduces productivity, and increases frustration and resistance. Not only that – but asking teams to specifically implement certain ways of working (the how) actually sends a strong signal that they must continue working this way and continuous improvement isn’t important. The teams you work with will either become frustrated, stagnate, may never really improve and may even slide backwards when experienced coaches step away. It’s all because the team members didn’t really understand why what they were doing was important and why it was designed that way to begin with. 

I once was coaching a scrum master that was running retrospectives after sprint planning. I decided to educate him on what order the scrum guide said retrospectives should be in. Immediately, after realizing that it was in the wrong order he agreed to switch the order so that retrospectives happened before planning. He didn’t ask WHY scrum had it in this order and so I told him not to do it because Scrum said to do it in this order. Instead I asked him to first understands WHY those who designed scrum put it in this order and then decide if that was a valuable reason for this team.

This team recently started running planning before retrospective because they felt that it was better to use their peak energy on planning first instead of on retrospective first and then planning. Swapping these for the sake of meeting the industry standard wouldn’t have made the team happy because they wouldn’t have understood the intended benefits, and they would have only seen the downsides; that planning would be harder because they would be tired by then.

The act of knowing and understanding why and giving them choice allows them to weigh the pros and cons and make the best choice for themselves. If they choose to swap the order of the events, at least they understand why this is important to them. The alternative, swapping it for them, and asking them to do it because it’s the ‘correct order’ would certainly have demoralized them and caused them to disengage if they didn’t understand why or have a choice.  This also means that if they are armed with why, and choose the best way for their context, they are much less likely to slide backwards.

Sustainable agility via creating a continuous improvement culture

In the above example, we see the core principle of building a continuous improvement culture emerge. Teams that clearly understand WHY and choose to improve themselves because of the WHY are more likely to sustain the improvements they make.  

Fantastic. Now you’re probably thinking education is what I’m proposing, but we all know education is time consuming and it comes with no guarantees that it is actually used or implemented.  Once we understand the above core principle we have to do everything we can to ensure that both education to create awareness of new improvement opportunities and choice to improve is harnessed and maximized continuously. If we can do this, then we can build a continuous improvement culture. 

We have to find a way to give the team (and leaders) an ongoing platform for which they are expected to stand up and demonstrate what they are doing to continuously improve. This should not just be when a problem happens, but all the time, hence continuous improvement. What I’m about to share with you will show you just one tool in my tool belt that I have found extremely valuable when used to create this platform and if used correctly will jump start your culture towards one that is designed to continuously improve.

A culture that demands everyone to transparently demonstrate what they are doing to continuously improve enables much more value than one that demands specific agile practices to be implemented. 

Enable sustainable agility by promoting a continuous improvement culture using these techniques


Leaders and teams both have Improvement Backlogs

An improvement backlog is a public place for us to log improvements that we want to do because we think they will be valuable. These improvements should impact the way we work together in process and with people. If you are tracking metrics that generate improvement conversation you should find those improvements being added to this backlog and this backlog should exist for teams, and leaders. This is the holy grail that will serve to tell you how your organization is actually doing at improvement. If there is nothing on these backlogs, then you’re likely not where you want to be yet.

If we want to promote a continuously improving culture than we need this mechanism in place to ensure that we are transparently able to demonstrate how we are trying to improve.

Regularly track a base set of metrics that are designed to elicit improvement conversations in critical outcome areas  

Metrics on speed and quality alone don’t help you to improve. They don’t help people identify areas of opportunity that they could improve next. For this reason I recommend a focus on a variety of other metrics.  

Here are some metrics I use for leaders and teams to both rate how teams are doing. This opens the door for a different kind of feedback to teams and leaders that they haven’t had in the past. 

  • Suitable Process
  • Sustainable Pace
  • Team Size
  • Ease of Collaboration
  • Safety

Here are some metrics that leaders and teams both rate on how leaders are doing. Yes, I get teams to rate leaders because it’s only fair and gives two-way feedback to help leaders improve as well.

  • Leadership Support
  • Team purpose and goal
  • Product purpose and goal

Here are some metrics that each team and their coaches both rate on how well the team is doing in certain outcomes. This enables education when big gaps are identified

  • Release forecasting
  • Planning
  • Estimation Methodology
  • Progress Checking
  • Improvement Backlog
  • Improvement Generation

Here are some metrics that leaders and their coaches both rate on how leaders are doing in certain outcomes. We need leaders to achieve continuous improvement behavior too and shouldn’t expect it only from teams.

  • Improvement Idea Progress / Impediment Removal Progress
  • Improvement Idea Generation
  • Budget for teams to use at their discretion
  • Transparent Product Intake Workflow
  • New member On-boarding workflow

Here are some objective metrics that teams are tracking at minimum

  • Improvements Ideas raised / month (on the improvement backlog)
  • Improvements Implemented / month (on the improvement backlog)
  • Quality Metrics (e.g. Escaped Defects)
  • Value Predictability Metric (e.g. velocity or lead time)

Here are some objective metrics that leaders are tracking at a minimum

  • Improvement ideas raised / month (on the improvement backlog)
  • Improvements Implemented / month (on the improvement backlog)

It sounds like a lot, but I’ve got probably around 20 of these metrics per team and leaders It usually takes them about 30 minutes to do this quarterly and the outcome is usually highly engaging and valuable. If implemented the right way, the team’s understand that these metrics are used for improvement and not for performance and they are shared transparently between perspectives (leaders, teams and coaches). This especially helps with coaching because teams can rate how well they perceive they are doing and coaches can correct a perception where there is a lot more opportunity for improvement (a classic example where there is always a gap is estimation methodology). The biggest gap between perceptions is where the biggest learning opportunity is.

The underlying idea is to track outcomes that you think will help spawn improvements to be put into the improvement backlog, but never prescribe how to achieve these outcomes. Coaches can give options and teams and leaders can choose the best option for their context.

Used correctly these can have a profound effect on culture

There are likely a number of outcomes that are so basic, it’s safe to say that every team and leader should try to achieve them. You should ensure that you track these outcomes as metrics that leverage the three different perspectives (team/coach/leaders) and regularly get organization leaders to inspect them to ensure that improvement is happening. The goal is to ensure that improvements are being raised onto the improvement backlog now that it’s very transparent that improvement opportunity is available and perspective sharing starts to increase. 

When everybody starts to learn what the improvement opportunities are, why they will help them, and improvement progress tracking becomes an expected norm then you are well on your way to creating the culture of continuous improvement where teams actually improve, and ideas stick for good. 

Just don’t prescribe how. Let them decide as they try to achieve and improve the outcomes you’ve put in place. 



1 comment on “Why you should stop applying Agile frameworks and best practices.”

Why you should stop applying Agile frameworks and best practices.

If your Agile transformation has been a painful experience you are not alone. This seems to be very common. They say change is hard. I strongly believe that we’re making a HUGE mistake with the approach in implementing this type of change in our organizations and we are making it much more difficult than it needs to be. There is a better way and I believe I have discovered what it is. I am confident that if you take a different approach it will reduce the amount of difficulty your organization experiences trying to improve and you will yield much more effective outcomes.

But first, let’s understand what a lot of us experience.

Most of you use the same approach and have the same goals and then feel surprised and frustrated when the plan doesn’t yield the desired results

You realized at some point that you need to work with your teams to improve delivery so that it is more effective for your business and for your customers. In order to do this, most of you probably create a plan which includes teaching your team how to implement the trending industry best practices. You probably make sure to explain the end goal to improve time to market, increase quality, or improve overall effectiveness. Sounds pretty solid so far and everybody and their grandma is trying this to be more competitive in the market.

Then you try to implement it and everybody becomes frustrated and annoyed, resistance is high and morale takes a nose dive. The practices aren’t deriving the value you had hoped for and has caused more frustration than benefit. You keep pushing forward, but soon people start begging to return back to the old way of working because it was “better”.

If this sounds familiar there is a reason this happens and I’m about to tell you why. Read on, soldier.

Agile was created out of a burning desire to continuously improve but they go too far and tell us how to work instead of how to improve

There is one line in the agile manifesto that you should pay very close attention to. That line is that “We are uncovering better ways of developing software by doing it and helping others do it”. To me this translates to “We are uncovering better ways of working by learning as we work”. The Agile manifesto was created out of a desire to find new and improved ways of working.

The problem is that Agile frameworks and a lot of associated practices tell you a SPECIFIC way of achieving a desired outcome and that it is supposed to be better than your current way of working. They define HOW you should work instead of focusing only on WHAT outcome we should try to achieve and WHY. They lock us into an approach and so Agile frameworks and practices DO NOT actually help us learn how to uncover better ways of working. They tell you a specific way of working that we must follow. This makes it very difficult for you to learn what works best in your context.

For example, according to the Scrum guide, the team must only show done work in a sprint review. With refinement, the Agile industry practice is to use story points for sizing and so most teams use them, and also use stories. These are rules that define HOW the team should run based on industry best practice. They don’t consider the context of your environment or the challenges your team has currently. Applying these rules blindly and strictly will cause the negative result I described earlier; an extreme amount of frustration.

Teaching teams the rules actually sends a message that this is the way they must work and that you don’t want them to find better ways of working. Implementing Agile frameworks or best practices is contradictory to why Agile was created to begin with. So the first step to improving and trying to achieve those goals for your business and your customers is to actually stop making teams apply these frameworks and practices blindly. Instead teach your teams how to continuously improve and build a culture that encourages it. Easier said that done, and in a future blog post I will be explaining a few new techniques that I’ve discovered that can help you to achieve this.

0 comments on “Agile is 15 years too young for Scrum.”

Agile is 15 years too young for Scrum.


The Agile Manifesto was published in 2001 by 17 software developers who were already using lightweight software development methodologies regularly. They wanted to move the industry away from using heavyweight, documentation driven software development methodologies. They had found that software development projects were increasingly experiencing very long delivery timelines, which often meant that the solution that was proposed and documented 2-3 years ago, wasn’t the right solution for the market once it was released 2-3 years later. Additionally, these projects were plagued with missed deadlines and/or outright project cancellations halfway through development.  And so, the 17 developers needed a way to refocus the industry on lightweight methodologies by publishing a new set of values that they found led to more successful software development projects; and that’s when the Agile Manifesto, and Agile as we know it today, was born.


But, did you know that Scrum and many of the other Agile Frameworks were created BEFORE Agile? Agile frameworks such as XP, SCRUM, DSDM, ASD, Crystal, Feature-Driven Development, Pragmantic Programming and others were around before the Agile Manifesto was even created.

In fact, Scrum goes as far back to an article published on Harvard Business Review in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka called “The New New Product Development Game“. The article doesn’t yet define Scrum as a process, but only merely references Scrum once as a single heading “Moving the Scrum Downfield” where Hirotaka and Ikujiro carefully explore and analyze then-prominent product development companies and what patterns they found that made for the most successful product development. It makes for a very interesting read because while it is a very small study, it shows that scrum’s roots are from careful analysis and research comparisons of teams that were actually trying to complete software projects effectively.

Takeuchi and Nonaka are not officially recognized as the creators of Scrum today. Thier article was published in 1986, but scrum was being experimented with by Jeff Sutherland and Ken Schwaber in the early 1990s. In 1995, they codified and published scrum in the form of a paper titled “SCRUM Development Process” and presented it in a object-oriented conference in Austin, Texas. If you look at some of the references in this article, they actually reference the same article written in 1986 by Takeuchi and Nonaka. This indicates that the creators of Scrum were influenced by the research findings of Takeuchi and Nonaka. So while Scrum was officially published and codified in 1995, there was almost a decade worth of time between the 1986 article and Scrum’s official codification. In-between this period of time the Scrum framework itself was being practiced and codified!


So if this is the case, and the 1986 article was the basis upon which Scrum was created, then Scrum itself was created upon a foundation of some empirical evidence that showed that successful product development teams have the following attributes.

  • Built-in instability (unknowns that require them to come up with solutions and be able to make autonomous decisions)
  • They are self organized
  • They are cross functional and have overlapping development phases to remove hand over between silo’s.
  • They embrace learning through experimentation (MultiLearning)
  • They get feedback often from customers and management
  • Management avoids controlling them through command, but prefers to control them through influence (Subtle Control)
  • They promote their learning throughout the organization so that others can learn what they’ve already learned.

This is taken right out of Takeuchi and Nonaka’s article in 1986. Note that I’ve paraphrased some of the above points to use some of today’s terminology.

The Agile Manifesto and Scrum are closely aligned and they work to achieve some overlapping values, and principles. The Agile Manifesto was in response to the frustration of failed development projects in order to promote lightweight frameworks like Scrum. Scrum was created from evidence based empirical research for successful product development teams and companies. This suggests a very strong connection between the need for being Agile, the need for lightweight frameworks, and the likelihood that the combination will yield the highest possible probability of success for software development projects

So there you have it. This is why the industry is moving towards using Scrum and Agile development practices, and why Agile loves Scrum.



1 comment on “Effective Change Leadership Requires Inclusive Decision Making”

Effective Change Leadership Requires Inclusive Decision Making

Agile is built upon teams of highly motivated individuals that leaders support to the best of their abilities, and they trust their teams to get the job done.


Dan Pink, the writer of the book titled “Drive”, recognizes through numerous studies and observations that human motivation can be grouped into three key areas; autonomy, mastery, and purpose.

It comes with no surprise that autonomy is a major motivator for a company’s workforce, and when autonomy is threatened or perceived to be removed then the result is likely to be a demotivated workforce and lower overall engagement.


Agile frameworks give more autonomy back to teams, but they are notoriously difficult to scale. When an organization starts working with multiple teams on one product, where teams and processes need to be aligned in order to achieve consistency, speed, and quality, how can we ensure that teams stay motivated, and continue to feel autonomous. As an organization we will need to make changes to the process often as we strive to improve the system; the team’s process and ability to deliver working software. So what is the most effective way to make changes that affect multiple teams, and still have them feel autonomous and motivated?


It is pretty common for leaders to leverage a small group of key influencers to provide them with insight before making a final decision – but they often make decisions without including everyone else because it’s faster. This kind of decision making is called Issuing and Edict. The decision has already been made so you either agree with this decision, or you quit. In other words, you must comply. As a member of a team, you don’t have any input or control over this type of decision. If you or your team is affected by this decision in any negative way, what choice do you have? Would you feel accountable to find a better solution? Would you feel empowered to suggest alternatives? Over time, this type of decision making and removal of autonomy creates a system of people that do not try to improve the system. Unfortunately, when leaders get into the habit of making these kinds of decisions, it can cause a downward spiral in motivation.  An added problem is that leaders often may not have all the critical information, and the decision they make may hurt the system more than it helps it. This is the unintended consequence I try to avoid with multi-team or organization wide decisions.


When leaders involve everybody in a decision, everyone feels heard. As a leader there are generally three different decision making methods to reach a decision across larger groups or multiple teams:

  1. Issuing an Edict
  2. Decision by Consensus
    (agreement for a course of action including specific details)
  3. Decision by Consent
    (agreement to support the general direction but not necessarily looking for agreement to all the specific details)See Max Widemen’s comparison of consensus vs consent for more details on the differences and when you should consider applying each one. By the way, it might be a good idea for you to do a little more research and try switching to a consent model of decision making. 

Both decision by consensus and consent are slower than issuing an edict. However, the decision will have more buy in and will better support workforce empowerment, autonomy and motivation.


YES!! An idealist would say, all decisions need to be made by the teams – but a realist would recognize that it’s simply not possible for everyone to get together every time and make a decision. The organization would improve far too slowly this way. Speed of decision making is critical for an agile organization – but so is a team’s engagement and motivation.


I suspect that a more balanced approach to decision making would be most effective – and you will have to use your judgement to find the right balance for your organization.

The below framework is designed to help you find the right balance, for each decision your organization needs to make.

Artboard 1

These are the main groups to consider when making a decision for change.

  • Unaffected – goes without saying. These people just don’t need any involvement. It seems silly to call this out – but sometimes when making inclusive decisions we tend to include people who just don’t care – and that doesn’t help.
  • Indirectly Affected – this group’s day to day work process will likely stay the same, but they may interact with people that belong to the system that is changing and this may have some unintended or intended consequences for them.
  • Directly Affected – this group’s day to day work process will likely change or be impacted by the decision that is about to be made. They are the ones that will feel most affected by the pain if the change is a bad one.
    • Key Influencers – those people who usually have a high impact on decisions being made because they are regarded as the experts or ones in the know
    • Empowered Decision Makers – the people selected that will have to agree in order to make the decision.
    • Decision Driver – the person who wants the decision to be made and is driving people to make sure it happens

Now that we’ve defined these groups, let’s look at the process.


  1. Identify a Decision Driver
    Responsible for facilitating the decision making process. The decision driver should create awareness of the pending change/decision to people who will be Directly Affected by the change/decision being proposed. It is a judgement call whether they include the Indirectly Affected group or not and to what degree. If you expect some significant impact to them the rule of thumb is to Keep them Informed.
  2. Form a group of Empowered Decision Makers
    This is the most important part of the process. Here are some key guidelines to get it right:

    • Ensure this group is made up of people at the lowest possible level. If you have members of the teams in the empowered decision making group – you are likely to make the most effective decision, and get the most buy in.
    • Keep this group relatively small; 5-7 people.
    • The Empowered Decision Makers are ultimately accountable for making the decision, and they can chose if Key Influencers get a vote (or not).
      • TIP: Ask people from the Directly Affected group who would like to be part of the decision making process and include them in one of these groups to get even more buy-in on the final decision.
  3. Include Key Influencers in the decision making process.
    They are called out as a separate group in the graphic – but your best bet is to include them in the Empowered Decision Makers group. This is another judgement call – but rule of thumb is to include them.
  4. Share the proposed decision with those who are Directly Affected and illicit feedback. Again, with the Indirectly Affected group, use your judgement.
    This is where things get really interesting. The goal here is not to get everybody to agree – but to get a feel of the general temperature of the workforce with regard to the decision. It’s also an opportunity to catch any serious drawbacks that weren’t considered that could sway the Empowered Decision Makers to go in another direction.
  5. The Empowered Decision Makers make the final decision and communicate it and push the change forward. 

There you have it. Try this framework to get more involvement while also making quicker decisions. Let me know what you think in the comments below.



You may be thinking that the graphic below has nothing to do with Agile, and you’re right – it wasn’t created for this purpose. It was published by Gartner to help us understand the maturity and adoption of specific technologies. In the talk that Tristan Kromar gave at the ‘Entrepreneurial Spirit in the Enterprise’ hosted by Lean Enterprise Toronto, he mentioned that this same cycle can be witnessed in organizations trying to adopt agile – which as we know, is not easy.


If you find yourself in the ‘Peak of Inflated Expectations’ area of the cycle or anywhere before it you should be very careful. This represents the highest risk area of the agile adoption cycle, and if expectations are set to be really high, the crash into the trough of disillusionment will be very sharp. You might notice this when the organization reacts with organizational changes in response to their realization that their first implementation of scrum or kanban didn’t solve their problems right away.


If you’re coaching an organization to use Agile, set the right expectations upfront. There will be a steep and long learning curve that has to happen before gaining the productivity that leadership wants and expects. The adoption of agile frameworks is an investment in the organization itself and should be seen as one. If these expectations are clearly set at the very beginning the peak of inflated expectations can be lowered, and the crash into the Trough of disillusionment should not be as steep.


0 comments on “High Performing Teams Give to Each Other Selflessly.”

High Performing Teams Give to Each Other Selflessly.

The united states Navy Seals are considered one of the most elite forces in the world. One of the most highest performing groups on the planet. To become a Navy Seal they have to go through something called BUDS, which is a multi month selection process which destroys their bodies, and the vast majority of people will drop out and never become seals because it is so aggressive.

A former seal was asked, what kind of person will make it through buds.

Some of the guys who become seals are skinny, and scrawny. Some of the guys, who become seals, you will actually see them shivering out of fear. There is one thing that they all have in common. When they are emotionally exhausted. When they are physically exhausted. When they have absolutely nothing left to give. Every single one of them is able to dig down deep inside of themselves to find the energy to help the guy next to them. Those are the guys that become seals. In other words, the highest performing teams on the planet are not the strongest, are not the smartest, and are not the fastest.

The highest performing teams on the planet are the ones that give to each other selflessly. They commit themselves to taking care of each other and this is what makes a great team.

See video for more inspiration.