“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.
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).
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: