I barely know anything about LeanUX, but have chatted with Jeff before and read the first few chapters of his book… but my role here is to just ask questions… Jeff will explain Lean UX to us today. I’m taken by the parallels between Lean UX (along with Lean Startup) and more general “Lean,” as I know it in manufacturing and healthcare. It’s about deeply understand the customer and their needs, forming hypotheses, and iterating in an experimental and data-driven way… a departure from the old way of the designer “knowing” what the customer wants or a software company writing a huge specification document (about “half of which never got used,” says Jeff). Lean UX designers are problem solvers, they “get out of the building,” and they get their designs (or even just sketches) in front of customers to get feedback early and often. It’s better to do small, inexpensive tests of change… if you’re going to fail, better to fail early and fail often… and we’ll be more successful as a result. That’s good solid Lean thinking and Kaizen thinking. Read more about Jeff via:

You might be interested in an eBook with transcripts from some of my favorite podcasts:

If you have feedback on the podcast, or any questions for me or my guests, you can email me at leanpodcast@gmail.com or you can call and leave a voicemail by calling the “Lean Line” at (817) 776-LEAN (817-776-5326) or contact me via Skype id “mgraban”. Please give your location and your first name. Any comments (email or voicemail) might be used in follow ups to the podcast.

Some of you might have seen it, but I wrote a piece for the LinkedIn Influencers series about how the “Lean Manufacturing” principles are being used in various “knowledge work” settings – including healthcare, education, software, government, financial services, etc. Here it is:

I’m not sure that “Lean startup” philosophies have become so widespread that it’s now the only way that startups are being built. There are still “fat startups,” I’m sure, that work in stealth mode for months or years trying to build the perfect software that they are guessing is wanted by customers.

The article describes sounds what sounds like a classic “minimum viable product” strategy, using iterative development and customer feedback to prove out both the product AND the business model.

When Kira Talent released its first platform, it was little more than a prototype, hampered by a rudimentary interface and numerous bugs. It was, however, enough for the needs of its first customer.

…

Today, she still doesn’t pretend to have all the answers. The close interaction continues, and the ensuing feedback is used to continually optimize Kira Talent’s platform, which has undergone many iterations since its inception.

Ms. Cushman is part of a growing group of entrepreneurs who value experimentation and trial and error over the traditional approach of honing products for months before introducing them to customers. These companies understand that innovation is a messy, unpredictable process.

Anyway, check out the article… it suggests that larger companies are learning to use these “Lean Startup” techniques (companies like GE have presented at Eric’s event, before).

The same mindset applies to areas like healthcare. Instead of working for months and months trying to develop a perfect process, can we start by implementing something that’s better (but not perfect) and then iterate from there? Can we implement and test smaller batches of improvement? This can often be done by breaking large, unmanageable problems (like “patient satisfaction is too low”) into smaller problems (like reducing noise complaints). Many many staff ideas can be implemented and tested (as we write about in our Healthcare Kaizen series of books) instead of relying on one large project to “fix everything.”

]]>http://www.leanblog.org/2013/11/the-power-of-the-lean-startup-mindset/feed/3Digital Pathology Software Company PathXL on Their Journey to Becoming a Lean Enterprisehttp://www.leanblog.org/2013/10/digital-pathology-software-company-pathxl-on-their-journey-to-becoming-a-lean-enterprise/
http://www.leanblog.org/2013/10/digital-pathology-software-company-pathxl-on-their-journey-to-becoming-a-lean-enterprise/#commentsFri, 25 Oct 2013 09:00:22 +0000http://www.leanblog.org/?p=22770Mark’s Note: Today’s post is a guest post by Nial Toner, who works for PathXL in the UK. I thought this was an interesting post because it touches on leader behaviors and team dynamics in a setting that we don’t often talk about here – a technology and R&D setting. I’ll be away on vacation through November 6, so there will be guest posts from familiar faces and new faces during that time.

By Nial Toner:

The last 12 months have seen some big changes to the way we approach things here at PathXL, a digital pathology services company. There have been a number of changes in the overall company approach in the last year, but the most notable change has been the shift towards becoming a Lean enterprise.

In recent years, software development teams have adopted Lean manufacturing concepts, which aim to produce high quality products, quickly, making effective use of resources and reducing waste.

In the last 12 months, PathXL has moved from cottage industry practices to a world of Lean processes and agile development. We have introduced the philosophy of continuous improvement, by holding kaizen events, creating key performance indicators (KPIs) and improving our visual management process.

Over the past year, PathXL have introduced Lean concepts not only to the research and development (R&D) team but companywide, helping to build strong processes that are improved on a daily basis.

There are three core functionalities behind everything we do here at PathXL as we continue to introduce Lean processes throughout the business.

These are:

Communication

Teamwork

Continuous Improvement

Our lean processes start with two short meetings everyday in our Belfast office. The first is at 9:45 am, where the R&D team has a stand up meeting in their two respective teams to conduct their daily scrum. For those of you unaware of a scrum, it is an agile software development framework which is used for managing software projects and product or application development. The key principle of scrum is the recognition that a customer can change their mind about what they require. During this meeting each team member, in turn, answers three questions with a time limit of one minute.

The three questions asked of the R&D team are as follows:

Have you any impediments?

What are you doing today?

What did you do yesterday?

An example of this new Lean approach at work would begin with Chris from the R&D team saying that progress was slow yesterday because a test box wasn’t working correctly. From this Adam (also in the R&D team) notes down a concern on the continuous improvement list. Chris continues by briefly describing the requirement he is working on today and finishes by letting everyone know the progress he made yesterday.

This process is repeated for all team members with an action list being created at the end of the meeting which is aimed at removing all issues from the process.

The second team meeting takes place at 9:50 am, which is signaled with an alarm clock to indicate that it is time for the daily performance meeting. Members of both the PathXL support team and the R&D team huddle around the Visual Management Board. In this meeting ,the teams discuss anything that relates to the product development process with the live support process allowing for a discussion on any problems that have come up. This allows everyone to be aware of any problems in the development process and allows for corrective actions to be taken.

