Tag Archives: Six Sigma

Is There a Disconnect Between Knowledge Workers and Business Leaders?

Posted on by

The past two weeks I’ve read a number of articles about the End of Agile and subsequent rebuttals. Yesterday I read an excellent article asking “Whatever Happened to Six Sigma?” Both of these articles are fascinating. The rebuttals to the first are incredibly enlightening. I don’t think these are the last of these sorts of articles. I expect to read “The End of Lean” down the road as well.

I think there are a few reasons, one of them is common between Six Sigma and Agile. Snake Oil Salespeople. Basically, what has happened with all methodologies (except for PMI’s Waterfall approach – which I’ll get to) there reaches a point in time where it becomes impossible to determine the quality of credentials for a given certification. At that point, the certification is valueless even if the training, like you dear reader received, was actually the top of the top. Because there’s no actual way to determine if the quality is any good or not.

I experienced this first hand while I was teaching Lean Six Sigma at AMD. I had some fantastic mentors when I was working there, that lived and breathed Six Sigma for their entire careers. They knew this stuff inside and out. Which made me gain a much deeper appreciation for the methodology. However, there was another small company in Austin that also taught Six Sigma to their employees, Dell. Whenever we hired people from Dell with a certification in Six Sigma, a Green Belt or even a Black Belt, we essentially had to retrain them. Many of them, did not truly internalize what they were taught, or the material was less rigorous. This was likely a trade off the Six Sigma training team had to make to ensure their team remained relevant to Dell.

However, whenever you cannot trust the training from an organization like Dell, it makes it a lot more difficult to trust training for any other organization. You just don’t know the standards. Agile’s currently experiencing the exact same issue. There’s been a huge influx of organizations giving certifications. Not all of them have the same level of quality.

I think as a reaction to this, the software development industry has created DevOps and DevSecOps. Which doesn’t have a certification process, but a general set of ideas, such as Trunk development, rigorous testing, continuous integration, and on the extreme continuous deployment.

I think all this goes back to a basic premise though. Knowledge workers, like engineers and software developers look at problems very differently than business leaders. I first experienced this while I was in college. I was studying Industrial Engineering (which pulls in elements from Six Sigma, Lean, Network Theory, Simulation, Human Factors, etc…) while a good friend was studying Business. We had a few conversations about how businesses should be run and it was very obvious to me, that we were talking about two completely different views of how a firm should be run.

I was arguing against (in 2003) off-shoring, because it decreased the efficiency of engineering and collaboration between manufacturing and engineering. Both Agile and Lean argue against off-shoring due to these reasons. Given the change in the approach, the salary savings, overall, didn’t make the effort worth it, because of the reasons I listed. My friend thought lowering cost was the right thing to do.

This isn’t just an anecdotal thing though. If you read books about Agile, Theory of Constraints, or Innovation, they all make the same arguments. The ideas taught in business school are causing business leaders to make bad ideas. Theory of Constraints was popularized in the book The Goal by Eliyahu Goldratt and came out in 1984. The ideas he espoused in that book were considered counter intuitive. If you read the Phoenix Project by Gene Kim which came out in 2013, which is written to model The Goal, you’ll find the characters running into, literally, the exact same type of thinking by managers and other team members. To me, this means there are other cultural organizations that are pushing back against the approaches technical leaders find work best and what our business leaders find work best for their goals.

The two most obvious cases for this are Accounting (which The Goal sets up as something of an antagonist) and Executives. Accounting has the weight of Law on its side, which is problematic, because Accounting organizations has their own reason for maintaining a status quo. They have their own certification process to become a CPA. From the executives standpoint, in many cases these folks are presented as having an MBA and excellent business training.

Despite that, they are still making poor business decisions for the technical team, poor decisions about how to structure their organization, and poor decisions about how to run projects. Most projects are run using a Waterfall approach, because that is the defacto approach we’re all taught throughout school. We manage to dates and push to get things done. The Project Management Institute has managed to corner the market on this approach, because most people can “do waterfall” without needing a certification. You learn through osmosis, by doing. The certification certainly elevates some PMs in some organizations. However, I don’t really think that having a PMP matters to most hiring managers.

So, where does this leave us? It leaves us with Knowledge Workers using ideas like Six Sigma, Lean, DevOps, Agile, and more to dress up their structured problem solving approaches to add structure and credibility. They need structure to compete with the Date Managed Waterfall approach. They need credibility of a methodology to put their approach on the same level as a PMP certification. In the case of Six Sigma, I’d argue its biggest success was internalizing the cost saving analysis. This helped translated the output in terms of money, which executives understand.

Every other approach tries to create an alternative measure. Elimination of Waste or “Working Software is the Measure of Progress” are nice alternatives to reducing costs or meeting due dates.

However, most share holders don’t care about that. They only care about what’s going to make them more money. Ethics and approach be damned. Until that is resolved. We’ll continue to have more fads or business fashions, as Knowledge Workers push back against Business Leaders.

