Using Every Tool in the Box

Share
Reading time ~ 5 minutes

At one of my former employers it was mandatory for every engineer and manager to be Lean Six Sigma Certified to at least Green Belt level. Most executive managers also needed to be Black Belt certified.

Don't worry, this Ninja is 'armless

(One of my team on my last project is a real black belt – in Aikido – he finds the copying of terms somewhat problematic. I’m not going to argue with him!)

The company was heavily manufacturing-oriented; producing machinery for oil & gas, jet engines, power station systems, white goods, medical equipment and more. You name it, they probably made it somewhere around the world.

The Lean aspect of the certification was a later addition but made it worthwhile – at least for me. However most of the “engineers” I worked with at my main site were purely software engineers. (A few of our other sites I worked with had software, firmware and hardware for the same products under one roof). The software teams didn’t see the value in a (rather rigorous) mandatory certification – and given the way it was taught and introduced I don’t blame them.

A Green Belt certification requires a week of training, book study, completion of an exam and delivery of a full end-to-end process improvement project following one of the Lean Six Sigma improvement cycles (typically DMAIC – Define, Measure, Analyze, Improve & Control). Beyond this, the DMAIC project has to use a broad selection of statistical process control and measurement tools for each of about 15 steps throughout the project.

Certification candidates had to identify a real (but small enough to be achievable) process improvement project on their site and deliver it through this process. A challenge with our software teams is that many felt they were already following continuous improvement practices and that the overweight nature of the certification projects was entirely unsuitable for the work and improvements they were doing.

In many ways they were right.

The problem was that nobody ever explained why the projects needed to be so rigorous and what eventual value they would see. All they were told was “By becoming Lean Six Sigma certified you can talk with staff and managers across the company at any level using a common language and understanding.”

That’s a great ideal – except that their management chain already spoke the language of software.

As a manager at the site, I too had to run a DMAIC project. It took nearly a year to complete as I had to use “borrowed time” on top of all the other projects and initiatives we were all responsible for. Funnily enough it was only after I left that company that I discovered how valuable the experience was.

Picture working in a garage for a high-end specialist motor vehicle company.

You have an array of tools in front of you. As a novice you don’t know how to use anything but a spanner. You barely recognise what some of the tools even do but as an apprentice, you’re trained up, taught the proper way to use each tool and in what situation and context. (You don’t – after all – use a sledgehammer to crack a nut).

This is where my Six Sigma training and certification failed significantly.

You’re required to prove you can use all the tools in the box but nobody actually explains that once you’ve learned how to use them, you only need you to use the right tools at the right time.

As a result, the indoctrination of Six Sigma churned out a high number of people that believed it was mandatory for every process improvement project to follow the same rigorous steps and use all the tools in the box. (I believe this culture has changed significantly now though)

The problem was exacerbated further by introducing a specific Six Sigma career path. Staff could apply for “Black Belt” roles that were a 2 year rotation through various parts of the business. These were amazing roles focused on delivering rigorous process improvement programs all over the wold however they had some dangerous flaws.

The 2 year rotation was actually the time it took to complete a Black Belt certification. Much like the Green Belt, it required completion of projects. In this case, two major process improvements for a business. Plus teaching and facilitating Six Sigma and Lean events.

Most (but not all) staff in Black Belt roles were not actually certified yet. Their personal goal for the 2 years rotation was to attain their certification such that they could move on to  become a “Lean Leader” or similar roles elsewhere.

Imagine the distortions in behaviour you’d see if the primary motivation for the person leading your major process improvement program was to complete 2 projects in 2 years in order to attain certification.

I personally experienced one particularly bad instance toward the end of a project at my site where a team of unqualified Black Belts were parachuted in to “fix” our out of control defect backlog. On the whole, these people were not experts – but they knew how to work the system.

In this particular case; toward the end of the project when it became clear their original quality target was not physically achievable they actually moved the goalposts.