A recent example of this second meeting in action is where Garry (PathXL Support Team) asked all present if there were any communication points within the team. At this point, Steve from the support team stepped up to talk about any support tickets that had been raised.

Through this discussion, the team discovered that a ticket had been raised by a customer who couldn’t view images. The teams discussed this issue and Mike (R&D team) thought he might know the resolution, so he suggested that both he and Steve get together after the huddle to discuss in more detail how this customer issue could be resolved.

Adam (R&D team) then stepped up to the visual management board on behalf of the R&D team to inform everyone that everything is on track. This information was then added to the continuous improvement log, with everyone being informed that all customer issues would be fixed by lunch.

The meeting finished and everyone returned to their desk with a clear picture of what work needed to be done during the coming today. These two meetings, which take place inside 15 minutes, allow us to discuss any current issues, communicate the progress and resolve any impediments. Now that’s Lean!

Two men who have been instrumental in the progress of Lean processes here at PathXL are Paul Moorhead and Denis Sharp. Both men have made a significant impact on the way we work, with Paul playing a huge role in helping the R&D team get to grips with agile development. This process including the creation of robust software development processes, which looked at projects from the initial requirements through to gathering information along the journey to final delivery of the project. Denis, from BSE Partners, has introduced Lean processes to the wider company and helped to drive out waste and transform quality in all our processes.

About PathXL: PathXL is a global pioneer in the use of web-based solutions for digital pathology. They provide a range of innovative software solutions for use in education, research and clinical sectors worldwide. To find out more on PathXL and the role that lean processes have played in helping the company it’s web-based and software solutions for the healthcare industry visit www.pathxl.com.

Nial Toner is a content marketer for PathXL, a UK based company who provide web based solutions for the digital pathology industry and software solutions for use in education, research and clinical sectors worldwide. PathXL incorporated lean processes into their business in 2012 and continue to use the lean philosophy to help improve learnings and offerings for the healthcare industry.

]]>http://www.leanblog.org/2013/10/digital-pathology-software-company-pathxl-on-their-journey-to-becoming-a-lean-enterprise/feed/0Upcoming Webinars with Mark Graban, Shingo, and KaiNexushttp://www.leanblog.org/2013/10/upcoming-webinars-with-mark-graban/
http://www.leanblog.org/2013/10/upcoming-webinars-with-mark-graban/#commentsThu, 10 Oct 2013 12:34:29 +0000http://www.leanblog.org/?p=22846Here are a few upcoming free webinars that I am participating in… I hope you are interested and can attend:

Mark Graban & Joe Swartz – Healthcare Kaizen

Join Shingo Research Award recipients, lean experts and authors of Healthcare Kaizen, Mark Graban and Joe Swartz, as they present an hourlong Shingo-sponsored live webinar. Whether you are in healthcare, manufacturing, financial services or any other industry, Mark and Joe are sure to provide practical insights that you can put to work right away.

KaiNexus & Continuous Improvement

I will be giving a webinar, with Dr. Gregory Jacobson, co-founder and CEO of KaiNexus, presenting examples of real improvements implemented by our KaiNexus customers, facilitated by our technology. Learn how KaiNexus supports proven improvement models like Kaizen, Rapid Improvement Events, 90-Day Workouts, Baldrige, and more. The webinar will also include a brief software demo. Space is limited to the first 25 attendees.

You can use the player (use the VCR-type controls) at the top of the post to listen to a streaming version of the podcast (or click here for the streaming audio and RSS subscription). The streaming link is faster for one-time listening (hardly any delay to start listening). Or you can use the download link to put it on your iPod or other MP3 player.

If you have feedback on the podcast, or any questions for me or my guests, you can email me at leanpodcast@gmail.com or you can call and leave a voicemail by calling the “Lean Line” at (817) 776-LEAN (817-776-5326) or contact me via Skype id “mgraban”. Please give your location and your first name. Any comments (email or voicemail) might be used in follow ups to the podcast.

]]>http://www.leanblog.org/2012/08/podcast-155-jim-benson-personal-kanban/feed/2“Blame & Shame” is Shamefulhttp://www.leanblog.org/2012/07/blame-shame-is-shameful/
http://www.leanblog.org/2012/07/blame-shame-is-shameful/#commentsFri, 06 Jul 2012 12:00:09 +0000http://www.leanblog.org/?p=17734Many leaders in healthcare (including John Toussaint, Paul Levy, and others) are working to eliminate the “name, blame, and shame” culture that often exists in hospitals. This push (in my mind) started with W. Edwards Deming, who taught that 94% of problems are caused by the system, and continued to the modern patient safety movement, which also teaches a systems-based view of what’s needed to prevent errors, not just punish an individual after the fact.

With a hat tip to Patrick Vlaskovits, I saw this post online, related to software development:

My short answer would be: “You probably can’t.” Does a blaming leopard change its spots?

There were a lot of great comments, mainly from programmers and developers who seem to understand systems better than many of the managers do.

The poster of the question added:

My arguments that this will decrease morale, increase finger-pointing and would not account for missing/misunderstood features reported as bug have gone unheard.

Adding “who” to blame doesn’t seem like a move that would increase teamwork or improve morale in any setting. Is a software defect something that’s truly an individual error, or, like healthcare, are the results of a system the result of all of the interactions and different moving pieces and processes? Not being a software developer, I wonder, though, if Dr. Deming’s 94% principle would still apply… maybe 6% of bugs are caused by a sole person’s individual error?

The default view of blaming managers seems to be that an individual is the root cause of a problem unless proven otherwise.

