0 comments 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.