Businesses and Silver Bullets

Posted on by

I’ve been teaching Lean Process Improvement or Six Sigma for about 6 years now. I’m getting into learning Agile in a pretty deep way through reading a ton of books, seeing it in action, and working with Agile teams. I’m currently learning Business Architecture/Enterprise Architecture as well. All of these methodologies are similar but different in some dramatic ways. Lean itself isn’t a project management solution, it has some features of it, but the goal is to take action put something in place and measure the results. Inherently, you’re supposed to be done as soon as possible. Six Sigma has some pretty strong Project management capabilities built into it, but it’s not to be used to install software or some other type of function, it’s design to solve a complex problem, prevent it from happening again and moving on. Agile is totally about managing projects while with as little overhead as possible, while maximizing visibility. This is done through frequent light weight touches and less frequent demos. Finally business architecture is about defining the structure of the business then identifying root causes. I’m the least impressed with Business Architecture at this point because it seems to have the objective of keeping the people at the top in charge while minimizing the amount of empowerment throughout the organization. That’s just my first brush with it though and I could be wrong. The other methodologies are all about empowering the team and the people doing the work so they can be as effective as possible. With Lean and Six Sigma the goal is to eliminate your own job if you’re an instructor or internal consultant, it doesn’t seem the be the case with Business Architecture.

Regardless, all of these methodologies indicate that our businesses are extremely sick. It’s becoming pretty clear to me that the vast majority of current state business practices are flawed and leading to under performing businesses. Lean Six Sigma, makes it clear that there are out dated and poor performing processes. Agile makes it clear that traditional software development doesn’t work and is much too expensive. Business Architecture indicates that no one knows what people are doing, why they are doing it, or where other parts of the organization are doing the same type of work.

In many cases some of the problems looking to be solved by Business Architecture are eliminated in a true Lean organization, but not always. I believe that is why Lean Startup methodology is becoming so popular in both new and old businesses. It’s a novel way to force change in an existing company, while in a Startup it helps keep the company healthy much longer. Furthermore, it forces the company to build effective organization structures early and continually test them.

With the majority of businesses being unhealthy due to out dated processes or aging systems, it’s no wonder why organizations are always looking for a silver bullet. They need a quick fix because nothing is working correctly. The goal to continually drive more and more profits prevents leaders from taking a hard look at what they are doing. Forcing investment in doing the right thing the first time or to do the right thing for the organization even if it takes more time and potentially money.

With my current process improvement classes and engagements I’m seeing a continually struggle between the way you should do Lean, focus on changing what you can, and the reality that most of the work is being done through systems. Even if I wanted to improve processes around the system there’s a limit to what I can do, because I cannot effect change on the underlying system. Changing those systems either IT or organizational can be impossible to do without a strong organizational will and clear strategy. Without either of those, any improvement or agile effort is doomed to fail.

Words, what are they good for?

Posted on by

At work, I’ve recently been given the task of redesigning all my training documentation and plans for Lean process improvement to something else. Apparently, despite successes, some of my leadership team doesn’t believe in Lean. However, they fully expect improvements such as reduced turn around times, quality improvements, and reduced non-value add activities to just happen. That it’s simply expected to occur without any top down pressure or support. Without clear direction or proper tools to measure improvement or even productivity, how can anyone expect to drive improvement in their organization?

Lean is a tool to do that, but since some leaders don’t believe that’s the proper way to drive improvement, we’re having to monkey with the idea of what it means to be an efficient organization. Therefore, I’m going to be rebranding everything to Process Innovation because Innovation. This does an interesting thing, it forces us to change the language we use for continuous improvement. We can’t use words like Gemba (the place where work is done), Kaizen (continuous change), Jidoka (automation with a human touch), Poka-Yoke (idiot proofing). or Muda/Muri/Mura (waste, overburden, unevenness). Using these words isn’t just to try to force people to learn some Japanese. It forces people to slow down and think differently.

Regardless of your thoughts on Malcolm Gladwell, he raises some really valid points about language in his book Blink, where he discusses the example of Korea Air and the usage of English as a language in the flightdeck because it changes the way the first officer and captain think about each other. Lean emulates this idea by forcing English speakers to use Japanese words. It forces people to stop and think about what they are doing. Yes, it’s a foreign word, but the meaning drives a change in behavior simply because it forces the people listening to slow down and think. According to Daniel Kahnman, system 2, deep and introspective thinking, is lazy and lets system 1, Blink thinking, do most of the work. A change of language and specific words triggers system 2 to actually pay attention and not just accept what is said as fact.

Now with Process innovation, I’m going to have to invent my own language and rules to try to force a similar behavior. I’ll have to lean heavily on Lean, Six Sigma, and other improvement methodologies rather than just Lean. However, this might confuse Lean folks.

It’s amazing the impact of a few phrases on changing the way people behave and it’s amazing how they can cause people to react in a negative way. Figuring out how to work around other people’s language hang ups is key for a successful work life, unfortunately.