I think the more correct view is to assume it’s the system unless proven otherwise – whether it’s a software bug or a medication error.

]]>http://www.leanblog.org/2012/07/blame-shame-is-shameful/feed/18Update on KaiNexus – Making Improvement Easier in New Ways & Placeshttp://www.leanblog.org/2012/04/update-on-kainexus-making-improvement-easier-in-new-ways-places/
http://www.leanblog.org/2012/04/update-on-kainexus-making-improvement-easier-in-new-ways-places/#commentsMon, 23 Apr 2012 09:00:08 +0000http://www.leanblog.org/?p=17038It’s been about a year since I started working with a software startup KaiNexus. We’ve made a lot of progress in that year, refining our product, signing on more early adopter customers, and adding more talent as we continue pretty much bootstrapping our growth. We recently released our first iOS app for our customers and we announced that Jamie Flinchbaugh has invested in KaiNexus, joining our advisory team. You can read more news here.

We have also compiled some aggregate statistics about our users – healthcare organizations that are using Lean and Kaizen methods to improve patient care and their organizations’ performance:

We are up to around 2,500 individual users across the eight medical centers that are currently using our software (including University of North Carolina, Centra Health, Univ of Texas Health Sciences Center at San Antonio, and more).

Our customers have completed over 600 Opportunities for Improvements (or OIs) since Jan 2011 and we are just scratching the surface of their capabilities for Kaizen-based improvement. Some of the results:

With Chrome, you have to hold down Command-Q for a second or two. If you tap Command-Q, you get the message shown in the pictures, reminding you to hold the keys.

I think this illustrates an example of a “Like Lean” concept – something that’s probably not driven by formal use of Lean methods, but just reminds us of Lean.

As I blogged about before, in this post Apple & Microsoft – Please Move “Control-W”!!!!, clever mistake proofing makes it harder for the user to do the wrong thing, without putting too many barriers in place for times when you are really trying to hit Command-Q.

What about the applications of this idea in software like EMR systems or in KaiNexus?

]]>http://www.leanblog.org/2011/08/safari-vs-chrome-error-proofing/feed/4Of Blogs and Books (or from Solo to Silo); The Need for Lean in Publishinghttp://www.leanblog.org/2011/07/of-books-and-blogs-or-from-silo-to-solo/
http://www.leanblog.org/2011/07/of-books-and-blogs-or-from-silo-to-solo/#commentsSun, 31 Jul 2011 09:00:09 +0000http://www.leanblog.org/?p=13833As a kid, I always enjoyed writing and, at one point, dreamed of being a baseball beat writer, like the father of one my best friends from elementary school who got to travel and cover the Detroit Tigers. I was editor of the high school newspaper and did very well in English and humanities classes, even though I ended up following the math and science path into engineering school.

I started blogging in 2005 and have produced about about 3000 posts. I’ve had one book published and I’m working on a second book – with a co-author this time, so let’s call that 1.5 books. It’s hard work writing a book. It’s also hard, at times, to make the transition from blog writing to book writing, especially because, as a Lean thinker, you have to wonder if the whole publishing model is broken beyond repair?

It can be hard to transition from blogging to book writing, for a number of reasons. I considered, on a number of occasions, going on “blog hiatus” for a while to help focus on the book. There’s both the time commitment of blogging (although it’s not as much time as people think) and the mindset differences.

I end up not really being able to put the blog aside because, for other reasons:

It’s a chance to practice writing about ideas in small batches, getting feedback and input from readers (like this post).

It’s mentally stimulating, so writing a blog post can serve as some practice swings in the on-deck circle before jumping into book writing.

I really enjoy the interaction with readers, seeing how others build on your ideas, how people challenge your thinking, or the “great post” comments via the blog or Twitter. You just don’t get that kind of interaction from a book (other than amazon reviews, emails, or failed attempts at building reader community)

One challenge is that blogging allows a more personal, less formal, and less polished mode of writing than a book would require. A blog post is often a stream of consciousness, while a book has to be structured, organized, and edited – keeping the reader (as customer) in mind to ask, “will they understand this?” and “will this make sense?” as you’re writing.

Below is a table that summarizes some of the differences between blogging and booking (OK, that isn’t really a word, but this is just a blog). I won’t elaborate on all of the table items unless you ask a question in the comments, I can answer or write a post elaborating on a comparison.

Blog

Book

Small batches

Large Batches

Dynamic / “Kaizen”

Fixed / static

Iterative / “agile”

“Waterfall” method

Informal

Formal

Solo

Silo

Multimedia (videos)

Text & photos

Low credibility?

High credibility?

Hyperlinking easy

Endnotes hard to follow up on

Indirect monetization

Traditional monetization

Temporary / transitory

Lasting / permanent

Interactive reader discussion

Little direct feedback

I’ve talked with a number of other lean authors and I think we tend to agonize over the same things and we get frustrated by the same things. This is regardless of the publisher, it seems. Traditional publishers all seem to have about the same model and processes.

For one, a book is a “large batch” of ideas, if there ever was one. Bob Emiliani, who self-publishes, maybe has the right idea by publishing a large quantity of relatively small books, in more of a continuous flow than writing one massive tome that can be intimidating or even hard to carry around (I’m resisting the urge to link to anybody on that last point).

The disadvantage of a large batch book is that you lose out on opportunities to get feedback and to iterative and improve the book, as a “lean startup” might do with it’s product and even it’s business model. Publishers take on a large part of the risk in deciding to go forward with a book project, not knowing if it might sell 150 copies or 15,000. I guess that’s why they earn more on a book than the author does. I’m not criticizing him for this, but Eric Ries chose to go the traditional publisher route with his upcoming book The Lean Startup.

When you throw a book out there, it’s pretty permanent. There’s not much opportunity to practice “kaizen” on a book, which is hard for a lean thinker. The first printing of Lean Hospitals had some defects and they couldn’t be corrected until the 2nd printing. With an e-book (yet alone a blog), you can release updated and improved versions as often as you want (which also seems like the “lean startup” practice of “continuous deployment” of new software code). I am now, almost 3 years after the original release, going to have a significantly improved (I think) and updated 2nd edition of Lean Hospitals coming out later this year.

