Shared Principles for Managing People Engaged in Diverse Tasks

This post expands on my response to Michael Sweeney's (Cloud Infrastructure Engineering for Salesforce) comments on Linked In:

This is a great blog to follow [Curious Cat Management Improvement Blog] if you aren’t aware of it. I agree with John, in general, but in this post I felt the missed one basic thing that I’ve seen in my own career- software is not physical and people who write great software and people who make great physical things MUST think (and therefore be managed) differently. The crossover between Agile and Lean thinking, to me, is the ability to identify non-value added activity (waste) in the Toyota sense, and empower small teams to make decisions and charge forward in the Agile sense. Getting a combination of software and hardware thinking together will be the key to winning the Cloud Wars and moving into the Fourth Industrial Revolution.

Thanks for your comments. I do agree that the system within which people are operating determines how they must be managed. There are definitely features of software development that are significantly different than manufacturing scalpels or basketballs or tables. As there is a difference between a surgical team in an operating room, road construction, mining, editing books, investment banking, manufacturing industrial robots, researching new drugs, manufacturing drugs, teaching in a university, maintaining plane engines, coaching an athletic team...

I see universal principles of management (respect for people, customer focus, continual improvement...) that cross all different human enterprises. How those principles should be manifest in a particular situations depend on the work being done, the management system that is in place, the individual people involved, the specific focus of the effort right now... The way those principles are manifest will look very different in all the varied types of organizations we create and the different work and processes used within those organizations.

John Hunter, presenting at a Deming management seminar in Hong Kong

It is interesting (on the software v not software divide) to note that 100 years ago what was manufactured didn't contain software elements. And the manufacturing process also didn't involve software. That isn't very often the case today. Think of all the manufactured things you use and a high percentage (measured by the cost of the manufactured goods) have software components (cars, phones, appliances, speakers...) and they are built with a great deal of software involved in the manufacturing process.

In addition, the sales process and other processes involved in the organization doing the manufacturing rely heavily on software. As you say "Getting a combination of software and hardware thinking together" is indeed key today and will be continue to be in the future. While relying on software as part of the manufacturing process (and in the supporting processes) isn't the same as developing software the thought process on how to use software within manufacturing systems and how that software should work, be adjusted... is very different from the work of manufacturing tires 100 years ago.

I also discuss related ideas in: Deming and Software Development.

Related posts: How to Manage What You Can’t Measure - Create a System That Lets People Take Pride in Their Work - Good Process Improvement Practices - The Importance of Management Improvement - Thinking Required, No Simple Management Recipe to Follow -Unpacking the Components of Hard Work to Design Better Work Conditions - Do We Need to Find Management Ideas from Our Industry? (No) - Avoiding Difficult Problems

Understanding and Using Data: Waffle House Example

Comments on, Why FEMA is Monitoring Waffle House this Weekend

look outside your organization for risk indicators that might help you make better (and faster) decisions, particularly when those risks are activated. Second, that you should explore crowdsourced risk data as a source of up-to-date information.

I agree. Also, just look at data close to where the action is (internal or external).

And don't just look at aggregated data but dig into what individual data points tell you. Aggregated data is very useful but it also can mask meaningful insights available when data is looked at more closely. It isn't a perfect match to Waffle House data but I think the principle is visible in the Waffle House example.

The Waffle House closure data is based on actually closing based existing conditions while warnings and evacuation recommendations are based on predictions about the weather and the impacts those will have on locations. The warnings are necessarily predictions (to be useful for the whole community they need lead times to take action) where the Waffle House has more flexibility and the organization has managed their system to be more capable of adapting to harsh conditions. There is a real similarity with designing a agile software development process that is able to be more flexible and react quicker than old "waterfall" style organizations that have to predict far in advance and adapt slowly as conditions change.

Waffle House closures are a useful data point for conditions on the ground that FEMA can use with other data to make decisions on how to react.

Related: Bad Weather is Part of the Transportation System - Leadership: Taking Action When Others Are Unsure - Lessons on Competition from Mother Nature - All Data is Wrong, Some is Useful

How to Respond to a Request for Estimates on Software Development

Response to: Do We Really Need Estimates?

I think it is a question of addressing the purpose those see for estimates. If they just say "lots of people do it, so we should" then your answer is fine in my opinion.

If they say they need some way of deciding if doing that work is wise or something that is going to be so difficult that it isn't worth it then a different answer is needed. If they talk about scheduling then other explanations make sense to me - talking about the issues with fixed estimates etc. but giving them alternatives of fixed schedule with variable features (if there is a business need to deliver on some date)., etc.

Related: Agile Story Point Estimation (2012) - Assigning Story Points to Bug Fixes (2011)

The Tendency for Lean Experts to Distrust Technology

My thoughts on Why can't we use technology to accelerate Lean adoption across my company? [the broken link was removed]

I think biggest objection is how often and badly technology efforts fail. This makes a knee jerk reaction against jumping to technology fairly wise.

I think the second reason is technology expertise is often not found in the same people that have lean expertise (it can be it just isn't super common). Combined that with number 1 and the fact that making technology projects successful requires great system (rare) or can be made more likely with a deep understanding of technology and management systems (but I just said they often don't have the tech expertise) so again a reason to shy away from tech.

