About this Blog

Welcome to this exploration of Agile and Lean ideas applied to engineering. A key topic—though not the only one—will be Agile practices for developing products in an engineering setting. Software and hardware.

I’ll also explore business systems. Why do we so regularly succeed in achieving goals no one wanted? Like buggy products that just become shelf-ware? In leading projects, I learned how much control you don’t have—and got interested in ways to succeed in spite of that.

But my main interest is in helping people see how to use Lean and Agile ideas now in their own setting to solve real problems. So I’ll offer that help here, for all varieties of development work—I’ve coached businesses doing business applications, financial services, embedded medical and safety-critical work.

Posted in Lean-Agile Partners | Leave a comment

How Does a Cashier Add Value?

Sometimes customers see value in activities that managers view as unimportant.

There was a news story on the radio today saying supermarkets are starting to do away with the automatic checkout stations. Why? They listed a number of down sides such as

  • Initial cost of the machines around $20K
  • The machines need constant maintenance—more than expected, so is expensive
  • Customers find them frustrating to use because they often have a question and no one is there to help
  • “Forgetting” to scan the prices of some items has been an issue
  • Only 20% of customers use them

The advantages of the automated checkout machines had seemed to be so clear that they were a “no-brainer”:

  • Replace recurring wage and benefit costs with fixed lower costs

I am not sure what other advantages were expected. You get detailed record-keeping either way.

More surprising was what they found when they asked why so few people use the automatic checkouts. Statements like “Everyone here is so courteous—I just like buying from a real person” and “They pack the groceries in the bag better than I can do it” came up. I’ll admit I am part of the 80% that does not use them. I expect such things to be a hassle to use, and for some products it’s worth fighting my way through that to get the benefits. But the automated checkout machines don’t offer me a compelling enough benefit.

I can picture the sales pitch that the supermarkets heard from the checkout machine suppliers. If anyone had tried to say “but lots of customers would rather buy from a real person” how could they have made that case? How could they put a monetary value on it that could compare to the difference in hard numbers between wages saved and prices for initial installation and ongoing maintenance?

There is an underlying assumption that a cashier’s job is only to ring up the prices and nothing more. At least nothing more that has to be taken into account. But from lean thinking we hear the central idea “Let value—in the eyes of the customer—flow unimpeded from customer need identified to customer use.”

Here is a case where the customer is seeing far more value in those ancillary parts of a cashier’s job than the grocery store’s managers did. Customers clearly valued getting prompt answers to questions, having their things bagged, and even just a simple verbal exchange.

Could the store managers have done something differently? I’m tempted to point out that customers were not asking for automatic checkout machines. But that would imply that managers ought to just sit and wait to be told exactly how to run the business by customers. That’s not right either. Apple didn’t sit and wait for people to tell them to make an iPad—they correctly read the signs for what their customers wanted.  Not just wanted but would actually use.

Food store managers probably thought the machines would give faster service without adding as much cost as hiring more people. It’s their job to find better ways to serve their customers. They have to take the best information they have and work from that.

The real question is how to know when there is likely more to the picture than you see, and how can you try out a possible pathway without having to commit big resources to it before you really understand the dynamics? So it’s more than just using the best information you have. You need to unearth new information that helps you know what customers really value. This is what is meant by “focusing on the customer”.

Posted in Lean Thinking | Leave a comment

Embedded Agile is Different from Vanilla Agile

Because I began with embedded Agile, it took me a few years to appreciate what is missing from regular Agile that is important in embedded software and firmware development. I’ve started referring to regular Agile as “plain vanilla Agile”. Plain vanilla Agile isn’t incorrect but its practices leave a gap that embedded developers find especially hard to bridge.

That gap appears in these ways:

  • Stories, especially early on, cannot all carry end-user-value and be small enough; must target nearer customers
  • Co-development with hardware (Lean set-based design) means software team cannot be as autonomous as in (some) non-embedded work—must actively serve the needs of hardware group or the two deadlock each other
  • Technical practices are needed to sort hardware from software issues: examples of such practices include dual-targeting, and single mode trouble log
  • Longer-term planning is a must for embedded work but too many well-meaning coaches try to tell embedded folks “I don’t have it so you don’t need it” when the discussion turns to longer term planning

Over the years I have heard Agile folks dismiss embedded Agile as being nothing—that Scrum+XP provides all that is needed. At the same time I keep on seeing embedded teams for whom it is *not* intuitively obvious how to extend those ideas to their world. Many get the essence of Agile and some even dive into it after reading a book…and then get sucked back into sequential development by the demands of hardware or by the “detour” necessary to provide a long term estimate.

Both in my coaching experience and in talks I give, I see this crazy tension between Agile and the embedded community. Embedded developers are risk-averse even if their work isn’t in a regulated industry because embedded products tend to have a life span measured in decades, not just months.  So the Agile talk about “extreme” anything has already blocked them from getting Agile buy-in from their managers and customers. At the same time they are under pressure to get bigger apps done in shorter time frames.

The nutty thing is that it was embedded work that got Ward Cunningham going on the idea of very small, simple tests to probe behaviors and to check potential designs—and that evolved into XP through his 1980′s work with Kent Beck at Tektronix long before the C3 project, which was the public debut of eXtreme Programming a decade later. XP is “eXtremely careful Programming” if it is anything. Electrical engineers have done more than anyone to make modularity and re-use a reality in the world of engineering design. Agile practices allow software development to do likewise.

Agile practices have spread rapidly through software development and are starting now to go beyond it. Over the past half century, lean manufacturing has applied the same core thinking to production and also to the business side of things. In upcoming postings I’ll explore what this all means for Lean-Agile Engineering.

Posted in Embedded Agile | Leave a comment