In another parallel to software development, traditional book publishing is very much a “waterfall” development process where the book draft kinda burps along in a single big batch across the silos. I was dumbfounded with the first book when I was told to wait until the entire manuscript was done before throwing it over the wall to the publisher for editing. No small batches, no editing a few chapters at a time. My employer at the time actually paid for a wonderful editor to work with me in more of a continuous flow (Cheryl Fenske, I highly recommend her).

Editing, publishing, and printing the books is a “batch-and-queue” process if there ever was one. If it takes 6 to 9 months from manuscript submission to books being sold (I heard 10 months from another author recently), how much of that 10 months is actual “value adding” time? Most of it is waiting time. Ironic for lean books!

Now, none of this is a criticism of any of the individuals involved in publishing, especially the wonderful hard-working people who are involved in my book projects. But, much like the individual nurses in a hospital, they are great people working in an oft-fundamentally broken system.

The whole value stream needs to be rethought. The author who was told “10 months” lead time by a traditional publisher decided to go the self publishing route to get her material out there (something that can be done immediately with a blog!).

His new book is “Every Book is a Startup.” He’s not just writing a book, he’s experimenting with a new business model, taking lessons from “lean startups” and other cutting edge development practices.

You can buy the book today for $4.99. Well, it’s an e-book – and it’s only 2 chapters so far. But if you buy the electronic version of the book, you will get free updates as the book progresses. If you wait, the price of the e-book goes up over time up until the point the print edition comes out. I bought in early, so I’m like an “angel investor” in this project.

I’d encourage you to follow his progress. I hope he succeeds and I hope we have more innovation in publishing. I love books – which is exactly the reason why we need to save books by experimenting with new models, the way Todd is.

Maybe one thing that’s out of whack is the current “value stream”:

Pitch book –> Book gets acquired –> Write book –> Edit book –> Rework book –> Promote book –> Sell book

There are more silos than flow. The process of producing a book might even be more siloed than healthcare.

Maybe “sell book” comes WAY too late in the process. I love how Eric Ries says one of the main ideas of the “Lean Startup” is to not waste the precious time of software developers by having them build a product that nobody wants. So the “Lean Startup” aims to get to market early with a “minimum viable product.” That’s Todd’s first two chapters (or that’s his hypothesis that two chapters is both minimum and viable).

Eric Ries talks about “technical risk” (can you do it?) versus “market risk” (SHOULD you do it?). Most books “can” be written. But should they? If we move the “sell book” (to real customers, not just to the publisher) earlier in the process, is that better for everyone? If books had to be funded by pre-orders (sort of the way political candidates gauge their viability through early donors), would some authors not move forward if it appeared they didn’t have a market? Can you always predict the market, particularly for first time authors? How many authors would plow ahead with a book even if it seemed a market wasn’t there? There is a huge intrinsic motivation to write a book beyond the market and “ROI” and there’s less financial investment required in a book than a startup.

Should writers continue to go the traditional book route, when there are so many new ways to get your material out there faster in ways that can ensure (or improve) quality? Yes, saying you have a book published provides a certain cachet (but should it, if it’s all about the ideas?). Many of the income opportunities from a book come from indirect activities (like speaking and consulting), rather than the book itself. The future relevance of books and publishers?

Your thoughts? As a reader, how much are you willing to participate in experiments with new publishing and purchasing models? I’m going to invite other authors I know to chime in as well.

]]>http://www.leanblog.org/2011/07/of-books-and-blogs-or-from-silo-to-solo/feed/25Changes in Mac OS X “Lion” and Parallels to Workplace Changeshttp://www.leanblog.org/2011/07/changes-in-mac-osx-lion-and-parallels-to-workplace-changes/
http://www.leanblog.org/2011/07/changes-in-mac-osx-lion-and-parallels-to-workplace-changes/#commentsFri, 22 Jul 2011 09:00:08 +0000http://www.leanblog.org/?p=12274 It’s nowhere near as important as yesterday’s topic of employee and patient safety, but my last two days of using the new Mac OS X 10.7 “Lion” operating system made me think of some classic change management challenges that might be of interest to Windows and Linux users even.

If you’ve ever used a computer mouse with a scroll wheel, you know that the standard has been to pull the wheel back toward you to scroll down on a page. If you have used Lion or read reviews about it, you know that Apple has reversed that to a new default they call “natural scrolling,” which feels anything BUT natural, at first.

If you’re a heavy iPhone or iPad user, then this scrolling method probably feels OK and at least things are now “standardized” across your devices. That’s maybe well and good for Apple, but now we have a horrible lack of standardization across all computer platforms. I don’t use a Windows machine very often anymore, but if I relearn this Apple method, then Windows will feel backward… is that what Steve Jobs wants you think?

So…. the question is: do you fight through the change and retrain your brain, or go back to the old and comfortable?

You CAN retrain your brain, as one insightful comment on the BusinessInsider piece said, but SHOULD you?:

George Stratton performed experiments in the 1890s by provided subjects with mirrored glasses that invert *everything* and provide an image to your retina that’s actually the “correct” way. (If you’ll recall, your retina actually processes an inverted image.)

Apparently, people can adapt completely to this inversion of their entier world within 4 days to the degree that things no longer appear upside down and they have to focus to tell that anything is amiss.

I’m sure your “pliable” mind will find a way to outclass experimental lab subjects from the 19th century.

I’ve seen similar situations via Lean improvements and “kaizen” (continuous improvement) work in manufacturing AND healthcare settings. When team members come up with a better way of doing things, that new method can feel strange or uncomfortable at first. People might be very tempted to go back to the “old way of doing things.”

It’s debatable whether the new scrolling direction is really an “improvement” or if it’s just a “change.” Different isn’t always better.

Case in point, the Lean process at Starbucks, their so-called “beverage repeatable routine” (something I blogged about last year). The new process was deemed better (in terms of drink quality and barista productivity), but it (steaming milk one drink at a time) was a big change from the old method (steaming a batch of milk for a few drinks).

