Lean Archive

0

Reading about Process Improvement

Reading Books Over the weekend, I found myself trying to read a physical book about systems analysis while listening to a book on operational process improvement.  I’m not going to go into the physical book because I am so impressed with the audio book.  I guess it wouldn’t matter if it was physical, digital, or audio.  It’s just a really really good book!

It’s titled: The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt (yes, if someone clicks on that link and buys a book, I would get credit)

Though the story reads like fiction, in its introduction of characters and story, it does an amazing job of introducing concepts to the reader.  The main character manages a production plant, where everything is always behind schedule and things are looking pretty bad. (Sound like any projects you know?)  The production plant is doing so poorly, the company has given the main character an ultimatum.   With a threat of closure, the plant has three months to turn operations from being unprofitable and chronically late on deliveries to being profitable and successful.  In the book, we are introduced to the Socratic method. Throughout the book, a character poses questions to another or a member of a team, which in turn causes them to talk amongst themselves to come up with a solution to their problem.

Because the book revolves around manufacturing and not application development or project management, there are a few dotted lines that need to be drawn.  But, overall, it really got my wheels spinning.  It doesn’t matter if you’re using Kanban or if you’re in any type of management position, I would recommend this book.

One quote really stuck with me

Intuitive conclusions (common sense) are commonly masked by common practice

Process Improvement

The following lists some of the ways that processes can be improved.

  • Reduce work-in-process (WIP) inventory to reduce lead time
  • Add additional resources to increase capacity of the bottleneck
  • Improve the efficiency of the bottleneck activity to increase process capacity
  • Move work away from bottleneck resources where possible to increase process capacity
  • Increase availability of bottleneck resources to increase process capacity
  • Minimize non-value adding activities to decrease cost and reduce lead time

Like the drawing? Get it free from Pictofigo

Popularity: 1%

Tags: , , ,
2

Intro to Value Stream Mapping

The Critical PathI’m in the process of doing a Current State Value Stream Mapping (VSM) for the PMO. The big questions are, based on the current state, are there areas we can improve? Can we eliminate any waste (or increase efficiencies) from our current processes? The answer to both questions is YES.  Everyone should be reviewing there processes on a regular basis, giving themselves opportunities to become more profitable.  Though I’m advising a Federal Government project, the American people still deserve the most bangs for their bucks.

Today is the last day for one of my projects.  It is done.  Now is the time to see what worked and what did not.  We now need to do a retrospective and see if we learned any lessons from the last go-around. I will give the vendor credit on this particular project. This small cross-functional team did a better job than others, in part, because we had a daily 15 minute status meeting. (otNay allowedway otay entionmay Agileway). One of the other program teams wastes so much time because they only communicate once a week in a 3 hour meeting.  I hope my VSM will change that.

For those new to Value Stream Mapping, I included a 5 minute video that does a pretty good job of explaining its value.  See how a process that took 140+ days to complete was shortened down to just 30 days.

If you don’t have your current process documented, you need to do it!  As the saying goes, “What cannot be measured cannot be improved”.  Don’t be complacent and accept the waste.  Times are tough and we need to think lean!

Like the drawing? Get it free at Pictofigo

Popularity: 1%

7

Mura Muri Muda

I had the wonderful opportunity to meet and listen to Jeff Sutherland a few days ago. For those who do not know who Jeff is, he and Ken Schwaber created Scrum.  It was really quite amazing to listen to him speak.  The topic of the talk was Using Scrum to avoid bad CMMI implementations.

Scrum and CMMI are often at odds with each other. What does each approach bring to the table? Scrum promotes the idea of focusing on the most important product issues first and supports frequent communication. CMMI brings a structure that promotes consistency and discipline to avoid waste and rework. So, why should we try to combine both approaches? Is this combination a good idea?

Mura Muri MudaThis post isn’t going to go into detail about the entire talk. Rather, there were three words Jeff said that had me scrambling for my pen. “Muri, Mura, Muda“.

The Toyota Production System identifies three types of waste (Muri, Mura, Muda).

Muri (無理, “unreasonable”) is a Japanese term for overburden, unreasonableness or absurdity.

Mura (斑 or ムラ) is traditional general Japanese term for unevenness, inconsistency in physical matter or human spiritual condition.  Waste reduction is an effective way to increase profitability.

Muda (無駄) is a traditional Japanese term for an activity that is wasteful and doesn’t add value or is unproductive.

With commercial organizations, I consistently see two primary goals:  [1] Make Money and [2] Save Money

But as you drill down into an organization, these two goals are not as obvious.  So, to address this, I rewrite the two goals as:  [1] Deliver Value and [2] Eliminate Waste

When we reach this point, muri, mura, muda come into play.  In your day-to-day activities, are there areas you can make more efficient or improve?  Do you really need to go to that meeting or can someone just email you an agenda before and minutes after?  In your project lifecycle, do you really need a 10-step process workflow or can you achieve the same goal with just 5 steps?

