A few weeks ago, Stout Systems and the Ann Arbor Chapter of the Association for Women in Computing cosponsored a seminar led by Mary Poppendieck. Ms. Poppendieck—noted author and speaker—is arguably the expert in Lean Software Development. We did this because of the increasing interest in Lean from our customers and from the industry generally.
Lean is not strictly a process. It is an organizational philosophy that brings into alignment all of the processes in a business so that they deliver increasing value to the customer—while eliminating waste and inefficiencies. Lean, by no means, applies just to the software business; in fact, it originally comes from the extremely competitive manufacturing world.
If there was any doubt about local interest in Lean, it was quickly dispelled as the seminar sold out in a very few days with only word-of-mouth promotion.
The seminar itself was a 3-hour rapid-fire introduction to Lean. Even more important than the theoretical study of this methodology, the attendees took part in several practical group participation exercises led and critiqued by Ms. Poppendieck.
We surveyed attendees immediately after the event, but we thought it even more important to find out if what they learned had a longer term impact on their work processes. So we waited a few weeks, contacted many of the attendees and surveyed again. Clearly, even this short exposure to Lean made an impact on the thinking of most of the attendees.
Here are the results of this second post-seminar survey.
The Lean principle Eliminating Waste sounds so simple. For those embracing Lean processes, the value proposition of waste elimination requires that one first understand the apparent contradiction that waste is continually appearing and yet must be permanently eliminated. Elimination is done through effectively removing one cause of waste at a time.
Survey results are divided on how well attendees are handling this one. Following the seminar, half of the attendees have become devoted to eliminating waste from their processes. Some see it as a daunting task because the source of waste is externally imposed upon their teams by organizational policy.
One of the managers I surveyed told me that the most noticeable improvement for his teams has come about from having his developers talk directly with customers (a change in previous philosophy). Among other things, this led to getting content right the first time and a huge reduction in support calls.
Another persistent technical leader has convinced his company that code re-factoring is a vital part of their development process, and has shown his bosses that their organization's dependence on using and testing with an outdated, inefficient code base ("technical debt") is a major source of waste and cost overhead.
The problem of Task Switching exposed a raw nerve with nearly everyone surveyed. Most attendees had already been attempting to address Task Switching in their own way—if only in self-defense—before they went to the seminar. The exercise during the seminar demonstrated conclusively that Task Switching always creates additional time and requires more energy to attain a goal.
It takes discipline and a certain forcefulness to stick to the task at hand and see it through to completion.
The survey respondents were split in terms of implementing handlings. It's obvious to most that focusing on one thing at a time is desirable, but making that focus happen is tough, especially in environments that are directly customer-driven.
One solution employed by a very strict team is somewhat controversial: an "off-the-grid" approach achieved by disconnecting all unnecessary communication channels such as phones, email, Twitter and office wanderers. Another attendee uses headphones to keep focus; this technique blocks out the noise of the environment and also discourages potential interrupters from diverting him, intentionally or otherwise. My own approach is to handle the thing in front of me until it is complete, not to start it then set it aside or pass it along to someone else when it is mine to handle. These solutions are all situations where a policy of non-interruption, when followed, could eliminate waste.
Surveys showed that the concept of a Value Stream Map is not entirely understood. In short, a Value Stream Map is a representation of the complete flow of a product start-to-finish as it makes its way through a company. The purpose is to discover where waste appears so that it can be obliterated.
Value Stream Maps were discussed in the seminar but not in great detail. All surveys showed interest in learning more about Value Stream Maps and using them. One brave company officer has produced maps on her company's pre-sales and software production processes to find inefficiencies, looking at how she can front load those processes more effectively so as not to run into QA bogs at the end.
It is commonly stated that there is no "I" in Lean. True enough. Only a team can implement Lean.
People in leadership roles in our business tend to focus on the most stimulating aspects of creating great software. That necessitates devoting oneself to learning and strictly making use of a philosophy such as Lean.
While Stout's own philosophy has always been to eliminate waste and inefficiency from our software development processes, the fresh view from Mary was quite welcome, especially in the area of Task Switching. We've found that the best results are achieved when we stay focused, sometimes doggedly, eradicate secondary distractions, and get directly to the goal. We are also evaluating our hiring and staffing process using a Value Stream Map. More to come on that.