The new BRR was slower for many people at first, so they wanted to give up on it. Leaders and baristas often said that you had to power through the change and get comfortable with the new routine to realize the improvement. So do you struggle through a day or two of awkwardness to have months of ongoing benefit?

One lesson that my co-author Joe Swartz has contributed a concept from their experience at his health system for our upcoming book Healthcare Kaizen: Engaging Front-Line Staff in Sustainable Improvements – this idea is “7 days’ grace,” meaning that you give any new process 7 days grace before deciding, for certain, if it’s better or not. There are exceptions to that rule (if something’s obviously unsafe), but it’s a good rule of thumb. I’ve seen others make the same argument that you need to give “natural scrolling” 7 days’ grace, as well.

After about 24 hours of having Lion on my iMac (and using it quite a bit yesterday), I’m getting more comfortable with the “natural scrolling.” I’ve fought the urge to switch back. I still scroll in the wrong direction occasionally, but I do it less often than I did at first. I’m retraining my brain here… but again, I’m not sure it’s really “better.”

Microsoft Office users went through similar turmoil with the introduction of the “Ribbon.” I remember reading (but can’t find) quotes from the main designer who said their research showed that the Ribbon was easier to use than the old toolbars and menu combinations. That might have been true… unless you had been using MS Office for years. Apple might think “natural scrolling” makes more sense, but that might only apply to brand new computer users!

If Rip Van Winkle woke up from a long coma and you put him in front of a computer and said “move the page down,” what way would be “natural” to him?

So the question remains – go back to the old and comfortable or power through the change to reach eventual levels of new higher peak performance? When do you admit failure with a change and realize that no amount of powering through will get you to better performance? Ah, the real world challenges of the PDCA cycle!

]]>http://www.leanblog.org/2011/07/changes-in-mac-osx-lion-and-parallels-to-workplace-changes/feed/10Warning: You Can’t Even Draw a Map with this “Value Stream Mapper” Apphttp://www.leanblog.org/2011/07/false-advertising-alert-value-stream-mapping-app-from-designingkaizen/
http://www.leanblog.org/2011/07/false-advertising-alert-value-stream-mapping-app-from-designingkaizen/#commentsWed, 13 Jul 2011 23:57:06 +0000http://www.leanblog.org/?p=12173If you are a Twitter user and follow the #Lean hashtag on Twitter, you might have seen a lot of noise from a company called Designing Kaizen (@DesigningKaizen), claiming to have a web-based app for “value stream mapping” (see their app’s separate website here).

After getting a ton of evasive answers and non-answers about who the co-founders even are (through a series of Twitter messages and emails), the company refused to let me have a “free trial” of the software (yes, the purposefully denied my request for the trial that they offer on their website) because they feared my motives were “nefarious” (WTF?). So I took a hit for the team and paid $25 for the “software.”

I will continue this post over time with more details and backstory, but the app is worthless, in my opinion. You cannot even draw a rudimentary VSM with the current version. I agree with @KarenMartinOpex when she tweeted “even beta versions need to have minimum functionality! It’s a worthless tool at this point.”

More to come… be warned and do NOT spend your money there. The app is not at all what they describe in their marketing, nor is it what they show in the screenshots… and their attitude, via Twitter and email does not suggest that they are an earnest startup that is trying to improve an early version that they know is lacking. I am going to be protesting the charge (as I expected I was going to have to do) with PayPal and American Express.

Update #1: I am all for the idea that a “Lean Startup” might launch with “minimum viable product” functionality, but this “beta” does not at all live up to the promise of their hype. One could consider that fraud. I have tried communicating my concerns privately, via Twitter and email and have not been satisfied with their responses (and churlish attitudes) so I feel obligated to warn the Lean community.

Update #2: These guys claim via Tweets:

More great feedback on our Value Stream Mapping app from our users “The more I use it, more I see why the simplicity works” #LEAN#AGILE

Getting VERY good feedback on our Value Stream Mapping app from early users. Everyone seems to love the simplicity.http://bit.ly/mDgxTI+

That cannot possibly be real feedback. The app is lacking in these areas:

If you drag and drop a process box onto the drawing, you cannot rename it. You can spin it in circles, but you cannot name it anything other than “press.” They claim the ability to rename a process box is coming later this week.

You cannot delete an element other than clicking “undo.”

You cannot save a drawing.

You cannot share/email/print/tweet/fax a drawing (they have claimed this is a robust tool for sharing VSMs)

Update #4: Their original product concept was online video Lean training that “doesn’t suck.” They claim the following companies as customers:

Then, they changed direction and unveiled this “value stream mapping” app that doesn’t even allow you to draw a VSM. It sucks. DesigningKaizen said, via Twitter, that all other VSM software sucks too. My god, the arrogance.

The software does NOTHING to save, archive, etc. Their advertising claims are untrue and fraudulent. Here is a screenshot of their software (click for bigger view).

Update #6: Their “support” email told me:

Mark,

We do not have a refund policy at this time. We will be happy to forward your email to the
company founders. Thanks again for the feedback.

Thank you
-Designing Kaizen

Be warned.

Update #7: Their confirmation email says:

This membership does not auto-renew at the current price until the end of the Beta Program. You may cancel at any time. For cancellation info, please contact the Designing Kaizen support department at support@designingkaizen.com.

Problem #1 – the signup process did nothing to accept a recurring charge (nor was there any license agreement).

Bigger problem – their app does not require any sort of user login or password even.

Update #8: They claim (via Twitter, not responding to my email) that they have revoked my access to the app so they can process a refund for me.

