Monthly Archives: February 2015

It’s been 14 years since the original Manifesto for Agile Software Development was forged on February 12, 2001, by 17 software development leaders.  The pace of change continues to accelerate and Agile Methodologies have begun to successfully replicate themselves beyond software and IT.
Recently Andrew was chatting with some of his colleagues at Knowit Group in Stockholm, Sweden and they had suggested creating a Manifesto that deals with Scaling Agile.  It was during one of the discussions on this topic that Andrew pointed out that there is actually a subtle, yet key, difference between Scaling Agile and Enterprise Governance.  And, so far, it has been a really tough sell for the Technology side of the company to convince the Business side of the organization to adopt “Agile.”  The graphic below might help describe the issue:
 Agile Governance Leadership UVF simplified
Scaling Agile has primarily been limited to all activities below the line in the Technology area.  Governance, on the other hand, is above the line and impacts the entire organization.  To date, Agile has grown organically from the bottom-up.  There are a myriad of team-level tools like Scrum, Kanban, XP, Scrumban, etc.  And, for scaling technology teams and programs there are tools like SAFe, DAD, LeSS, etc.  But, they all are targeted at the technology side of the house.  Management 3.0 sort of straddles the line between technology and business, but it is primarily aimed at and utilized on the Technology side (for the middle-layer of management).
Our tool, the Unified Vision Framework, begins with the Executive in mind.  But also, due to its simplicity, also works at the team-level, regardless of the methodology:
Agile Governance Leadership UVF Napkin
We believe it is time to initiate the discussion about a Manifesto for Agile Governance instead of just for Scaling Agile.  This is because we feel that a Manifesto that could be used for just Scaling Agile, for example, would limit the discussion to only Technology through a management lens.  In our opinion, a Manifesto for Agile Governance raises the discussion to the Executive and leadership levels in the organization.
A number of well-known, authors and experts in the Agile community have recently published books on how to scale Agile and Scrum to the Enterprise level.  We’ll look at those tools in another blog post.  We find it interesting that a Manifesto for either Scaling Agile or Agile Governance hasn’t yet been agreed upon by the Agile community.
To get the ball rolling, we propose the following Manifesto for Agile Governance for consideration:

Manifesto for Agile Governance
We are uncovering better ways of delivering business value
by doing it and helping others do it.
Through this work we have come to value:
Clear Vision and Strategy over team-level, self-prioritization
Servant leadership over micromanaging, command and control
Business value delivered over completed product, service or result
Stakeholder collaboration over unbending governance structures
Iteratively leading change & innovation over following rigid plans 
That is, while there may be value in doing the items on the right,
we value delivering the items on the left more.

All thoughts, comments and input to improve this draft Manifesto for Agile Governance are most welcome; and, in advance, many thanks…
Andrew Kallman and Ted Kallman are the co-authors of the Unified Vision Framework and their book, “The Nehemiah Effect” is a #1 National Best Seller on (in as many as 3 categories:  Business, Consulting and Project Management) for 4 of the last 10 months:
The Nehemiah Effect: Ancient Wisdom from the World’s First Agile Projects
Often companies are hesitant to get started with transitioning and/or transforming their Traditional Governance to Agile Governance since they’re unsure of where to start.  There are a number of paths that will get you to the same destination, but we have found the following format for the journey is most productive and beneficial:
1.  Begin with the Leadership Teams
  • Cascading Vision Workshop
    • This is designed to facilitate the Leadership Team in defining and agreeing upon the definition for each team member’s vision for their business and technology teams.
    • Half-day format
    • Facilitator-led, hands-on participative format
    • The output of this workshop are the visions that will be used to guide each of the Portfolios, Programs and Projects/Teams that work with each member of the Leadership Team
2.  Walkabout Workshop / Big Room Planning
  • After the Vision(s) is in place, the next step is to build the “big picture” by bringing all of the teams together to product the Portfolio View
  • Full-day format
  • Facilitator-led, hands-on participative format … includes both the Leadership Team and all teams involved in delivering the Portfolio
  • The output of this workshop is the big picture, i.e. Portfolio View
3.  The Cutting Room floor exercise / Portfolio Prioritization
  • Once the Portfolio View is in place, then the Leadership Team and Teams prioritize the work in the portfolio and create work in process limits for each Portfolio, Program and Project/Team
    • The Portfolio is balanced against the organization’s velocity using this exercise
  • Two-day format
  • Facilitator-led, hands-on participative format .. includes both the Leadership Team and all teams involved in delivering the Portfolio
  • The output of this exercise is the Prioritization of all work included for the Portfolios, Programs and Projects/Teams that is balanced with the existing organizational velocity
4.  Ongoing tailored solutions, including the training, coaching and mentoring of the Leadership Teams and all teams involved in delivering the Portfolios.
  • Tailored solutions for each organization’s specific situation, can include:
    • Structuring and/or setting-up an Agile PMO
    • Structuring and/or setting-up an Agile Governance Group (AGG) or Agile Transformation Group (ATG) – used in parallel with the Agile PMO
    • Refining and/or transforming the organization’s existing Governance meeting structure to an Agile Cadence
    • Creating the Agile Communication / Reporting dashboards
  • This step includes both longer-term implementations and health-checks on a regular cadence (when up and running with the customized solution that fits the needs and culture of the organization)
If you’re still unsure of where to begin, then contact Ted or Andrew to arrange for a customized assessment of your organizations readiness to implement Agile Governance.


As with all of our other blog posts previously shared on, these thoughts are Andrew’s and Ted’s and don’t necessarily reflect those of the Knowit Group, PMI, Scrum Alliance, Agile Alliance, etc.

Copyright © 1972 – 2015 Unified Vision Group all rights reserved – used with permission

Update:  Almost all tickets for this event are already taken, so if you’re planning on attending, then book your spot a.s.a.p. at the following link (this is a free event):

