That training is given by people who have never been involved in the kanban community and who may be offering substandard guidance. There is a need for quality standards so that people who pay for kanban training know they will walk away with useful information they can apply in their organization. Software Development Times, Kanban Development, May 2012.
I love kanban. I also fell in love with scrum some years ago. Their appeal is that they emphasize many of the good things that have worked well for me over the years. It helps when working with an organization to be able to say “give scrum a try” or “you may want to consider trying kanban” because I know that when they dig into them, they’ll be exposed to many good ideas and approaches.
However, I’m not an expert in either scrum or kanban. I’ve not written a book nor have I taught a class. I’ve not specifically implemented any of these technologies nor have I managed a group or project that directly used these approaches. Obviously then, I can’t talk about any of them because I don’t have any expertise or experience.
Actually, that is true for just about every successful project I’ve ever delivered and every successful organization that I’ve ever led. I was not an expert in that domain, industry, technique, methodology, technology, etc., until after we were done. Done and successful. Done and successful far beyond what those organizations had achieved in the past (at least the recent past, but often in the collective memory of the organization).
To put it bluntly, being an expert can be highly overrated
To put it bluntly then, being an “expert” can be highly overrated. I can’t count the number of “experts” who pitched or implemented “improvements” in our organizations whose only apparent expertise was getting the company to pay them money over months and years. Measurable results were pretty much non-existent.
In one organization we were paying a well known consulting firm $1 million a year to help us improve our software development, maintenance and acquisition projects. The core strategy was to move our very large and diverse organization up to using best practices and methodologies throughout these development processes. This contract had been in place for some years before I joined the organization.
About every six months we went through a new reorganization and revitalization of our efforts to improve. The consulting firm kept telling us what we were doing wrong, what we needed to do to improve and providing us training. We formed committees, called meetings, wrote new procedures and policies, set goals, created implementation plans, gave powerpoint presentations, and watched as nothing really changed over the years (except terminology it seemed — we could sure talk the talk). We kept doing what the experts assured us had worked in their other engagements, but it didn’t seem to do anything for us. We finally disbanded our special project office that drove this effort for years but we kept the $1 million a year contract because we were still determined to improve, and they were the experts we obviously didn’t have.
From the break-up of the project office, I formed a small team of four whose stated purpose was to help development teams to implement selected new technologies (e.g., metrics, new development tools, research, estimating, etc.) We had a grab bag of “things we need to do” that had been given to us because they didn’t seem to fit anywhere else (or no one else wanted them). One thing we were not given was the original core improvement goal of moving all development up to the next level of management and development best practices (in this case, based upon the SEI CMM).
To make a long story short, based upon the inspiration to provide a service rather than “implement a project,” the organization achieved its certification at operating at the next level of management maturity (i.e., the next SEI CMM level) in about 18 months. This was after years of trying, with a much larger team, and that $1 million a year consulting contract. Oh, and those $1 million a year consultants cheered us on at the end and thanked us for allowing them to finally achieve their contractual obligation. No, they were not involved in the effort nor even aware it was happening until it was clearly showing results.
For more see Don’t Project Manage Change — Provide A Service!
We became experts by taking on the effort
The lesson here was that our team had not been experts in the methodology when we kicked off this effort. We had never done it before nor had anyone ever worked in an organization or team that had used this methodology. However, everything we were doing made sense because we took the time to understand it and how what we were doing was simply a combination of good practices we had known and used in other places. Most of the theory behind the “new” methodology was for example the same stuff most of us learned in college years before (Deming, Juran, organization behavioral, statistics, Hawthorne effect, software engineering, etc.). We became experts by taking on the effort.
Experts, journals, blogs, books, seminars, etc., are all great sources of information and good ideas. However, the notion that we must be an expert before we can do something or we need an expert to tell us how to do something before we do it is, in my experience, rarely the case. Most of the real experts I’ve known are self made. They studied, researched, observed and tried things out, and became experts in the process. Few, if any, became experts by just taking training courses from experts or amassing certifications. Becoming the experts we needed is a project management tool that worked.
Are you allowing the notion of lacking expertise to hold back your project from achieving better results?