Update #9: Part of the feedback I had given to them originally was that their planned pricing model of $50 per month was completely out of line with the market.

]]>http://www.leanblog.org/2011/07/false-advertising-alert-value-stream-mapping-app-from-designingkaizen/feed/33Blog Post About Preventable Errors Felled by Preventable Errorhttp://www.leanblog.org/2011/03/blog-post-about-preventable-errors-felled-by-preventable-error/
http://www.leanblog.org/2011/03/blog-post-about-preventable-errors-felled-by-preventable-error/#commentsWed, 02 Mar 2011 10:00:54 +0000http://www.leanblog.org/?p=9719So Monday’s blog post was about preventable medical errors – namely errors involving pharmacies giving the wrong meds or wrong doses to patients. That’s not rocket science – it’s a clearly preventable error. But it’s also something to not blame individuals for – it’s a matter of fixing processes and systems and creating environments where people can do the highest-quality work.

Ironically, my blog was down for quite a while that afternoon and you may have seen error messages like seen on the left.. Ironically, the downtime was due to what turns out to be a PREVENTABLE ERROR from my hosting company, GoDaddy.

I’ve been using GoDaddy since 2005. Originally, I started using them for domains and hosting because they were a local Phoenix company (back when I lived there). I’ve had my share of downtime and server problems over the years, but it’s a bit of a pain to switch hosting companies.

But between Monday’s downtime and other factors (such as their increasingly tacky Super Bowl ads) — it’s just not a company I want to do business with anymore. GoDaddy is cheap – but minding Dr. Deming’s advice, I never chose them on the basis of price alone. I’m going to be switching to a new hosting company, one that comes highly recommended by a tech person I trust. It will cost more, but the value will be higher (and defects fewer).

Normally, GoDaddy won’t really tell you what the problem was when you have site downtime, nor will they tell you exactly what they fixed. They consider this proprietary information (and I guess if you want to know, get your own servers and your own team).

Yesterday, they “fixed” my initial downtime (caused by a shared database server), but that “fix” meant only the front page of LeanBlog.org was working. Everything else showed a 404 error. But the content was not completely wiped out (I was able to see files and I keep my blog routinely backed up – a lesson learned from previous tech problems.

After calling back to GoDaddy, the tech support person investigated and found out (and surprisingly told me):

In the course of troubleshooting, they had renamed by .htaccess file (don’t worry about this detail if you’re not a techie).

After troubleshooting, the individual “forgot” to set the file back to its original name.

Since the file was essentially missing, the internet didn’t know how to find my blog pages (oops!)

This error was easily corrected – actually it was fixed by Cindy Closkey, the woman who designed and set up my WordPress blog. She managed to find and fix the problem while I was on hold waiting for GoDaddy.

Situations like this make me think – why does somebody forget? Checklists are often used as a means for not forgetting steps (airline pilots and increasingly in the O.R.). I have a checklist I use for my Podcasts, to make sure I don’t forget a step.

If there WAS a checklist and it wasn’t being followed, then our response should be to ask “why?” Why wasn’t it being followed? Lack of training? Was the checklist not sufficient? Was the tech support person under unreasonable time pressure (such as being on a “calls per hour” quota)??

The GoDaddy tech apparently wasn’t working off of a checklist – whether one generally exists or not, it wasn’t being followed in my case. This was human error and my response, as a customer, wouldn’t be to want somebody to be punished or fired. I’d want to know what GoDaddy is doing (or not doing) to prevent that same reoccurrence. They might be doing nothing or they probably wouldn’t tell me.

What do I know about software? Not much. But I’ll be there to talk about general lean culture and lean management methods, leading a discussion about the most appropriate way to learn from manufacturing practices – including my experience in helping healthcare people understand what applies and what’s transferrable.

Critics often mis-state lean principles or highlight cases of “lean done wrong” – or what has been described as L.A.M.E. or “Lean As Misguidedly Executed” an admittedly awkward acronym coined by this month’s speaker. Organizations that mindlessly force tools on employees, use lean to drive layoffs, or focus on speed over quality, give “Real Lean” (a term coined by author Bob Emiliani) a bad name.

Austin’s Lean Software community welcomes Mark Graban, a blogger, author, and consultant for healthcare organizations that are embracing the Lean philosophy. Mark will share his experiences working with hospitals after beginning his career in the manufacturing sector. Starting the talk with a vivid case example from a hospital, we will have an informal discussion about the role of systems and processes in delivering quality, as well as the critical nature of a management system and culture in lean transformation efforts. Expect a robust discussion about the proper, thoughtful transfer of methods from one industry to another, including software and “lean startups.”

In this podcast, we discuss their book and the “Customer Development” methodology that was first published in Steve Blank’s book The Four Steps to the Epiphany. This methodology is often used as part of the “Lean Startups” methodology and can be contrasted to a traditional “product development” approach.

The high-level model looks like this, moving from left to right:

The model is not so much linear as it is built on iterative loops, similar to a PDCA (or Plan-Do-Check-Act) cycle, as shown here:

Their book is available on Amazon in traditional paperback form, but if you want to buy a DRM-free PDF of the book, you can do so at www.CustDev.com, using my discount code: LEANBLOG to get 20% off.

We discuss points including:

What is the “customer development process”?

How does tie into the lean startup methodology and MVP (“Minimum Viable Product”?

How is this different than classical entrepreneurial product/service development or the traditional product development model?

Why is it critical to get out of the office to go do customer discovery?

What examples can you point to of companies or products that came about through this CDP?

Do you think this approach could be used to develop new products in older, larger companies?

If you have feedback on the podcast, or any questions for me or my guests, you can email me at leanpodcast@gmail.com or you can call and leave a voicemail by calling the “Lean Line” at (817) 776-LEAN (817-776-5326) or contact me via Skype id “mgraban”. Please give your location and your first name. Any comments (email or voicemail) might be used in follow ups to the podcast.

]]>http://www.leanblog.org/2010/07/this-yahoo-check-makes-zero-cents/feed/8Guest Post: Don’t Market Without Your Kanbanhttp://www.leanblog.org/2010/06/guest-post-dont-market-without-your-kanban/
http://www.leanblog.org/2010/06/guest-post-dont-market-without-your-kanban/#commentsSat, 26 Jun 2010 12:00:06 +0000http://www.leanblog.org/?p=6804Today’s guest blogger is Joe Dager, of the site Business901. He’s a very active blogger and podcaster and he’s very active on Twitter (@Business901) as well. Joe also takes the step of turning the podcasts inteviews into free e-books, which you can also download.