Topic: Beyond Budgeting

Beyond Budgetering handlar om att förändra hur vi ser på budgetering och budgetarbete idag. Istället för krävande byråkrati och styrsystem handlar det om att lita på människors förmåga att ge dem tid att reflektera, dela, lära och förbättra under resans gång – vilket leder till ett mer effektivt och relevant resultat.

Presenter: Stefan Ovemark, Senior verksamhetskonsult, Knowit Decision

Stefan Ovemark har över 10 års erfarenhet av att införa systemstöd för budgetering. Han började som controller 2001 och har sedan dess arbetat både i linjen och som konsult i gränslandet mellan ekonomi och IT. De senaste åren har Stefan varit involverad i stora projekt på bland annat bank, försäkring och ett av Sveriges största sjukhus.

PDUs: 2
Light Lunch included (many thanks to Knowit Decision for sposoring today’s lunch!)

See you there!

For those that are tracking this blog, the next Agile Governance Community of Practice – Sweden even is on 29 January and there are only a few tickets left.  Register here on Eventbrite.

Topic: Agile Governance – Focus Led Organizations with Vision (FLOw Vision)

Presenter: Andrew Kallman
Becoming agile at the program, portfolio, C-suite and Board levels begins with having a shared (and agreed upon) Vision. Achieving the Vision to be agile is a journey that can be challenging for many organizations. One of the keys to success is understanding whether your organization is synchronous or asynchronous not just in its culture, but also in its organizational structure.
In this presentation / workshop you will learn how to successfully use the UVF (Unified Vision Framework), VSPT (Vision, Strategy People and Tasks) and 4D Model (Define, Distill, Deliver and Drive) to create a truly Agile culture at all levels in your enterprise.

PDUs: 2
Please note that the time for this workshop is from kl 14 – 16 (coffee and water will be available).

Helia Conference room at Knowit Group
Klarabergsgatan 60, 4th Floor
Stockholm, Sweden

Look forward to seeing you there.

Update:  This event is sold out.
Waiting list tickets are available at the link below.
Thanks … and see you there!

Agile Governance CoP Idea

This concept is already proven and underway in West Michigan (co-sponsored by the PMI West Michigan chapter), USA, with over 50 PMOs and PPM leaders participating every month for the past year (2013 – 14).

Similar forums will be launched Q4 2014 / Q1 2015 in Stockholm, Sweden and Helsinki, Finland.

One of the key topic areas for the next 12 months (2014 – 15) is that Agile and Scrum are quickly getting to the point where scaling these to the Enterprise is a challenge for most Agile PMOs, Agile PPM and Agile Governance teams.

Why Agile Governance?

The challenges are similar for companies that are journeying down the Waterfall to Agile transformation path, or if it is a start-up that began as agile. Many PMOs and PPM programs are set-up in a traditional format and in many cases Agile Governance is completely absent. The number of PMOs that have been set-up in an Agile way, right from the start, are relatively few at the moment. So this forum addresses one of the hottest topics in Agile.

Other topics of interest and suggestions are welcome as well.  That’s one of the key value-adds of a self-organizing forum like this.

How the CoP works

The CoP is self-organizing and “self-funding.” We will follow the same pattern as the W. MI PMO CoP and here’s how it works:

  • Monthly networking meeting (lunch)
    • Except during July / Aug and Dec “vacation / holiday” months
    • Maximum of nine meetings per year (more likely five or six)
    • Find out what challenges other leaders for Agile PMOs / Agile PPM / Agile Governance teams are facing and how they overcome organizational obstacles
    • Discover best practice(s) – i.e. what works well and why did it work so well?
  • Each member company will have the opportunity to host the monthly meeting and has the following responsibilities / opportunities:
    • Provide the conference room
    • Provide lunch (first 30 – 45 minutes)
    • Take the participants on a tour (if possible) and/or give a short presentation (about 15 – 30 minutes) i.e. provide the Discussion Topic (either an Obstacle or Opportunity) for the meeting
    • Open Space / Discussion about the day’s topic (last 45 – 60 minutes of the meeting)