Here is a practical exercise:  Make a list of activities you have to do this week.  Ask yourself why you need to do each of those activities. Do they map back to the core mission of your company?  Should any of these activities be postponed until the goal is clarified?  Should you just NOT do one of them?

I have a daily meeting at 10:00.  Why?  I fill find out what the team did yesterday, what they are doing today, and what impediments they have.  My job is to help facilitate their activities and remove roadblocks.  This 15 minute meeting is a keeper.

I have an invite to the Finance Working Group meeting on Monday. Why? Hmmm.  That’s a good questions!  The meeting is scheduled for 1hr.  I know that it traditionally lasts 2-3hrs.  No invoice was attached in the meeting invite.  That leads me to believe they are going to review 500 pages as a group.  Though it’s necessary to review the invoice, this is a very inefficient way of doing it.  I will send a request for a copy of the invoice to review when I can.  I will decline the meeting invite.

Of those activities on your list, highlight which ones just don’t sit well with you.  Really listen to your gut. Are any items on your list an activity that does not directly translate into providing value?  Are any items on your list going to somehow cut into your personal life?  Are any items on your list literally a waste of time, money, or energy!?  If you can scratch any one of these items off your list, you are on the road to Kaizen (改善) (English: Continuous Improvement).

Before you accept that next task or meeting invite, ask yourself if there is a better way.


HT: Wikipedia

Like the drawing?  You can download it free at Pictofigo

Popularity: 3%

1

Is Santa Agile?

Tony Askey of Post-it Projects asked  ”[Are] Santa’s elves using Kanban in the toy shop!!??

I can see it happening.  But doesn’t it sound a little disturbing hearing about Santa controlling his WIP?  What are the elf labor laws like at the North Pole?

Brian Bozzuto at Big Visible asks, does Santa draft his “naughty and nice” list up front and implement change control or is he Agile?

I hummed a few bars and thought “Making a List, Checking It Twice…”  My answer: Santa isn’t necessarily using any kind of Agile process for this.  I do think it’s a draft.  He created the (draft) list, it’s tested.  Since the song says he does it twice, perhaps he is doing both a unit test & acceptance test.  Once the list is baselined, I bet he does use change control.

Brian’s response was then: If he’s checking his list twice, why doesn’t he automate?

Oh man, I think Brian has just stumbled onto something.  If Santa isn’t using automated tests, I bet he’s delivering a lot more presents to kids who should be getting coal.  I think the automated test scripts should be ran daily, right up to deployment.  Even if Santa is not doing automated testing, he should be leveraging some kind of automated deployment. Seriously, you think Santa should delpoy all of those toys around the world in one night without some kind of automation?

Though you don’t think “Lean” when you think Santa, the guy has be to be leveraging some kind of Agile processes.

Popularity: 1%

Tags: , ,
0

Building on failure and action versus motion

I just listened to the 37signals podcast.  It was a playback of some of the brainstorming sessions leading up to the release of the book REWORK.  For those who don’t know me, I’m a complete 37signals fanboy.  They just “get it”.  I don’t know if it’s their no BS approach to business or that they have great products.  But, I’ve found many of the things they created, do, and say helpful in multiple areas.  It doesn’t matter if you’re an entrepreneur or a project manager.  They have something for everyone.

There were two things from the book I wanted to note today.  First, they talked about building on failure versus building on success.  My takeaway is if you want to reach a goal (insert your project or product here), it is easier for you to build upon small successes than to fail and start over. Example: When you’re [creating] an [product] for a customer, wouldn’t you rather deliver small chucks and get acceptance from the customer along the way, rather than offer a big reveal at the end and risk delivering something they don’t want?  If you fail, you have to start all over.  Out of a million possibilities, you’ve narrowed it down by ONE.  I agree with the PDCA approach (Deming cycle). You should refine, deliver, refine, deliver.  Don’t forget to deliver.  If you get something 99% done, you still have nothing.  Deliver something (regardless how small), get acceptance, and repeat.

The Second thing I wanted to note from the podcast was the mention of an Ernest Hemingway quote

Never mistake motion for action

Things don’t have to be hard.  If your business [process] requires you to do wasteful (time or money) things, don’t do them!  You should be doing things because they provide value (save time/money or make money).  The rest is just fat and you need to trim the fat from every business [process].  Make your [processes or products] as lean as you can without hitting the bone.  Only then can you have a good baseline.  Only then can you build on top of something.  Anything beyond that and you may be wasting time and money compensating.

Do something because you need to do it.  Don’t do it because you feel obligated.  Do you need to go to that next meeting because there is valuable information being communicated?  Or rather, if you don’t go it will give the impression that you’re being antisocial?  Meetings are perfect examples of an crime perpetrated by people that don’t have enough actual work to do or those to feel obligated by people that don’t have enough real work to do.

You know why I don’t check my email every 5 minutes?  Because I have things I need to get done for the customer!  Sending me pictures of LOLcats is not going to help me get that work done.  Equally, expecting me to respond to that email within an hour of you sending it just reinforces the fact that you have more time on your hands than me.

Image courtesy Flikr: Travis S.

Popularity: 1%