I believe there are big benefits to knowing how to code (programing, software development). What is possible for your organization is often significantly impacted by understanding how to properly use software (and create it, coding, when needed). The lack of understanding of software is a significant problem not just for those wanting a job coding (that are available for those with the right skills) but also for those making decisions about what the organization should do.
The profound ignorance (meant not in a pejorative way but in the descriptive way) of software is a significant problem for managers today. The critical role of software in our organizations is only growing. And the importance of understanding software (which coding provides in a way no other learning does) is only increasing. My guess is a decade or two or three from now a understanding of coding will not be nearly as critical for managers. I am just guessing the nature of coding will be significantly changed and not understanding the details needed to code will not be as critical as it is today. Maybe I am wrong about the importance of understanding coding fading over time (it is more a feeling than a chain of logic I can clearly explain easily).
There are many indirect benefits of learning to code. In the same way that those with an education in engineering do very well in their careers overall, even if they take a path where they are no longer engineers a background in coding prepares you well for your career. Actually, similar to engineering, part of this effect may well be those that can graduate with an engineering degree and those that can be employed for several years as a software developer have skills and abilities that would have made them successful even if they didn’t pass through those experiences (still I think, those experiences to add to their success).
If you work along side good programmers these traits will be reinforced every day (this was my favorite part of my last job – working with great programmers that pursued these principles and re-enforced my doing so also). Yes there are also things you might have to temper in dealings with non-coders (being a bit kinder/less-direct about perceived failures, for example). Also some coders can be so engaged they expect an unsustainable commitment from peers (this is one of the great benefits of a good agile software development system – a focus on creating an environment for sustainable development [not expecting unreasonable effort/hours on the part of coders]).
For complex systems there is no root cause by John Allspaw – “We like to simplify complex problems so we can work on them in a reductionist fashion. We want there to be a single root cause for an accident or an outage, because if we can identify that, we’ve identified the bug that we need to fix.”
Get Ready to Fall Off the Cliff by Ron Ashkenas – “Managers of successful firms tend to become complacent and even arrogant, assuming that past performance will continue and that the formulas that worked previously will work in the future.”
Walter Isaacson’s ‘Steve Jobs’ by John Gruber – “Apple is an experience company. That they create both hardware and software is part of creating the entire product experience… [Jobs:] ‘That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.'”
Use heijunka, don’t reduce takt time by Michel Baudin – “Keeping your work force intact and prepared for the next upturn is just as essential. So you stop using temps, cut all overtime, go on four-day weeks, or three-day weeks, and use the available time to solve nagging engineering problems,
experiment with new technology, etc.”
The biggest complaint (with some merit) I see is why is lean/Deming/six sigma… so hard to actually do. If companies constantly fail to do it at all (even when they use the name) isn’t that an issue. Isn’t that a weakness of the “solution.” My answer is: yes. The caveat is, until someone comes up with the management system that both gets the results using Deming’s management ideas can, and is super easy for organizations to actually fully adopt (and have the great success that doing so provides) I know of nothing better than trying to do these things.
Certainly I believe you are much better off attempting to use Deming, lean or six sigma than listen to someone that tells you they have management instant pudding that will give you great results with no effort.
My belief is that a partial success rate is much higher than 1%. While many organization never go beyond slapping a few good tools on a outdated management system those few tools actually have good results. Maybe 50% of the implementations are so lame they have almost no positive results (not even getting improvement worth the time and effort). They could be seen as “failures,” to me. Those that actually have a right to say they are practicing “lean” I would say is a pretty small number but still above 1%?
There is also an advantage to this stuff being hard to do. You really don’t have to invent anything new. If you just have persistence and keep continually improving along the path applying ideas proven over decades from Deming, Ohno, McGregor, Christensen, Drucker, Scholtes, Womack, Roger Hoerl (six sigma)… you have a great advantage over all those organizations that ignored the ideas or made a bit of effort and then gave up.
They are several critical paths to address in building our pipeline of future scientists and engineers. First we need to encourage kids to explore these areas. In my opinion, we currently do a pretty good job, sadly, of discouraging kids as much as we can. So reducing those barriers is key, then we need to actually build ways that help kids. We actually do have many good efforts in place to encourage kids to explore their natural curiosity (follow that link for tons of great organization: FIRST, Project Lead The Way, Engineering is Elementary, The Infinity Project etc.). This helps balance out the discouraging of students that our normal classrooms do. But the pool of kids we reach with these efforts now is far too small. And many are so turned off by our traditionally science education that no matter how much they enjoy outside science and engineering projects they are not willing to pursue science and engineering in school.
The next big area is undergraduate and graduate education. At this point we do a good job, for those willing to put up with the current model of education, which is not designed to encourage those who are interested. It is basically up to weed out any students not willing to put up with the current painful model of higher education for science and engineering. The system seems designed to wean out those who are not sufficiently willing to put up with the difficulties they are asked to face. If the only people that would benefit from science and engineering education are those that are willing to deal with the current system, then it might be fine. But I believe we have turned away hundreds of thousands of people that would have done great things with what they learned. I believe those that will not put themselves through the current system can offer great value. We will gain great benefits if we create a system that is designed to maximize the benefits to students.
Maximize Test Coverage Efficiency And Minimize the Number of Tests Needed by John Hunter – “The steeper the slope the more efficient your test plan is. If you repeat the same tests of pairs and triples and… while not taking advantage of the chance to test, untested pairs and triples you will have to create and run far more test than if you intelligently create a test plan.”
Toyota University Lean Video – This video shows one of the lean training simulations developed by the experts at Toyota. As you can see, the game uses toy car manufacturing (what a surprise!) to illustrate pull production.
The Apple Voice by Zach Holman – “Mechanically, The Apple Voice is characterized by short, declarative sentences that are informally and personally delivered to you with a hint of smugness.
Our most amazing iPhone yet. 10,000 songs in your pocket. We think you’ll like it.
In agile software development tasks are documented as user stories. Then the level of effort for those stores can be estimated by assigning each story points. The velocity that can be produced in a period (called a sprint, for us 2 weeks) can be estimated. Thus you can predict what can be delivered in the next sprint (which can help business managers make priority decisions).
I have found estimation to be worthwhile. In doing so, we accept there is a great amount of variation but points give a hint to scale. They can help prioritize (if you have 5 things you want but 1 is much harder you may well drop that to the bottom). I have always accepted a great amount of variation in the velocity, worry about the variation I don’t find worthwhile. I do think trying to act as though the velocity is precise can lead to problems. At the same time having a measure of velocity, even accepting understanding variation was present, was useful.
Over time reducing variation (probably largely through better estimation and perhaps a few better tools, reduced technical debt, better documentation, testing…) is helpful and laudable. We made improvement but still lots of variation existed. The biggest help in reducing the measured velocity was breaking down large stories to more manageable sizes. The challenge of estimating user stories, I suspect, has some fairly high variation (even with good system improvements that can help reduce variation).
Large stories just can hide huge variation in what is really required once getting into implementing it.
The way we did estimation (discussing in a sprint planning meeting) did take some time (but not a huge amount). It was agreed by those involved that the time spent was worthwhile. Sometimes we did slip and spend too much time on this, that was an area we had to pay attention to. The discussions were educational and helped provide guidance on how to approach the story. The value of discussions around estimations was probably the biggest surprise I have had in implementing any agile ideas. The value of those discussion was much higher than I imagined (I basically anticipated them just as non-value added time to get the result of an estimate, but they were a source of learning and consensus building).
Bob Lutz, the former head of GM, says it was neither uncompetitive wages nor unions that drove the Big Three into decline. It was a management with its eye focused on the bottom line and the short term.
That sentiment should be familiar to students of Deming (it is one of Deming’s 7 deadly diseases). It is sad that this bad management practices, short-term thinking, continues to do harm several decades later. Hopefully we can do better in the next few decades.
retiree health care and pensions — burdens that are borne by society, not manufacturing plants, in every other advanced country. That disparity, the result of policy decisions made in Washington rather than wages negotiated by the United Auto Workers, was the source of most of the labor-cost advantage enjoyed by foreign companies.
The excessive health care costs in the USA, another of Deming’s 7 deadly diseases, has continued to get worse every year since he classified it as one. The damage that the failed health care system in the USA does to the USA is enormous.
As happens in this fast paced world this service is no longer available. The company has shut down their web site.
I think the potential for consulting as you need it is great. I actually was looking into creating an application to support the ability to provide this service with someone else; but we just had too many other things going on. I have now made myself available for consulting you pull as you need it through MinuteBox. You can get consulting when you need it for as little time as you need.
So if you are trying to apply the ideas I discuss on this blog and run into issues you would like to get some help with connect with me and you can get some immediate coaching on whatever you are struggling with. I am offering a special rate of $1.99 a minute, for now. The graphic on the right of this post (any post on this blog, actually) will show if I am available right now (as does johnhunter.com). If so, you can connect and get started. If not, you can leave a message and we can arrange a time.
I am featured on MinuteBox with this cool graphic, isn’t it nice 🙂
John Hunter feature on Minute Box homepage
One advantage of this model is that those of you following this blog have a good idea of what topics you would like to delve into more deeply with me. If you have any questions on a particular topic you would like answered today or arranging coaching on specific topics over a period of time or help planning a project or someone to bounce your ideas off give this consulting as you need it model a try.
For those of you management consultants reading this blog (I know there are many) you can create your own Minute Box account easily and provide this service also. And even if you are not a consultant if you have advice worth sharing (and I know there are many of you also) you can also set up an account.
Less Process, More Discipline by Charlie Martin – “Without it, you lose everything agile methods promise. The key to agile methods is this: You may have less process, but you must have more discipline.”
Evaluating Executive Performance by Art Smalley – “One interesting thing that I will note that was considered in Toyota in Japan by the HR department when evaluating executives was how their previous departments fared after they had left. If the department continued to improve then this was generally a good sign.”
The evolution of design to amplify flow by John Hagel – “If we want to remain successful and reap the enormous rewards that can be generated from flows, we must continually seek to refine the designs of the systems that we spend time in to ensure that they are ever more effective in sustaining and amplifying flows.”