If a good lean consultant saw the organization had great system for making technology projects, countermeasures etc. successful they would support such efforts even if they were weak on tech. I'll also say most lean consultants aren't great. They don't understand lots of stuff about respect for people, management systems, customer focus, gemba etc.. Due to fear I think many that don't have strong lean understanding will shy away from technology.

I think technology solutions can be great. There is nothing wrong with them, when conditions are right. Conditions are almost never even decent - forget right. Technology projects and efforts are much more likely to be messed up due to bad systems and lack of expertise.

Technology solutions can have huge impacts - there are many good things possible with technology. The problem is so often technology wielded inside organizations (human systems) fail for many reasons very closely tied to bad management practices. The better the management practices the less likely technology will backfire in my opinion. The stronger the management system the more likely technology projects will be managed sensible, tested at the gemba, adjusted by people with a strong understanding of the gemba, project managed by people with an understanding of lean thinking practices (deliver working code fast etc.)...

The fear of technology projects is those reasons and more. Things like the same problem with brain-dead implementations shoving down a horribly inflexible ERP program or shoving down a 10% across the board budget cut and many other such efforts. Technology efforts really are no different than others but there are some difficulty in the problems of technology often being more difficult for people to see.

Technology also is often seen as this wonderful simple quick fix by executives - letting them avoid the gemba and just put hope in a essentially magic bullet solution.

The whole effort to make problems visible is much less likely to be done well around technology (which has to do with some issues with the domain but also with the lack of technology expertise [especially software development] of management and decision makers). Lots of the efforts in lean software development and agile have very good practices for technology efforts.

Related: Deming and Software Development - Involve IT Staff in Business Process Improvement - Mistake Proofing Deployment of Software Code

Boston Lean?

Kanban And Lean - A Challenging Association

I've come to refer to American Lean literature as "Boston Lean" to clearly differentiate it from Toyota materials generally translated from original Japanese. What makes me uneasy about Boston Lean is its focus on "the pursuit of perfection" through "waste elimination" where waste is "muda" (or non-value-adding activities). The typical Lean consulting firm, and again, I find myself mentioning, McKinsey, offer Lean through a defined approach that involves value stream mapping, identifying non-value-adding activities in the workflow, designing out those activities and then managing a change initiative to install the new, leaner process with the waste designed out. Like yesterday's post, my objection is to the process-engineering-centric approach and the notion that the process engineer knows best. This designed and managed change approach is truly the antithesis of of the Toyota kaizen approach where the workforce is empowered to make their own changes and processes evolve.

I think your kanban ideas are excellent. I think you are defining "Boston lean" to really be badly done lean. There is a lot of badly done lean - just as it seems to me every management system is poorly executed very often (specific practices or management tools can be adopted quite successful fairly frequently but overall system just are not, from what I have seen). I am not sure if management ideas are necessarily poorly executed so often but they certainly are quite frequently.

There are tons of great lean blogs by people based in the USA (Jon Miller, Mark Graban, Kevin Meyer, Jamie Flinchbaugh, Tracey Richardson, Mike Stoecklein, Bill Waddell, Bob Emiliani ...). If people read what those people are doing and saying I don't think any of the negatives of "Boston lean" are present.

I am guessing "Boston lean" is a swipe at the Lean Enterprise Institute (since they are based in Boston). I don't really think that is accurate. It seems to me LEI support lean done right - a system that help employees improve, not some top down dictate approach. I agree with you that much of what is called lean is bad management. I think LEI and those I listed about (and many more) practice lean as it should be, and I don't think that practice of lean has the drawbacks you mention.

Related: Lean Manufacturing and the Toyota Production System - Why Use Lean if So Many Fail To Do So Effectively - Rethinking or Moving Beyond Deming Often Just Means Applying More of What Dr. Deming Actually Said

====== David's comment on his blog ===========

Please take the time to observe what Lean consulting firms actually do. Do they sell managed transition initiatives that involve value stream mapping, designing out the waste and then deploying the expert designed "lean" (waste reduced) process definition? If you can refute that this is actually not what they are doing and how they make their money, then we can talk. Please show me the case studies where a true kaizen culture has been coached into organizations by these firms? Please show me the evidence where the workforce are empowered to perform their own kaizen events and that the consulting experts involved didn't actively design the new processes and manage the transitions.

====== my response to David's comment =======

You can look at what the people I suggested are doing, or you can chose not to. I am just suggesting that you would benefit from looking at them. I don't feel it is my job to provide the evidence packaged up for you. I also understand you have no reason to listen to anyone unless you feel like doing so.

I think your claims are what I said, looking at bad implementations calling themselves "lean" (and as I said, there are many) and defining that as Boston Lean. That is your right but it isn't so useful it doesn't seem to me. The main problem I see is that you seem to have missed all the good stuff being done with lean in the USA - that is your right, but I think you are missing a good opportunity to learn from others good work.

A great deal of great work is being done with the real lean principles -- respect for people and continuous improvement -- in the USA, and it has been done for decades.