Rather than a defect fix being declared “done” when shipped and accepted by a customer, “done” was redefined to mean “code complete”. They fast-tracked nearly a thousand bug fixes in 6 months through engineering (and our outsourced partner) with no capacity for test and release resulting in significantly more code churn than our customers were willing to tolerate in the same time frame. The development teams couldn’t actually ship the fixes to customers and at the end of the project, the Black Belt team were hailed as heroes for “fixing” the problem and process.

Statistically, according to their measurement system, they had!

The Irony is, the new process they introduced was great. They used a construction and manufacturing management concept known as “Line of Balance” to plan and deliver fixes according to customer “want dates”. If the team had the freedom to ship specific releases to the right customers and customers had the ability to install them it would have worked amazingly well however their analysis stopped within the building without awareness that those customers generally had many years and millions of dollars worth of product customizations meaning they were unable to take “raw” product releases any more.

They missed the critical context of our customers and users.

Anyway… I digress!

It’s worth learning how to use as many tools and techniques as you can. Understanding the powerful combinations available to you across different theories and practices allows you to combine and apply that knowledge in valuable and novel ways. 

But just because you know how to use all those tools, doesn’t mean you need them all the time – choose the right tool and process for the job at hand and remember to keep things as simple as possible.

 

 

A Dream of Project Management

Share
Reading time ~ 3 minutes

A short post today…

A lesson in seeing the wood for the trees

Last week I had a dream about project management – sad, I know!

I was in a room with 3 other people. The first posed a problem…

“You’re starting a new software company and have decided you want to kit out your new 3 storey office properly. For the sake of simplicity, the 2 key tasks that need completing are decorating and wiring. The wiring cannot start until the decorating is complete. You want to be moved in in a month however decorating takes a week per floor and wiring takes 3 days per floor. Can you do it?”

A project manager stepped up and started talking through the problem

“It’s a simple, sequencing and crashing problem.”

“We can do one floor at a time. A week of decorating and then a week of wiring for each floor.”

“By the end of the month, you’ll have 2 floors ready which should be plenty.”

“If you need to run faster, we could contract in some more resources, run each floor in parallel.”

“There’s still drying time to take into account so each cycle of decorating won’t be able to run any quicker but in theory with enough resources and adding in contingency and risk, I think we could commit to being moved in in 3 weeks.”

The “dream me” smugly stepped up and said

“That could work but where are you going to get all the extra people from and can you afford it.”

“Can’t you see, it’s a theory of constraints problem. For the first week, the wiring team are unoccupied. Let’s have them step in and help the decorators. And when that’s done, let’s have the decorating team help with the wiring.”

“We can have one floor ready in much less than 2 weeks and have them all done within 5”

Obviously the “dream me” had failed to notice that electricians and decorators are different skill sets. And still mentally treated them as “fungible resources”. (Nobody would ever think something like that in the software development world right?!)

Then the “Systems Thinker” stepped up and said.

“You’re starting a new software company in the 21st century…”

“…Why the hell do you need an office at all!”

If you’ve not been watching HBO’s “Silicon Valley” comedy series; I thoroughly recommend it. It’s offensive but is a powerful series of caricatured observations of the software industry. Season 3 includes an episode where a promising startup blows nearly all their funding on plush offices, chefs, a foosball table and all the other trendy office quirks.

So the dream was over-simplistic and flawed in many ways but it did at least encourage me to start writing again.

Don’t just focus on the problem or solution immediately in front of you. When somebody presents you with the solution they want, remember to take some time to figure out what they actually need to achieve and discuss their rationale and motivations.

All too often we want to step in, help, achieve, and deliver.

Stop and think about the context, goals, impacts, and relative value/opportunity trade-offs before starting on that next great solution.

Defeating the Misuse of 5 Whys

Share
Reading time ~ 2 minutes

I’ve tried using 5 whys techniques on many projects and with teams and individuals in a variety of situations.

It’s generally used for root cause analysis but often (I think) misused for other situations. Something about it has always bothered me.