Joe also focuses quit a bit on Lean principles applied to sales and marketing, so here is his guest post on that theme:

Don’t Market without your Kanban

It is an honor and a great pleasure to have the opportunity to provide a guest post for Mark’s readers and the opportunity to participate with him. Thanks Mark and keep up all the great work you do in promoting Lean.

Most people think about the marketing process as a function of lead generation and follow-up. They envision the marketing funnel which creates an excellent visual image of collecting prospects and narrowing the field till you produce a customer at the bottom. This image is often times a fair reflection of your marketing budget. You spend most of your money reaching out to the masses. It is an expensive proposition and seldom produces measurable results. However, you can’t just cap the funnel because you never know where your next lead or sale will come from.

The job of marketing is to increase prospects, create better odds in obtaining a customer, and increase the number and dollars per customer. I believe marketing is also responsible for decreasing the dollars in obtaining a customer. I think these five parts can be best served through Lean and more specifically using a Marketing Kanban.

If you introduce Lean into marketing it will not take too long before you are creating a Value Stream Map of the process. Most marketing people do not look at marketing as a process so it may take a seasoned mapper to facilitate. Without drilling down too far in the process you can gather numbers of prospects in each segment and the conversion rates as they proceed through your value stream. Typically to accomplish this you must use only one marketing channel at a time or segment your list by a category. When first mapping the process, use the best defined channel so that you do not fight the process. The Value Stream Map created will be the outline for your Kanban.

Kanban has recently been used in Lean Software development as a way of limiting work in process and the amount of new work that is introduced into the process. As a result, work would be pulled from the previous stage as work is completed and levels demand. It emphasizes throughput rather than numbers. If you have read my previous posts, you would recognize the emphasis I put on throughput and the need for this to be monitored in the sales and marketing process.

I have included an example of a typical Kanban board for an internet marketing company (click for a larger view):

I have established an abbreviated beginning and endpoint for clarity. Someone visits your website, signs up for your e-zine and is channeled to your Auto-responder that induces them to a Webinar. What makes this procedure effective is those numbers in the parenthesizes, your number of prospects that are in that particular segment of your value stream. As tasks are completed either for groups, categories or even individuals they are queued for the next stage.

Adhering to this process limits your work in a given stage. In Lean manufacturing we believe that limiting your Work in Process (WIP) is a good thing. It is also a good thing in Sales and Marketing. If you control the amount of work in your process you will respond to your prospects needs more efficiently and as a result increase throughput. Improving throughput is the quickest way to accelerate sales and as a result increase revenue.

Utilizing the Kanban provides a visual indicator to your WIP and as a result demonstrates exactly what is happening within your marketing cycle. It also allows you to visually see where your constraint is in your process (I used a horizontal hourglass to depict the constraint in the picture). At that point you can allocate resources, create divergent paths, perform triage in the preceding queue or as we would say in the Theory of Constraint world; elevate the constraint.

Don’t think of Kanban as a planning tool; think about it as an execution tool. Improving your marketing process does not have to constitute wholesale changes nor increased spending. Getting more customers into your Marketing “Kanban” may not solve anything at all. Improving what you do and increasing the speed that you do it may result in an increase in sales and decrease in expenses. That’s marketing!

About: Joe Dager is the president of Business901 and provides direction in areas such as Lean Sigma Marketing and Achieving Expert Status. Visit the Business901.com website for a collection of podcasts and eBooks with noted Authors, Consultants and Industry Experts in the continuous improvement arena.

Don’t Market without your Kanban

Mark Graban is one of most prolific Lean leaders in the field. It is an honor and a great pleasure to have the opportunity to provide a guest post for his readers and the opportunity to participate with him. Thanks Mark and keep up all the great work you do in promoting Lean.

Most people think about the marketing process as a function of lead generation and follow-up. They envision the marketing funnel which creates an excellent visual image of collecting prospects and narrowing the field till you produce a customer at the bottom. This image is often times a fair reflection of your marketing budget. You spend most of your money reaching out to the masses. It is an expensive proposition and seldom produces measurable results. However, you can’t just cap the funnel because you never know where your next lead or sale will come from.

The job of marketing is to increase prospects, create better odds in obtaining a customer, and increase the number and dollars per customer. I believe marketing is also responsible for decreasing the dollars in obtaining a customer. I think these five parts can be best served through Lean and more specifically using a Marketing Kanban.

If you introduce Lean into marketing it will not take too long before you are creating a Value Stream Map of the process. Most marketing people do not look at marketing as a process so it may take a seasoned mapper to facilitate. Without drilling down too far in the process you can gather numbers of prospects in each segment and the conversion rates as they proceed through your value stream. Typically to accomplish this you must use only one marketing channel at a time or segment your list by a category. When first mapping the process, use the best defined channel so that you do not fight the process. The Value Stream Map created will be the outline for your Kanban.

Kanban has recently been used in Lean Software development as a way of limiting work in process and the amount of new work that is introduced into the process. As a result, work would be pulled from the previous stage as work is completed and levels demand. It emphasizes throughput rather than numbers. If you have read my previous posts, you would recognize the emphasis I put on throughput and the need for this to be monitored in the sales and marketing process.

I have included an example of a typical Kanban board for an internet marketing company. I have established an abbreviated beginning and endpoint for clarity. Someone visits your website, signs up for your ezine and is channeled to your Auto-responder that induces them to a Webinar. What makes this procedure effective is those numbers in the parenthesizes, your number of prospects that are in that particular segment of your value stream. As tasks are completed either for groups, categories or even individuals they are queued for the next stage.

