“An Expert is someone who carries a briefcase and lives more than 50 miles away” Professional Consultants Association website.

This is an old joke that I have heard many times over the years and has a degree of truth in it. But there is a dark secret to expertise that lingers inside most organizations – Experts are the people we trust to say no.

What does this mean to Agile or Scrum environments?

We need the right people with the right ideas (see the 4R Model at the end of our blog post from last June 2014 on how to implement Management 3.0 using the UVF) and expertise on the team to be able to deliver the hoped for value as determined by the organizational Vision and Strategy as filtered by the Product Owner.

So why do we need to eliminate ‘experts’? Because deferring to an expert usually ends debate, innovation and creative thinking.  There should not experts on an agile delivery team – only team members who are there to understand, deliver value and find ways to overcome the obstacles to that end result.  A person with history and wisdom in an area of expertise should be listened to carefully.  But, a high performing team does not allow that one opinion to end discussion or ideation toward a better path.

Henry Ford understood this. Peter Diamandis in his recent book “Bold” quotes Mr. Ford on page 112:

“None of our men are ‘experts’. We have most unfortunately found it necessary to get rid of a man as soon as he thinks of himself as an expert because no one ever considers himself an expert if he really knows his job. A man who knows a job sees so much more to be done than he has done, that he is always pressing forward and never gives an instant of thought to how good and how efficient he is. Thinking always ahead, thinking always of trying to do more, brings a state of mind in which nothing is impossible. The moment one gets into the ‘expert’ state of mind a great number of things become impossible.”

In other words, Mr. Ford had an Agile mindset and expected his team to have the same mindset or he removed them from the team. Exponential results followed.

An example in our experience will be a case study in our soon to be released book ‘Flow: Beyond Agile’. The project started with our brother Dan. At that time Dan was an IT manager for Steelcase, a multi-billion dollar furniture manufacturer, the largest in the world, in Grand Rapids Michigan. Dan’s development team was working on a Sales Force Automation tool to deliver cost data to the field in real time to facilitate better pricing for competitive edge.

The team had reached a point where they needed to aggregate data from a number of locations within a very diverse data universe in order to obtain and deliver it to the field sales force in a usable form. All of the ‘experts’ from the large companies assisting in the project said it could not be done and counseled Steelcase that they should abandon the project as a failure. These included; IBM, Hewlett Packard, Anderson Consulting (now Accenture) and Oracle.

Dan’s team did not include anyone who would be considered an ‘expert’ by these consultants so their opinion held little weight with upper management. Dan did not believe the facts as delivered by the experts and stated:

“it is not impossible; you just don’t want to try.”

One of the experts from Accenture said:

“if you think you are that good why don’t you do it?”

So Dan gathered his merry band together and in Apollo 13 fashion said:

“Guys, this is what we have to work with, failure is not an option.” Well, what he actually said was, “If we cannot pull this off the project is dead and our company will have lost US$ 4.5MM in the failure and without any the future benefit that this tool could deliver. We need to find a way to do it.”

You get the point.

They went into ‘skunk works’ under the radar mode and started to look at alternatives and ideated over and over for a number of days.

Now, before we reveal the result, you need a little more of the back-story.

Dan’s team had wanted to take the tool logo (IT) and have it spin when the tool was processing instead of the standard spinning arrow. This had no value to the end product and would not have been approved if Dan had requested it as a feature but he knew his geek squad wanted to do it because it was cool and they thought they could. He gave them two days to do it. (Google, which formed a couple of years before this event, gives employees the freedom to use 20% of their time on anything they choose to do, and it was that type of moment for Dan’s team).

They did not fully pull off the spinning IT within the two-day “hack event.”

Ah, but during the ideation session to save the SFA project, one of the Developers brought up one of the things they had attempted when trying to make the IT logo spin and suggested that they use the same approach to aggregate the data.

Everyone agreed.

They tried it and it worked. The impossible became possible. The team hired me to do the roll out and training and then we brought Andrew in on the service side. (Yes there were multiple jokes about entirely too many Kallman’s in one place at one time – the universe has still not yet fully recovered).  You can read about the whole story in Flow when it hits the street later this year but the net/net value delivered to Steelcase after one full year of implementation was US$ 29.5MM of profit according to their internal audit team. Not bad.

So how does this relate to Agile and experts?

Use expertise to place a person on a team but do not let their expertise block creative thinking and innovation. The ‘all for one and one for all’ culture in Scrum and Agile leaves to door open to all ideas and does not allow experts to kill them. And, short cycle testing of ideas along with retrospectives that assess what worked, and what did not work, keep the team growing. This growth increases expertise even as it eliminates individual experts (except as a team contributor).

Last thoughts.

One of the big challenges we face when coaching Enterprise Level Agile adoptions is the split use of experts over many teams. The rationale is that these critical resources are needed so that the organization does not make mistakes, or go down dead-end paths unnecessarily.

We believe that an expert should be on one team only and that if needed to consult with another team on a short term basis it is with a laser focus burst and then they return to their own crew to deliver value going forward.  This is not normal in most corporate structures. When you split the time of an ‘expert’ it mitigates against high performance for the individual, the team and thus the organization as well. It is an anti-pattern.

One of the other hurdles that needs to be overcome at the executive level is the elimination of silo-controlled expertise in executive decision-making.  Executive teams must be cross-functional and operate as equals within the team structure, just the way a Scrum team functions.  This is not easy and can be a critical point of failure in an agile adoption.  It requires a major cultural shift to succeed.


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 Amazon.com (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

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 Amazon.com (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 Agilean.se, 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 Amazon.com, “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 Scrum.org that owns Scrum?  Actually they both do, sort of.

The “real” Scrum, in the Agile community, is actually divided between Scrum Alliance and Scrum.org 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 Scrum.org 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 Scrum.org 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 Simplyhired.com 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.