When you see it described in theory it makes so much sense. But most examples are already solved (and I suspect refactored for post-rationalization). When you use 5 whys techniques in practice it never quite hits the mark.

In most cases where I’d have previously considered a 5 whys line of questioning for understanding cause I’ve been inclined to use an Ishikawa (fishbone) diagram instead. This allows us to dig into multiple lines of questioning and link across related areas.

19th July 2013: Output from the retrospective

But this still only works well in understanding problems, not goals and reasoning.

Thanks to a great session from Paul Field at the Cambridge Agile Coaches Camp last year – I’ve finally been given a 5 whys alternative that actually works properly outside the context of examining root causes.

Paul’s own article goes into the full detail on the lines of questioning and the techniques involved so I strongly encourage you to give this a read.

A large part of the improvement here is in replacing the question “why” with directed alternatives.

“Why” in psychotherapy (and some coaching circles) is seen as a dangerous question. From a purely human perspective it can be confrontational and seen as judgmental. A good therapist or coach will instead ask very specific questions based on context  that encourage consideration and introspection in a safe and well-judged manner.

Much like asking a child “Why did you punch little Davey in the face?”, asking “why” – particularly in challenging, negative, or political situations is unlikely to yield a well-reasoned answer. You’ll get a knee-jerk and/or self-justifying response.

Put another way. Repeatedly asking “Why” is like using a sledgehammer to open a jar of candies.  You’ll open the jar but I wouldn’t recommend putting the results in anyone’s mouth – and you’ll still have to go fishing through the damaged results to find anything of real value afterward.

Next time you’re considering 5 whys, try asking “and what will X get from that?” instead.

Dark for the last few months?

Share
Reading time ~ 3 minutes

photo looking up a medieval chimney

There’s some bright lights ahead…

Over the last year I’ve changed roles (twice – but still in the same company) so things have been pretty quiet on here as I cram a mountain of new information, ideas, thoughts and challenges into my brain and try to make sense of it in ways that are insightful or useful to anyone that reads these posts.

I picked up and then put down development of my text adventure after a few months – I learned more than enough to meet my stated goals when I started but re-discovered how addictive coding something you really care about can be. I got to the point where I was head-down coding 6+ hours a day on top of a full time job. This was stealing time away from learning more important and valuable (but probably less fun) things for me and not leaving me enough head space for much else. (It was also mentally exhausting doing both)

As some context, Last Spring I moved on from my Head of Project Management role here to work with our Sales Operations team for a couple of months. This was a combination of me wanting to get my head back into the commercial side of the software business and a pull from the team to have some support and a tune-up around their capacity, flow of work and goals.

I’ll write a short post on this as it was useful for both me and the team but in a nutshell it was just under 3 months of applying lean, agile & theory of constraints principles to an ops team and setting them up for future success.

Since the Summer I’ve had a new long-term challenge. It’s a far cry from leading agile teams but still uses my broader industry skills & experience.

I’m now heading up Product Design here.

So far I’m loving the move. It’s full of new challenges. I’ve picked up support for our Technical Communications, User Experience and Product Management communities, bootstrapped a major product design initiative and (as always) I’m interviewing like crazy for new recruits for all these roles.

I’m now working directly for our CTO as part of a team of 6 amazingly talented people covering our innovation, strategy, engineering and product design capabilities. We’ve a load of work to cover and our roles intersect enough that we can collaborate on some bigger things affecting the way we operate.

At the moment we’re in the middle of rebooting our communities of practice, a portfolio-wide strategic review, a push toward design-led product thinking, building a strong learning and development foundation for our product organization and significant market and innovation research.

After feeling that much of the new focus in agile (around scaling) was in contexts that no longer applied to me, it’s good to be back into researching and studying in depth around strategy, design and innovation and finally feeling these ideas all coming together. I’m thoroughly enjoying the break from running software teams directly and working hard on my influencing, sharing and leading again.