PDUs (Professional Development Units for PMI Members = 1.5 PDUs (Professional Development Units) per meeting.

Who Should Attend?

Directors of Business Management / Development
Directors of New Product Development
Portfolio Managers and Directors
Change Management Professionals
Release Managers
Release Train Managers
PPM Managers and Directors
Program Managers and Directors
PMO Managers and Directors

When and where will the first meeting for the Swedish CoP be held?

The kick-off for the Swedish CoP will be held on Thursday, 11 December 2014 from 11:30 am to 1:30 PM at (please register in Eventbrite due to limited space for this event – 27 places, total, including 4 internal participants – as 10 Dec 2014 this event is sold out!):
Knowit Group
Klarabergsgatan 60
111 21 Stockholm, Sweden
Light lunch included.
For more information or questions please contact (via email) Andrew Kallman, Partner, Knowit Group.
See you there!

The 22 Immutable Laws of Marketing, Published in 1993 by Al Ries and Jack Trout, could just as well be titled the The 22 Immutable Laws of Agile today, which is the title for this blog post.

Their book was released almost a full decade before the Agile Manifesto emerged and years before Scrum surfaced.  Agile thinking is catching up to what was already out there in many different formats and this is just one (very good) example that serves as an interesting template, both for Agile and Scrum in general and especially for Product Owners.

Our comments for each law are divided into two parts.  The first part is how the law applies in general to Agile and Scrum at the macro level. The second part is how Product Owners should be using these at the team, project and product level.  For a deeper understanding of this content, see link above to the the original laws.

1. The Law of Leadership: it’s better to be first than it is to be better.

In general:

Last we checked, “speed to market” is still one of the key benefits of using Agile. Microsoft is the master of doing this, i.e. 80% of the user stories being “complete” is usually “good enough” to hit the MVP, a.k.a. minimum viable product.  Bill Gates already understood this “Agile” principle with the development of MSDOS back in the 1980’s.  For example, back in the mid-80’s we assessed the capabilities of the four leading word processing systems at that time: MS Word, WordPerfect, WordStar and AB Dick’s proprietary word processing program.  Of those four, AB Dick was light years ahead of the competition in features, functionality and ease of use. However, Microsoft buried the other three with marketing leadership and not a superior product.

Up until Taylor and Rationalism appeared in the late 1800’s, the way work was done in the past was (many times) as clever and Agile as anything we have today.  We address that in our #1 Best Selling book on, “The Nehemiah Effect” where Nehemiah completed the walls of an ancient city (which easily could have taken decades, or more, to complete) in only 52 days.

Although Agilists weren’t first in the category for project management, they have been pretty effective, so far, with 20 of the 21 remaining laws of Marketing.  Agile consultants, booksellers and software companies have convinced a large number of prospects that Agile is the latest, hip and cool management methodology. And, in many cases, it is.

For Product Owners:

Every product owner should memorize this first law. We have observed a number of product owners during the past eight years agonizing over their MVPs. Experiment, release and redo … you don’t have to be perfect … you need to be lightning fast with the right team and right Vision to get your product into the hands of the customer as fast as possible.

2. The Law of the Category: If you can’t be first in a category, set up a new category you can be first in.

In General:

This is what both Scrum and Agile have done since neither were first in the Project Management space in 2001 when the Agile Manifesto was released. By doing so, they set-up a new category for Scrum and Agile thinking. However, what many people in the movement have missed (or don’t want to admit) is that Agile and Scrum are still part of the Project Management continuum:

Proj Mgt Continuum May 2014

For Product Owners:

Product owners should determine if their product is a “first,” or not. Ideas that seem fresh or new might already exist in the marketplace in other forms. Product Owners should create a “Continuum” for their product category to see where it fits and then, if their product cannot be first in its category, then create a new category.

3. The Law of the Mind: It’s better to be first in the mind than to be first in the marketplace.

In General:

As we shared above, Microsoft has repeatedly succeeded in doing this. Now, Agile and Scrum have everyone believing that they are the new methodology every business needs. And, in part, they are correct. Dr. Jeff Sutherland shared at a Scrum Gathering in Las Vegas back in 2013 that Traditional methods only succeed 14% of the time (based on numbers from the Standish Group), but that Scrum and Agile succeed 42% of the time. This should immediately place Agile “first in the mind” of many managers and Executives. Delivering on the promise is another discussion.

All successful project and process management (for those who like “flow” and “Kanban”) ultimately distills down to People and Tasks, breaking down the work to small enough chunks (i.e. work packages or user stories) to the task level. Empowering the right team, getting out of their way and letting them figure out how to get the work done is wise management, regardless of the label .

For Product Owners:

Product owners should implement a strategy to own “first place” in the mind of their stakeholders, prospects and customers. This is simple to understand. But it is not easy to do. It requires planning and execution at the highest level.

4. The Law of Perception: Marketing is not a battle of products, it’s a battle of perceptions. 

In General:

Perception is reality. The Agile and Scrum community understood this principle well and they have, during the past decade, shifted the perception of organizations in their favor. And, you have to admit they had a pretty easy target at which to shoot with the success rates mentioned above (where the project failure rates were at 86%). Even with this positive shift in perception an Agile transformation still requires internal proof that it will work.

The good news is that, led well, it does work.

One example in our universe that we heard about last week is a large non-profit that has (with Ted’s coaching and training) been slowly moving their IT department toward Agile structure and delivery. They went fully Agile in the last 90 days and the CIO stated “our overall production as a department has doubled and morale is sky high.” As a matter of fact, one item slated for delivery next March went live in their system last week. This is now rippling through the rest of the organization in a positive and powerful way making the perception of Agile very positive.

For Product Owners:

This is great news for Product Owners. Of course having excellent product is the goal and quality is always paramount but it’s more important that your prospect perceive that your product is good than whether or not it really is. With short-cycled, iterative and continuous improvements wrapped around a clear and compelling Vision you will be able to quickly create a positive perception of your brand and product. David Robertson and Bill Breen outlined how Lego achieved this in their book Brick by Brick.

5. The Law of Focus: The most powerful concept in marketing is owning a word in the prospect’s mind.

In General:

Here are some of the words from Agile and Scrum that are “owned” in the prospect’s mind:

  • Agile
  • Scrum
  • Kanban
  • Scrumban
  • XP
  • SAFe
  • Unified Vision Framework (UVF)
  • etc.

As you can see there is more than one word “owned” in the prospect’s mind in the Agile and Scrum category which has led to confusion. To us, Agile seems to be the umbrella word for the entire movement and so we put it at the top of the list. Also, we have coined the phrase “Business Agile” as a distinct category for our work using the UVF delivering Agile to the Senior Management and Executive levels.

However, from an “ownership-of-the-word-in-the-prospect’s-mind” perspective, there has been an epic failure on the part of Scrum and Agile. The movement founders failed to properly protect the word “Scrum” and/or “Agile” via IPR, Trademark or Service-mark. This basically means that anyone and their brother can now claim they are certifying “Scrum” or “Agile.” We will share more on this epic failure in the next law below.

For Product Owners:

Since this specific topic is probably not covered in the CSPO (Certified Scrum Product Owner) or other product owner certification training that is available on the market, it is incumbent upon every Product Owner to insure that their product, service and/or result has the proper legal protections in place for their IPRs (i.e. patents, trademarks, service marks, etc.) and for the “word” they are going to own in the prospect’s mind related to their product(s).

6. The Law of Exclusivity: Two companies cannot own the same word in the prospect’s mind.

In General:

Here are some of the “words” and acronyms that are owned in the project management category:

  • PMI owns “PMP” and is still the 800-pound gorilla in the project management category
  • Lean owns “Kanban” and a bunch of other Japanese words (does this lead to Muda?)
  • Agile Alliance owns “Agile Alliance” (ok, it’s two words, but close)
  • Scrum Alliance owns “Scrum,” or, is it that owns Scrum?  Actually they both do, sort of.

The “real” Scrum, in the Agile community, is actually divided between Scrum Alliance and since both groups are presenting themselves as “Scrum.” However, they did themselves no favors by splitting “Scrum” in the marketplace due to inter-Tribal issues.

To complicate matters even further, SCRUMstudy has now entered the training market with a PMI-PMBOK knock-off called the SBOK (i.e. Scrum Body of Knowledge). We found out recently that there is also an ABOK (Agile Body of Knowledge) as well. Andrew contacted both Scrum Alliance and regarding SCRUMstudy and they both informed him that they are aware of SCRUMstudy, but … and here’s the clincher … since SCRUMstudy is not infringing on either group’s trademarks, then there is nothing that they can do about the knock-off product. One that is suspect, at best, in its interpretation and presentation of “Scrum.”

SCRUMstudy found a legal loophole through which you could drive a bus.  The resulting confusion in the marketplace should be a concern to everyone that has a certification from either Scrum Alliance or since, if SCRUMstudy is even just moderately successful in its marketing efforts, this will potentially create confusion in the marketplace both for employers as well as individuals pursuing a certification.

And, a number of PMI Ethics violations has been lodged against both SCRUMstudy and it’s parent company (since the parent company of SCRUMstudy is a PMI REP and is bound by the PMI Code of Ethics).  The results of those cases with PMI are still pending.

For Product Owners:

Companies invest a large amount of money to “own” a word in the prospect’s mind and this topic is not covered in the CSPO (Certified Scrum Product Owner) training. Product Owners need to create and manage their product’s IPRs diligently and with great care, as mentioned in the previous law.

7. The Law of the Ladder: The strategy to use depends on which rung you occupy on the ladder.

In General:

A decade ago, Agile and Scrum were virtually unknown in the world of Project Management.  They executed their strategy so well that Traditional/Waterfall to Agile/Scrum Transformations are now just about the only thing that most companies are talking about and/or implementing as fast as they can. Agile and Scrum didn’t climb the ladder … by virtue of their success they took the elevator.

For Product Owners:

Product Owners would be wise to follow the trail of the leaders in the Agile and Scrum movement.  It is essential to know who your competitor is.

8. The Law of Duality: In the long run, every market becomes a two horse race.

In General:

Based on current trends, it appears that the two horses in the project management race will be PMI and the Scrum Alliance.  Some might even suggest that PMI is already behind the trend-line.  For example, attend any PMI meeting and you’ll be hard pressed to find anyone under 40 years old. At the same time, if you attend a Scrum Gathering, the average age is probably around 28 years old and finding someone from the over 40 crowd can be a challenge.

For Product Owners:

Product Owners need to understand that if their product doesn’t have any real competition then the odds are pretty good (unless it is a new market like iTunes) that they probably don’t have a viable product.

9. The Law of the Opposite: If you’re shooting for second place, your strategy is determined by the leader.

In General:

Agile and Scrum haven’t been shooting for second place.  They have considered themselves the leader of a new movement right out of the gate.

Surprisingly, PMI has been behaving in such a way that, although they are still the number one project management association in the world, in some ways they act like they were in actually in second or third place. The clear example of this is to do a search on for jobs requiring or preferring “PMI-ACP” (as of today there were 332) versus doing the same search using “Scrum” (that resulted in 532,044 “Scrum” roles).  The PMI-ACP has been marketed strongly for two years but these numbers speak for themselves.

To be fair, as of today, there are also 831,567 jobs requiring or preferring “PMP” so the PMP certification is still the market leading certification and the most highly valued certification.  But, it is not an Agile designation and the PMP is considered by many in the Agile movement to be anti-Agile. As PMPs, we can assure you that there are many of us that are as Agile as (or more Agile than) the Agilists that don’t have the PMP. In some respects it depends on your definition of “Agile” but we will let our customer results speak for themselves.

For Product Owners:

As Product Owners, if you are working in the area of new product development, then shooting for number 2 might seem odd.  Everyone wants to be number one, right?  It depends.  Here are some examples to consider:

  • Coke
  • Pepsi
  • Who’s number 3, again?

And, a couple more:

  • McDonalds
  • KFC
  • Who’s number 3?
  • Burger King, by the way, is in 6th place on the Forbes List

So, a product owner needs to clearly define the Vision and Strategic placement for their product.  Understanding who your competitor is will help you create a viable product.

10. The Law of Division: Over time, a category will divide and become two or more categories.

In General:

We sort project management methodologies into three broad categories:  Traditional, Lean and Agile & Scrum:

Proj Mgt Cont w UVF Safe and M30

  • Waterfall was the standard during the 1970’s and 1980’s
  • By the 1990’s Lean had appeared
    • By the way, we were already using Theories of Constraints (ToC) in project management by the early 1990’s and we integrated those ideas into the UVF (which began as “the Model” and that has been in continuous use since 1972)
  • Scrum and Agile were only just beginning to emerge and were formalised in the beginning of the 2000’s

As we’re showing with the picture above, the additional sub-divisions in thinking begin to occur in order to meet the needs of the market.

Recently Andrew read a Kanban book from a hip, cool and often-cited company.  It was surprising that there was literally nothing new in that book about lean or kanban that he hadn’t already been taught back in his MBA program in 1993, over twenty years ago.  Agile and Scrum are actually playing catch-up with what was being taught as management thought leadership in the 70’s, 80’s and 90’s.

Another example of this that Ted recently found is the book “The Leader of the Future” published in 1995 by the Drucker Foundation. Over and over in the essays from world-class leaders they talk about ‘empowering’ teams and ‘leadership rising from within’ verses directed from above. Ken Blanchard’s essay states it this way:

“We can’t have one group coming up with the vision, the values, and the direction and another group implementing them. Although the vision has to start at the top of an organization, everyone must be able to provide input and at least buy into that vision and direction. And once people know where they are going, top managers cannot divorce themselves from the implementation process. They have to get in and roll up their sleeves and be facilitators, cheerleaders, and supporters of getting the systems, the strategies, and the behaviors in line with that vision.”

This is a great description of a Business Agile mindset published six years before the Agile Manifesto.

The categories of Waterfall and Lean have been further divided into Agile and Scrum. PMI’s version of Agile (the PMI-ACP) is a shotgun approach while Scrum’s approach is a rifle shot.  We believe that the rifle shot is more effective as long as the target is clearly defined and sighted.

For Product Owners:

Product Owners can leverage this law for their product, service or result to identify potential new categories that they can create and in which they can be first.

11. The Law of Perspective: Marketing effects take place over an extended period of time.

In General:

Scrum is so “new” that its overnight success has taken almost 20 years.  Agile as a descriptor is also just a little over a decade old at this point in time, so its “instant” stardom has taken time as well.  By the way, how you define a “project” is relatively important since we’ve heard on numerous of occasions that teams don’t do projects anymore in Agile or Scrum.  We don’t agree.  Here’s the traditional definition of project from PMI’s PMBOK Guide 5th Edition:  

“A systematic series of activities directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs.”

Sounds like the definition for a Sprint or Iteration to us.  Basically, a project is a group of tasks that need to be completed and that have a clear start and end date … that’s a project.  If one accepts these definitions for a project, then every Sprint in Scrum can and should be defined as a “project.”

For Product Owners:

As Product Owners are taught in the CSPO training, the life cycle of the product is much longer than the life cycle of a “project.”

12. The Law of Line Extension: There’s an irresistible pressure to extend the equity of the brand.

In General:

In the end, it really begs the question:  What is Scrum?  By the time companies “adapt” Scrum or Agile to fit their particular company culture, the end result can look quite different than what was probably intended by Scrum purists.

Agilist’s love to quote Deming’s “plan–do–check–act” (PDCA) cycle. But, if you follow this to its logical conclusion, there is a big risk that due to company culture or other constraints that the resulting Scrum or Agile no longer follows what is recommended by purist Scrum or Agile coaches. Some variants are:

  • Scrum + Internal Processes = “Scrumbut” (i.e. “we’re doing Scrum, but…”)
  • Scrum + Kanban = Scrumban
  • Agile + Kanban = Agileban
  • Waterfall + Scrum = Water-Scrum-Fall.

 For Product Owners:

Product Owners should resist the urge to extend the brand for their product.  This has been shown to decrease the value of the product over time, but companies do it anyways.  It’s an anti-pattern that should be avoided at all costs.

13. The Law of Sacrifice: You have to give up something to in order to get something.

In General:

Pre-Active Vision is understanding how to leapfrog your competition.  Agile and Scrum did exactly that by recognizing that hierarchical command and control was not working and that the best ideas are usually generated at the point of delivery and not from the top down. A system was developed that defines and keeps the vision and highest priorities visible and continuously re-groomed. It empowered people and teams to be transparent and accountable in small, rapid iterations while innovating at the team level at the point of need. Upper management has had to ‘sacrifice’ control but the results have been and are still impressive.

For Product Owners:

A good Product Owner will be able to exploit this law when launching their product, service or result.

14. The Law of Attributes: For every attribute, there is an opposite, effective attribute.

In General:

We mentioned this above, but worth looking at it again here:

  • Traditional – slow, ponderous, long cycles succeed only 14% of the time (i.e. an 86% failure rate)
  • Agile / Scrum – fast, nimble, succeeds 42% of the time (i.e. three times better than Traditional, but still a 58% failure rate)

For Product Owners:

If a Product Owner is using Epics, Features (and/or sub-Epics) and User Stories to manage the various backlogs at the Portfolio, Program and Project levels, then this law applies.

15. The Law of Candor: When you admit a negative, the prospect will give you a positive.

In General:

There are no silver bullets.  This is a classic line in almost all Scrum and Agile literature and training.  And, it is a perfect example of this law in action. This could also be seen as a team level result when management admits that the as-is state is not working well enough (admitting the negative) and allows an Agile experiment. The teams respond with exponential effort and result.

For Product Owners:

Product Owners can use this law to effectively mitigate the “negative” features of their product, service or result.  Listerine (a mouthwash brand in the US) are masters at this:

it tastes so bad it has to be good…

16. The Law of Singularity: In each situation, only one move will produce substantial results.

In General:

“When the culture doesn’t fit Agile, the solution is not to reject Agile. The solution is to change the organizational culture. One doesn’t even have to look at the business results of firms using hierarchical bureaucracy to know that they are fatally ill. In today’s marketplace, they will need to change their culture or they will die. They need to become Agile.” From Jeff Sutherland’s blog post.  The speed at which business and technology is changing demands that organizaitons adapt in different ways. Agile has proven itself over the past 20 years so Jeff’s statement is right on point. This is one of the strongest arguments out there for helping companies understand the need to go Agile.

For Product Owners:

Product Owners probably aren’t taught this.  This is the realm of strategic leadership in marketing and in part why the continuous re-grooming of the Product Backlog as new information emerges makes Agile so powerful as a tool.  This is also why speed to market is essential for survival.

17. The Law of Unpredictability: Unless you write your competitor’s plans, you can’t predict the future.

In General:

This is why experimentation, adaptation and speed to market are key to survival.  Scrum and Agile failed here since SCRUMstudy has clearly taken them by surprise.  It is very tough to predict the future.  Also, it was a mistake for the leaders to assume that everyone has the same “Agile” values and attitudes that they have.  This was a little naive.  An Entrepreneur always includes in their plans the way that they will both protect and share their IPRs.

For Product Owners:

Product Owners should have the ability to write a good marketing “plan” on a single page. The US Military calls this the ‘Commander’s Intent’.  If this work has not been done, then the Product Managers or Business Owners will have to do it.  Companies should strive to eliminate as many multi-page plan templates that they can.  Reducing the paperwork is one way to eliminate waste, since most of the 50-page “plans” in the Traditional world were wrong 100% of the time anyways.  But, Product Owners still need to have clear guidance on how to interface with the organization’s Governance.

18. The Law of Success: Success often leads to arrogance, and arrogance to failure.

In General:

Agile and Scrum have had some CSTs and other leaders that have communicated in a rather arrogant way towards the management and leadership of organizations (that will be the topic of a future post), so the danger signals are there for future disruptions in the movement.  The demise of Nokia’s mobile phone division is a perfect example of that.  Most people are not aware that Nokia had a touch-screen phone prototyped and ready for production already in 2004 (well before Apple launched the iPhone).  The Board of Directors decided to kill the project since they felt it was too risky to launch the product.  The rest is history and Nokia’s arrogance lead to failure.

For Product Owners:

Product Owners will need to work extra hard to help themselves and their teams to stay humble.  It’s hard not to become a little proud when you’ve really delivered a “home run,” though.

19. The Law of Failure: Failure is to be expected and accepted.

In General:

One of the quotes Andrew came up with about eight years ago is “Agile/Scrum helps you fail faster … and that is a good thing.” Agile is all about getting rid of projects that will not deliver value.  Failing faster helps you do just that. It also shows why the ‘cage fight’ that forces prioritization is so important. There is no room in today’s environment for sacred cows. Everything should be on the table, prioritized and re-prioritized on an ongoing basis.

For Product Owners:

Product Owners should have sufficient empowerment and latitude so that any project or product failure will not be “punished” by the leadership of the organization.

Edison failed over 1,000 times when he invented the light bulb.  Michael Jordan summed up success this way, “I missed 9000 shots, lost almost 300 games, missed the game winner 26 times. I’ve failed over & over again; that’s why I succeed.” That’s the heart and soul of Agile and Scrum!

20. The Law of Hype: The situation is often the opposite of the way it appears in the press.

In General:

There are a ton of cool companies out there that are hyping their prowess and success in using Agile.  It is crystal clear that if we were able to look behind the curtain we would find all of the same issues and problems that any other non-Agile start-up experiences when going through the maturity life cycle.  Since many of them have gone public, they will never publicly admit this but they are struggling with scaling, leadership and maturity issues.

For Product Owners:

Product Owners need to resist the urge to use hype as a tool.  It takes a high level of discipline and self-awareness to avoid doing that.

21. The Law of Acceleration: Successful programs are not built on fads, they’re built on trends.

In General:

This is one of the keys to Scaling Agile to the Enterprise.  An Agile PMO in combination with either an AGG (Agile Governance Group) or an ATG (Agile Transformation Group) are the tools to create, measure and report back to Senior Management the trends for each program and portfolio.  This is exactly how we doubled the throughput in 2.5 years at NPG without adding resources.

For Product Owners:

Product Owners should understand the trends not just for their product, but also for the development of their product.  The teams need to be tracked using a common KPI in such a way so as to not disturb the culture of the team, but at the same time to be able to help the team reach a level where it is high-performing.

22. The Law of Resources: Without adequate funding an idea won’t get off the ground.

In General:

Agile and Scrum help an organization kill bad projects sooner (see 19 above).  One thing that the Scrum/Agile purists have missed is the “Golden Rule: he who has the gold, rules.”  Unless a team is self-funded, then they will not be truly, or completely self-governing.  Someone, somewhere is footing the bill.  Ideas are a dime-a-dozen.  The latest emphasis on innovation is rather puzzling since entrepreneurs have been innovating quite a bit for the last 150 years.  Money talks, everything else walks.  We address this point more fully in our last blog post, Agile Coaches Can’t Scale.

For Product Owners:

It is the person that controls the budget that is the ultimate stakeholder for the Product Owner, ScrumMaster and the team.  Product Owners have to make sure, in conjunction with the ScrumMaster and Team (since the “project management” function is divided among those three roles) that the product, service or result are still delivered within the constraints of the budget and time.

It is amazing to us that a classic like the 22 Immutable Laws is still relevant over two decades later.  For as much as we change, there are an awful lot of basic, business fundamentals that remain the same.  And, it still holds true that if you violate them, you do so at your own risk.

WARNING!  This blog post will probably offend most Agile and Scrum purists.  Also, as with all of our other blog posts, these thoughts are ours and don’t necessarily reflect those of the Knowit Group, PMI, Scrum Alliance, Agile Alliance, etc.

Arthur Shopenhauer, a 19th Century German Philosopher (nicknamed “obstinate” by his detractors), once said,  “All truth goes through 3 stages. First, it is ridiculed. Second, it is violently opposed. And third, it is accepted as self-evident.”

But, with those disclaimers, the time has come for transparency for some of the challenges companies are facing when trying to Scale Agile.  One assumption many companies have made is:  if Agile Coaches helped us become successful at the team level, then it follows that they should be able to help us scale Agile to the Enterprise level.  That assumption may be, and is usually is, in our experience, wrong.  This is true even for companies that have started out and remain Agile.

Just because an Entrepreneurial start-up has been successfully using Agile from its beginning does not exempt it from basic business principles that apply to scaling all successful businesses.  

As companies grow, suddenly what worked when they had five teams no longer works with 100 teams.  This is especially true from a governance perspective.  It’s fairly easy to manage Tribes, Guilds, Scrum of Scrums, etc. when a company is small.  To assume that you can successfully scale start-up culture and processes to the Enterprise level is naive and potentially fatal.

At some point in time the Tribes need to become a Nation.

To do that, you need to have effective and focused Agile Governance for the Enterprise.  If we were allowed to look behind the curtain of many Agile start-ups, we suspect that we would find a different picture that what is reported in the media.  It reminds us of law 20 from the book “The 22 Immutable Laws of Marketing” (by Al Ries and Jack Trout, 1993) which had this to say about what you read in the news:

20. The Law of Hype: The situation is often the opposite of the way it appears in the press.

No Agile start-up will ever publicly admit, particularly if they are publicly traded, that they are having troubles scaling Agile as they grow into more mature and larger organizations.  As we pointed out in our last blog post, one of the primary issues that Agile start-ups face as they grow is that they are now dealing with a completely different kind of professional stakeholder who speaks an entirely different language and has a completely different set of expectations. In many circles we call these stakeholders “Executives:”

Languages of Leadership and Management

The language difference between Management and Executive leadership usually comes as a shock for the Agile and Scrum purists.  They assume that success communicating at the management and team level should automatically translate into success communicating with the Executive level without any accommodation for the tribal differences.  They also firmly believe that the same tools and methodologies used at the team level will work at the Executive level.  We have observed that trying to force feed Scrum to traditional Executives generally ends badly.

It takes an Agile professional who possesses a high level of business acumen and maturity to be able to speak the Executive’s language.  It is even better if you can find an Agile professional who has been part of that tribe, i.e. one with Executive experience. Anyone who has worked at the C-level has already learned, and acknowledged, that a pragmatic, methodology agnostic approach is a more successful way of working.  By the way, the Agile and Scrum purist’s “force feeding” mindset (that Scrum / Agile can only be done one way, regardless of its audience) strikes us as unusual, especially from a group of people that pride themselves on quickly adjusting and adapting to reality.

Up to this point, some of the people reading this blog post will already be responding with ridicule and disdain. Others may even be responding in violent opposition to what we’re saying (and are already flaming us in the comments section below).  But our intent is to try and explain what we have found to be self-evident when successfully Scaling Agile to the Enterprise.  So, before getting all riled up and shooting the messengers, please follow our observations all the way through to their final conclusion.

When talking about Agile coaching, or team facilitation, it’s appropriate to be aware that almost all Agile literature and training is targeted at the individual and team level.  This doesn’t make it bad, but it also doesn’t make it effective when trying to execute Agile in the Executive suite.

What this means in practice is that a majority of Agile Coaches can’t scale and probably shouldn’t.

Yes, we know it’s not fair or accurate to lump all Agile Coaches together (as we stated in our last blog post on Enterprise Governance for Agile) since some Agile Coaches actually have the experience, education and skill to be able to scale Agile.  The rest of this post is about why the above quote is true for the vast majority of Agile Coaches with which we have come in contact.  It seems that many of the Agile Coaches themselves have missed a key point from title of the Agile Manifesto:

Manifesto for Agile Software Development” 

By definition, “Agile,” as described (and limited) by the Manifesto, is only for software development.  It was not originally intended for the entire organization.  That doesn’t mean that Agile’s Values and Attitudes cannot be used in other areas.  But, it does mean that the signers of the Manifesto understood the constraints of software development in context and relationship to the rest of the Enterprise.  There are examples of organizations that use Scrum and Agile for the entire enterprise:, F-Secure, etc.  However, the number of organizations that are struggling to scale Scrum and Agile far exceed the examples of those who have succeeded.

Most Agile Coaches and ScrumMasters are all about working with and facilitating teams (and individuals) with the goal of getting the teams to become high-performing.  This is part of what makes Agile and Scrum so effective.  And, Agile Coaches are taught to “lead” (train, coach and mentor) from the back of the room, as they should.

For example, Lyssa Adkins book, “Coaching Agile Teams,” has entire chapters on the coach as a mentor, facilitator, teacher, problem-solver, conflict navigator and collaboration conductor.  Another example is Sharon Bowman’s “Training from the Back of the Room,” which is the required course and book for anyone seriously considering becoming a CST (Certified Scrum Trainer).

These courses and books are both focused on training individuals and teams, not executives.

It has been our observation, however, when working at the Senior Manager, Executive and Board levels, it is an absolute requirement that a project, program and/or portfolio leader has Executive-level “room presence.”  Most of the Agile Coaches that we have observed in action don’t possess the room presence required to effectively communicate to and interact with Executive leadership.  This should not come as a surprise since they’ve actually been trained to do the opposite (to lead from the back of the room).

Assuming that all of the above statements are true, and even if an Agile coach has Executive level experience and/or “room presence,” we have witnessed a deeper, more fundamental problem within the Agile community that is blocker to effective scaling.  The following quote from a well-known Agile Coach captures the essence of this problem:

Management is the source of all Evil in the world.”  

Let’s be a little blunt here:  this is only true in the land of Dilbert.  Every organization has a pointy-haired boss lurking in the org chart.  However healthy, mature and growing Enterprises do not hold or share this errant belief.  Further, Agile and Scrum “purists” with this attitude have not done themselves (or the Agile Community at large) any favors by blaming all Agile transformation, transition and governance difficulties on the management and leadership of the Enterprise.

This is biting the hand that feeds you and also does not end well.  Worse, it blocks the ability of the organization to migrate to an Agile culture and many times kills the transformation effort.

Why is that?  It’s because, as we pointed out above, the language of Enterprise leadership is different than the language of management, Agile or otherwise.  I (Andrew) have a perfect example of this from last November when I had the opportunity to attend meeting for an Agile consulting company (that has both Agile Coaches and Agile Management Consultants).

The most fascinating, passionate discussion I’ve witnessed, so far, in my Agile journey, erupted during the course of this meeting.  As we shared in the quote above, one of the Agile Coaches had a complete meltdown during the meeting and literally blamed “ALL Evil in the entire world on ALL management consultants, managers and executives.”  Extreme? Yes. Unusual? Not so much.

Agile Coaches tend to ferociously fight to “keep a space for Agile and Scrum” (as they have been taught to do).  However, the most fascinating and rewarding part of the meeting was when the CEO of the company challenged and rebuked the riled-up Agile Coach with the following response in front of all of the other Agilists and Management Consultants in the room:

Frank*, by definition, if we are doing Agile consulting with the management of a company, then we are “Agile” management consultants.

*Note:  name changed to protect identity of the Agile Coach.  

The crimson-faced Agile coach sat down and the meeting continued.

Later in the same meeting, on a flip-chart, the President of the company had drawn a matrix with each of their products and services that they offered their clients.  The horizontal swim lanes were sorted by Portfolio, Program and Product, Project and Team and Individual Team Member levels; and, the vertical swim lanes were a categorization of their products and services.  ALL of their “Agile” products and services were aimed primarily at the Project, Team and Individual levels.

However, at the Program, Portfolio and Executive levels they had little or no product offerings.  No surprise there, either.  The “Agile” offering from almost all companies at the Executive level is fairly thin.

Why is that?  Because Agile has been aimed at optimizing the team (and by extension, individual).  I went up to the flip chart and drew two boxes around his Product / Service offering matrix that looked like the following:

Typical Agile Product Offering

A hush fell over the room as the idea of of the two languages sunk in and as they understood that Agile, for the most part, had ignored the leadership and governance levels.

Agile purists, like the Agile Coach above, have done a superb job of alienating almost everyone from the middle management level on up through the Executive team.  Worse, that particular coach wore it as a badge of honor that executives refused to meet with him; or, in the cases where they did, they never invited him back to another leadership meeting, ever.  This is because Agile purists speak a language that is foreign to the pragmatic leadership of the organization and because they have a value-set that is not aligned with the Executive level.  It is possible to preserve a “space for Agile and Scrum” without being offensive, arrogant and demeaning.

If at the team level 80% of all project management is communication, then working with the higher levels of an organization is 100%.  If Agile Coaches view Senior Management, etc., as the source of all evil, then that unprofessional attitude will be communicated loud and clear to those Stakeholders.  That is not a good thing.  It is truly a very unproductive anti-pattern.

People seem to have forgotten a well-know version of the golden rule:

He who has the gold, rules…

Everyone working on an Agile or Scrum project is accountable for the budget entrusted to the team.  If the team is not self-funded, then they are not truly self-governed.  If they’re not paying their salaries out of their own pockets, then they are financially accountable to the company and Executives that are.

Their mission is to deliver an increment of value to the Product Owner who is the voice of the Customer.

Sitting around in a circle, holding hands and singing “Kumbaya” just isn’t going to get a team very far with a group of jaded, “show-me-the-money” investors, Board Members and/or Executives.

So far we’ve looked at the “new” Golden Rule, the different languages used by Executives and Managers, the training Agile Coaches receive along with some aberrant attitudes and values that don’t win any friends with Executives and Upper Management, etc.

As we mentioned earlier, some Agilists have actually started to understand some aspects of successful scaling.  For example, at the Scrum Gathering Las Vegas (SGLAS 2013) I (Andrew) had the privilege to participate in a workshop facilitated by Lyssa Adkins and Michael Spayd on the Windows on Transformation: Four Pathways to Grow a More Agile Enterprise (the “I, We, It and It’s” 4-box applied to Scrum and Agile).  The model Lyssa and Michael used does a good job outlining the “who?” and the “what?” when scaling Agile to the Enterprise-level:

Windows on Transformation

There are additional items that they addressed in all four areas above, but those didn’t really give a crisp understanding of “how” to implement in each of the 4 areas.

While on the surface it would make sense and appear that teams should be able to organically scale using “team” Agile (from the “We” quadrant), the reality for most companies, even for those that started out Agile, it is quite the opposite.  There are organizational dynamics that “team” Agile is not equipped to manage … nor should it try.  See our recent blog post on “Agile Can’t Scale: Fact or Myth” for more on that.

Assuming that Team Agile, facilitated by Agile Coaches, will automatically translate to the Enterprise level has been a painful experience for many companies.  It’s not a question of Agile Coaches being able to understand the idea or principles of scaling.  It’s a question of battle scars, skill and demonstrated previous success in scaling Agile.  The universe of people that have “been there, done that” is rather small.  That is why a methodology agnostic Business Agile framework, like the UVF, is absolutely crucial for creating an organizational culture that facilitates Agile in all quadrants:

Windows UVF Aligns Implements All 4


The UVF works, and is powerful, because it continuously and iteratively communicates and focuses the “Vision” in all four areas and keeps it aligned at the Team level while you implement Business Agile.  The UVF is a simple, effective way to break through organization language barriers and get everyone on the same page.

But, frameworks don’t implement themselves.  And, there are no silver bullets.

Implementing Scaled Agile requires skilled people that know how and when to use the right tool for the right situation. During the past 2 decades, we have found that the Business Agile UVF with the VSPT, 4D and 4R Models will focus your organization to optimize all four areas, the “I, We, It and Its” that all Enterprise Agile must address.

Agile Coaches that only have a software development background usually do not have anywhere near the education, business experience and/or skills at the Executive level to deliver what is needed.  Hoping your Agile Coaches, using an organic “team” Agile approach, will get you to Enterprise “scaled Agile” simply won’t cut it.

You cannot scale an Enterprise from the bottom up only.  You scale from the top and bottom, simultaneously, using Vision.