Adhering to this process limits your work in a given stage. In Lean manufacturing we believe that limiting your Work in Process (WIP) is a good thing. It is also a good thing in Sales and Marketing. If you control the amount of work in your process you will respond to your prospects needs more efficiently and as a result increase throughput. Improving throughput is the quickest way to accelerate sales and as a result increase revenue.

Utilizing the Kanban provides a visual indicator to your WIP and as a result demonstrates exactly what is happing within your marketing cycle. It also allows you to visually see where your constraint is in your process (I used a horizontal hourglass to depict the constraint in the picture). At that point you can allocate resources, create divergent paths, perform triage in the preceding queue or as we would say in the Theory of Constraint world; elevate the constraint.

Don’t think of Kanban as a planning tool; think about it as an execution tool. Improving your marketing process does not have to constitute wholesale changes nor increased spending. Getting more customers into your Marketing “Kanban” may not solve anything at all. Improving what you do and increasing the speed that you do it may result in an increase in sales and decrease in expenses. That’s marketing!

About: Joe Dager is the president of Business901 and provides direction in areas such as Lean Sigma Marketing and Achieving Expert Status. Visit the Business901.com website for a collection of podcasts and eBooks with noted Authors, Consultants and Industry Experts in the continuous improvement arena.

]]>http://www.leanblog.org/2010/06/guest-post-dont-market-without-your-kanban/feed/8How I Broke My Blog and Fixed It… Lessons Learnedhttp://www.leanblog.org/2010/04/how-i-damaged-my-blog-and-fixed-it-lessons-learned/
http://www.leanblog.org/2010/04/how-i-damaged-my-blog-and-fixed-it-lessons-learned/#commentsMon, 26 Apr 2010 09:00:55 +0000http://www.leanblog.org/?p=6206For those of you who have had difficulty accessing LeanBlog.org for the past two weeks or so, I apologize. It’s been frustrating to me and I’ve gotten a number of emails from people who couldn’t get the site to load.

I think I finally got to the root cause, with the help of tech support from GoDaddy.com. Things should be back to a stable, “site loads every time” state. Update: there are still some problems today, so maybe we don’t have the root cause ID-ed.

I’ll spare you all of the technical details, but will share a bit to help other WordPress bloggers who might run into the same problems. I’ll also tie it to a core “Toyota Way” principle that I violated.

I switched from Blogger to WordPress late last year. WordPress offers many more features in an open-source platform. The number of features is both a strength and a weakness (as people can sometimes overload their site with tons of “plug ins” that add little value and slow down page loads dramatically).

I’ve tried to keep my site “lean” without a ton of extraneous plug-ins. But one extra “feature” that I turned on turned out to be the problem… we think.

I have been using one plug in called “TwitterTools” that, among other things, automatically generates a new ‘Tweet’ when I publish a new blog post. After a while, I decided to try another feature that’s shown below. The fact that it was labeled ” – Experimental -” was a red flag that I missed. Lesson learned.

Allows readers to catch up on links that I sent out that weren’t blog worthy (lots of good reading)

This plug in apparently caused a huge load on the database server as it ran throughout the week. Things would be worse in the early morning, right after my new posts are auto-published. The site often wouldn’t load, showing database errors or not loading unless you hit “reload” many times – and sometimes not at all.

After GoDaddy thought the problem was their servers for the first week, that through us off the trail of the real root cause. I was basically blaming GoDaddy (since their said it was their problem). Then, when they decided it was NOT their problem, better root cause problem solved happened.

GoDaddy helped me track down that my first call to tech support was on April 5. They kept better logs of all of this than I did. Thanks to them for that. They helped me did into the server files to see what I turned on or change on or around April 5. With a little trial and error (and recognizing an “experimental” feature shouldn’t have been used), we turned off that auto-tweet post. In hindsight, I was about to turn that feature off anyway, since the value seemed minimal.

Use only reliable, thoroughly tested technology that serves your people and processes.

Lesson learned. Read more about The Toyota Way in this great book: The Toyota Way by Jeff Liker.

In the course of the troubleshooting, GoDaddy recommended a site caching plug in that should make the site load faster than before. Basically, the cache means that the site doesn’t dynamically re-create each blog page each time a person loads it (that constantly re-creation could be considered the waste of “overprocessing”?). Now, after a page is rendered the first time, the second visitors and beyond get served a static version of the page, meaning it loads faster (until it’s updated with a new comment, for example).

So, for all of that hassle, my site is faster than before… and now that it’s unbroken, it should load consistently like it did before April 5. I will be more cautious in the future about not breaking things. Organizations and people do this all the time – we are wowed by some new technology or feature and we rush it into place. Sometimes bad things happen… mine is just a silly blog… the consequences in healthcare can be far more serious.

Update: things were still slow and bad this morning… I disabled the entire Twitter Tools plug-in, not just the experimental feature. Although the plug-in was there and working fine before I turned on the experimental feature, I’ll see how things work with the whole thing turned off.

]]>http://www.leanblog.org/2010/04/how-i-damaged-my-blog-and-fixed-it-lessons-learned/feed/3Parallels between “Lean Startups” and “Adaptive Design”http://www.leanblog.org/2010/04/parallels-between-lean-startups-and-adaptive-design/
http://www.leanblog.org/2010/04/parallels-between-lean-startups-and-adaptive-design/#commentsFri, 23 Apr 2010 09:00:29 +0000http://www.leanblog.org/?p=6147I’ve been a fan of the “Lean Startups” work of Eric Ries since last year, so I’m happy to be producing a free LEI webinar called “Lessons from Lean Startups,” to be presented live on April 28 at 2 PM EDT.

I found some interesting parallels between the methodologies, which surprised me.

In his talks about Lean Startups, Eric compares the approach to traditional “waterfall” software development and the “agile” methodology. As illustrated in this short slide show, the differences are about whether the problem and/or the solution are known.

You might also be interested in Eric’s recent post “Four myths about the Lean Startup,” which includes the myth that this approach is only about web-based software products. That’s why we think his webinar will have lessons that apply to innovation in any industry, even if you’re not a traditional startup.