So… Time & motivation-permitting I’ll start posting a few new lessons and experiences over the coming weeks and months. They’ll still have relevance to agile and software but will be much more focused on the business end of things; product design, strategy, recruitment, organizational capabilities and innovation.

Thanks for sticking with me this far.

S

 

Ship Early – Why New Software Sucks

Share
Reading time ~ 4 minutes

I’ve been working in software product development companies for nearly 20 years.

Until 4 years ago I’d always been involved in “enterprise” software.

You know – the monolithic systems with great reporting capabilities that sell well to managers and (at least historically) poor UX for the real users. Those same products that promise the moon during slick demos, require 6-12 month sales cycles where complex pricing structures are worked through and year-long implementations are agreed.

I’ve helped set up demos, I’ve watched amazing presales engineers work all night to rewrite chunks of an application to demonstrate to a prospect that it’ll meet their unique requests.

And then during implementation you discover some of it just doesn’t work.

I implemented one company’s products internally. Dogfooding from the day V1.0 was released. In 6 months I raised over 50 showstopper bugs (almost all were found by their first real customer not long after us). On a visit to HQ in San Francisco, after a fair bit of wine at a great Italian restaurant in Burlingame (the House of Garlic if I remember correctly) I challenged the then VP of Development for that application on why they shipped blatantly unfinished software.

His answer was simple,  logical and for a young, inexperienced graduate analyst programmer my first window into the commercial realities of product development. He said;

“Market timing”

“If we released when the software was actually finished, we’d be beaten to market by our competitors.”

“It’s acceptable business practice because it takes 6 months to sell and we can’t start selling until the product is released and in our price books.”

“Even after the sale it takes months to implement so by the time users are ready to go live we’ve fixed all the major issues because you guys are dogfooding it for us”.

It made a whole lot of sense but it wasn’t something they ever told us on the project!

The thing is, everyone else is on the same bandwagon and the escalation games start rolling.

Products are brought to market earlier and earlier in their maturity with the knowledge that “nobody trusts a v1.0 version of a product anyway.” It continues today. Many large banks won’t touch an x.0 version of a product until the first major maintenance release is shipped.

My experience was the same. In most companies I worked for; when a new release of the DB platform shipped, we’d plan on adopting it sometime after the first 6 months out in the wild when we knew it was stable.

The game has moved on. It’s no longer just products that take a year to sell and implement so our exposure to early releases is increasing and in general so is the entire industry tolerance (there are obvious exceptions in safety-critical systems).

In my time at Oracle in the late ’90s I saw them try to change this world. They had a vision known as”Gray Iron”. It seemed brilliant – for business, development teams and customers. The idea was that based on a playbook of “best practice” business processes a customer could buy a server entirely preconfigured and working out of the box to support their entire financial, ERP and CRM set of processes. They could simplify the pain of users, ensure quality was high and radically reduce implementation times. Obviously this also offers a great potential competitive advantage.

Sadly it didn’t take off. Competitors were still playing the “ship early” escalation game so we had to play too – the poor system fed itself.

The surge of change brought about by Eric Ries’ book The Lean Startup has fanned the flames of this mentality. Ship early, get customer feedback and adjust.

The sad thing is this used to be only in the enterprise market but the world has turned. Consumer electronic devices now face the same market timing escalation issues as this article from December on Forbes highlights.

It’s now common for us to expect our phones to need a reboot or crash and even for consumer software to have significant glitches.

It’s great for the pace of innovation but spare a thought for the end users and customer support teams.

It’s a commercial reality we can’t avoid but let’s make sure we’re not sacrificing the end user experience. If you must use your customers as lab-rats, let them opt in or out of your experiments. Let them decide if they want “bleeding edge”, “new” or “stable” and honor their wishes.

If your product is even remotely valid you probably have enough early adopters willing to validate the bleeding edge without sacrificing laggards on the altar of possible futures.

What’s your “ship early” policy like?