You can ignore the good work being done by some because there is lots of bad stuff labeled lean. I just think the great stuff being done is useful and those interested in managing their organizations better would benefit from paying attention to the people doing good work (the ones I mention above and plenty of others).

Quick Mistake Proofing Ideas for Preventing Date Entry Error

I found a new failure mode for online bill pay. I had an electric bill due April 24. I mistakenly entered May 23 as the pay date 

So, by April 30, I had a late payment termination notice from the electric company. Kudos to them for the fast cycle time on getting those out. I paid the bill via credit card on their website. 

I’m not sure how to error proof “wrong date.” You?

It is easy to put in a filter that checks and then puts a big flash message:

  “The date you entered is after the due date. Are you sure you don’t want to put in a date prior to that...”

You can also make the data entry bias toward a on-time payment: require an extra step to go beyond the due date, default the value to be the due date... How you implement this would depend on the entry method.

It is really easy to do well if you are using calendar point and click – grey out all the post due date entries, if click on a greyed out entry, pop-up a message that says “that date is after the due date are you sure...” It gets less effective/cool if it is just text entry...

Even with text entry thought you can popup the message on submit of the form if the date is too late (so they enter the wrong date but you catch it before the action is completed).

You can also follow up with (using this method alone is better than nothing but it is pretty lame so I wouldn’t suggest it as the only method unless nothing else can be done reasonably) email saying “you entered a date after the due date in your last bill payment, if you don’t pay before that late fee…

Anyone what to hire me for a few minutes at a time to think of ways to make it harder to make an error just let me know. I don’t like processes that allow errors so have become fairly good and thinking up ways to make it harder pretty quickly :-)

Related: Mistake Proofing Deployment of Software Code - Improving Software Development with Automated Tests - Poka-Yoke Assembly

Avoid Bad Technology Non-Solutions Using Agile and PDSA

Automation is Not Always the Answer, in Retail or Healthcare

I’m not anti-technology. I just believe strongly in the “Toyota Way” principle that states: “Use Only Reliable, Thoroughly Tested Technology That Serves Your People and Processes”

Very good post. I am a big proponent of technology. My career path was basically from helping management improve organizational performance to IT program manager doing that same thing. I did that because there were so many opportunities to improve using technology.

But there are big problems. Many technology solutions are lousy. If people applied PDSA thinking they would be much better off. agile software development does this to a reasonable degree (I think they could do more in that vein but it is decent now). A big reason I moved into technology myself was because getting IT solutions implemented properly (even half way decently) was nearly impossible. And this is true all over.

If you use PDSA, systems thinking (Deming's view not computer systems) and agile software development methods you will avoid the all too common technology messes and instead take advantage of technology. You also need people that have the right skills and knowledge - knowing how to use technology properly seems to be less common that you would think given all the technology around us.

Related: Involve IT Staff in Business Process Improvement - Information Technology and Business Process Support

Agile Software Development and Lean Thinking

I think agile software development practices are by and very useful and in the spirit of lean thinking. Software development is a domain that is not equal to say manufacturing cars. There will naturally be differences in how lean ideas are applied. And then within different software development organization their will be differences.

There certainly can be issues with how agile is adopted. And how you look at features and releases can make sprints seem like bad batches. Kanban is being adopted more and more for agile teams as an alternative to sprints.

There is certainly some of http://agilemanifesto.org/ which seems to be against lean. "Individuals and interactions over processes and tools" But in my experience the agile community is very in tune with lean ideas but it is also an area very much filled with experimentation and with fairly big areas still far from settled. I discuss software development fairly often on my blog.

I see a strong future for agile software development and continue to work on using the concepts at work to build a successful software development organization, upon a foundation of Deming and lean manufacturing ideas.

In response to: Agile software development does not equal LEAN thinking

Related: Agile Practices are Needed, Not Just Words - Improving Software Development with Automated Tests - The Importance of Making Problems Visible

Agile Practices are Needed, Not Just Words

Agile is Fragile

I embrace Agile/Scrum development because I am firmly convinced that it addresses many of the problems that plague software development along with providing working professionals with the autonomy that they should have in the first place. If something isn’t working, most likely it isn’t the process that is at fault. I’d wager that there is an implementation or execution problem. 

... 

Many organizations struggle with implementing the basics. Jeff Sutherland has spoken frequently about the Nokia Test and how upwards to 80% of teams that claim to be doing Scrum don’t perform that basics (some don’t even know who the product owner is, let alone have a prioritized backlog). 

... 

When it comes to problems with Agile development, people tend to blame the process when in reality the problem(s) are in their implementation and/or support of the process.

Well said. I find many management failures are do to very poor implementations of a style - compared to just really bad ideas in the first place (though that also exists). I think agile has great potential but you can't just say we are doing agile and expect everything to work. Poor implementation of the ideas will lead to failure.

Also you have to realize, in many organizations, you have to make numerous modifications. In my organization we have had to modify things because of what the organization is willing to do. It is working well for us but we have to watch where we are weak and attempt to improve our ability to actually practice agile methods.

Related: Better and Different Management - Future Directions for Agile Management - Leaving Quality Behind – Again No