Blog — Derek Huether

Kanban

Valentine's Day Pull System

Nothing is quite as romantic as sitting with your husband or wife, sharing a dinner of fondue.  Nothing, that is, unless you’re sitting with me.  I’m not a big fondue guy.  This is sad because my wife loves it.  She enjoys the whole process.  To counter that, I like my food to be given to me, already prepared.  I enjoy the results! So, leave it to me to point at the fondue pot half way through dinner and yell “Fondue is a pull system!  Fondue is a pull system!”

What is a pull system you ask?  Perhaps you’ve heard of Drum-Buffer-Rope or Kanban?

Businessdictionary.com defines it as a Manufacturing system in which production is based on actual demand, and where information flows from market to management in a direction opposite to that in traditional (push) systems.

The idea behind a pull system is to keep a smooth production flow.  For the sake of argument, let’s say N is a volume of work output.  It can be trouble-ticket call volume, software development, or hardware manufacturing.  Any of these work in the example.  If you and your team can consistently deliver quality N in a month, and keep a good work-life balance, you should know that a C-Level executive asking you to deliver N+10 is going to create bottlenecks in your process flow.  Your overall delivery velocity is going to slow and your team is going to work longer hours trying to deliver N+10.  This increase is unsustainable unless something changes.  You need to get back to N, either by cutting back the work, expanding the amount of people or things to complete the work, or find some efficiencies.

You limited your work in progress (WIP) for a reason!  If more is going into your process than is coming out, you’re going to accumulate a backlog.  For every unit exiting your process, you should have another unit ready to enter it.

For fondue, you limit your work in progress by the amount of long-stemmed forks you have to put into the pot (caquelon).  Before you start, you cut up all of your fruits, vegetables, meats...whatever you plan to dip.  That’s your product backlog.  You then begin dipping whatever you have, X at a time.  We had 3 forks each.  When the food is done, you take it off the fork, add another piece of food, and back into the pot it goes.  You can’t eat anything until it’s done with the process.

Am I a romantic buzz kill or what!?

Image: Recipe Tips

Week Retrospective 110130

news

Posts this week

I was a guest of AgileScout Live.  I really enjoyed myself.  Check out my video interview and retrospective.

I wrote about how I’m always looking for ways to communicate with team members, vendors, and customers.  When trying to understand the range of communications, I recently reassessed what I thought the opposite of communications was.  I no longer believe it is silence.  See some of my examples on why the opposite of communications is manipulation.

I loved this 10 minute video by Mike Cottmeyer, I had to write a post for it.  Though I frequent the LeadingAgile website, I had to do a little more than just retweet a link in support of this post.  For those who are new to Agile, Scrum, or Kanban, you need to carve out 10 minutes and watch this video on blending Scrum and Kanban.

After we published our first Scrum Posters, I was asked if we were going to create Non-Scrum Posters.  The answer is YES!  This week, we completed our (first) one-of-a-kind Pictofigo Project Management poster.  The Project Management Process Groups poster is now available!

Like so many this year, I got snowed in.  Unable to go into the office, I instead blogged about how our HOA handled the situation compared to the great snow storms of last year.

I recently read a pre-published copy of the Scrum Pocket Guide: A Quick Start Guide To Practical Agile Software Developmentby Peter Saddington of AgileScout.  I'm giving away one free PDF copy of the book.  Find out how to get registered to win.

Want to use the blog image for free? Find this drawing at Pictofigo

Blending Scrum and Kanban

Though I frequent the LeadingAgile website, I have to do a little more than just retweet a link in support of this post.  I've known Mike Cottmeyer a while now.  The guy just gets it!  For those who are new to Agile, Scrum, or Kanban, you need to carve out 10 minutes and watch this video.  In his own words, Mike says he 

blends concepts like Epics, Features, User Stories, Story Maps, Minimally Marketable Features, Scrum, Kanban, RUP, and even traditional SDLC to create a scaleable agile enterprise portfolio framework.

I wouldn't doubt that pretty much anyone who watches this video is going to have a light bulb moment. Recently, I've had quite a few people asking me about Kanban. Though I'm excited to tell them what I know and my approaches, Mike does an awesome job of both blending Scrum and Kanban and then communicating the approach in 10 minutes.

Head over to LeadingAgile and read some really great stuff. Also follow Mike on Twitter at @mcottmeyer

Web Interview Retrospective

Today, I was the guest for a live web interview with @AgileScout.  I'll admit, I'd never done a live (video) web interview before.  I did recently do an audio interview with @tykiisel & @RaeLogan.  I enjoy interacting with people but I usually do it one-on-one.  I rely a lot on audio and visual feedback to steer a conversation.  So, that made both interviews a bit challenging for me.  Since I had no visual feedback for the audio interview, I literally closed me eyes to stay focused.  To help me stay focused during the video interview, I closed all screens with the exception of the one of me on camera.  No, I'm not vain.  I just wanted to make sure I was centered on the camera.   So, let me say, I really enjoyed the interview.  Peter made it seem effortless.  There is a lot going on behind the scenes.  We talked before the interview to resolve technical issues and roughly go over the scope of the interview.  When you watch the interview, know two things.  [1] I was pretty excited and anxious.  I had already drank a pot of coffee.  [2] I was staring at a live feed of myself, not Peter.

ASL002 - LIVE with Derek Huether 2011.01.22 from Agile Scout on Vimeo.

The Retrospection

While we were doing the interview, my wife was in the other room watching the live feed.  After the interview, she said she thought I drank way too much coffee (during the interview) AND I moved around too much.  You know what?  That's not bad feedback!  If she had walked into the room and told me what I was doing (during the interview), I would have probably stopped (drinking my coffee).  Though it would have been a momentary interruption of the interview, it would have been a perfect testament to the need for short feedback loops.  THIS is a perfect example of why you want co-located teams.  THIS is a perfect example of why you have daily stand-ups.

Shorten the feedback loop and you will have less waste and deliver more value.

Thank you, again, to Peter Saddington for being an independent voice democratizing Agile.

2011 Resolutions WIP

2011 Resolution KanbanLast night I submitted my speaking proposal for the Great Lakes Software Excellence 2011 conference.  The title of my talk is Breaking the Law of Bureaucracy. A little back-story:  One of my "Epic" stories (Resolutions) for 2011 was: As an agile proponent, I want to articulate the values, principles, and methods of the agile community to the traditional project management community, so there will be more mainstream adoption of agile.

What's my acceptance criteria for this Epic?  I must appear (speak) at no less than 4 conferences.  I must write at least 1 article to appear in a trade publication. I must publish my book (Zombie Project Management).

As you would expect, I broke the epic down to multiple (actionable) stories and prioritized them.  The GLSEC is number 2 of my 4 conferences.

Below is the abstract I submitted as part of my proposal.

Abstract - Breaking the Law of Bureaucracy

The law of bureaucracy exists in all organizations.  The larger the organization, the stronger the law. Examples of this law, in a business organization, would be those who work and sacrifice to bring value to the customer, versus those who work to protect policy, process, and procedures (regardless of use or value). The Law states that in all cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions.

Top-down organizations are suffering from the worst case of egoism: When each person acts to create the greatest good for himself or herself.  When the organization and its employees make decisions merely to achieve individual goals (at the expense of others), they lose sight of the original organizational vision or goals.  The law of bureaucracy can be broken, through team empowerment and altruism: From this perspective, one may be called on to act in the interests of others, even when it runs contrary to his or her own self-interests.

This talk will introduce ten characteristics of servant-leadership, to help those who currently manage others, to break the law of bureaucracy.

Like the image? Find it at Pictofigo

Zombie Tug of War

Zombie Tug of War

This week I'm in an all-out tug of war with the zombies.  Just short of getting hostile with the lot, I figured writing a blog post would be more cathartic.  I'm going to rant about enterprise tools and how I see them fit into the world of business.  I've been asked many times what products I would suggest to satisfy different needs.  I'll admit, I'm pretty passionate about some of the tools I use.  I love Evernote.  Why?  My memory sucks!   If I can get my thoughts into Evernote, I know I'll be good.  I also love using AgileZen.  I know, you've heard me talk about them before.  I keep a physical Kanban and a virtual one.  It's what I describe as both lightweight and elegant. It just works!  One more little app you may of heard of that I love is Google docs.  I like the fact that I can edit my documents anywhere and then share or collaborate on them with other team members. There are 3 primary commonalities that I can note about these 3 applications.  [1] They are super easy to use,  [2] either free or very affordable, [3] they help me save time.

So, what are the zombies taunting me with?

I'm working with a customer who is on a Novell network, uses Groupwise email, and has the poorest implementation of Microsoft SharePoint I've seen since I was introduced to SharePoint 5+ years ago.  None of these applications are necessarily bad.  But, when it comes to this bastardized configuration I'm currently dealing with, I get the feeling the only reasons these apps are being used is because really good salespeople sold a few zombies on these half-baked solutions.

Before you spend tens of thousands of hard earned dollars on the next "silver bullet", ask yourself why you need the product.  Are you trying to fix a process?  If so, I think you'll end up with an expensive crappy process.  Let me be very blunt.  Enterprise software will not fix a crappy process! Enterprise software is for making a refined process more efficient.  When I started advising this customer over two years ago, a vendor had just sold them on a deployment of MS SharePoint with Project Server.   Why?  So the customer could internally track time being billed to different work packages.  That's it!  What I found odd was the customer didn't have an existing way of internally tracking the time.  So, instead of having people fill out Excel spreadsheets to get them started, they just went for a solution that would solve all of their problems.  Have you read that promise before?

The result?  A solution nobody uses.

Score: Zombies 1 / Humanity -$50,000

My apologies for the negative nature of this post.  Happier posts are on the way!

[VIA: Oxford Dictionaries]

Like the image? Find it at Pictofigo

One of My Resolutions

When PM Bistro asked if I would write a blog post for them, I was happy to oblige.  You can read the original post here.  For a little background, I was asked to write about a particular work-related goal I have for 2011.  I actually have several (goal) resolutions for 2011.  I keep them on my Personal Kanban so I can be reminded of them daily.  Because they are so big, I consider them Epics.  I then break them down into "actionable" stories.  Anyway, here is the blog post.  I hope you enjoy.


When asked to think about a particular work-related goal I made for 2011, I knew it would be easy to list but harder to explain. It’s common to say “how” or “what” you’re going to do. It’s a whole other thing to say “why” you’re doing it.

The goal I have is: To articulate the values, principles, and methods of the agile community to the traditional project management community.

Why: I’ve been working in the Industry for some 15 years. I’ve seen and been involved in the best of projects and the worst of projects. Over time, I’ve seen more and more methods defined and practiced. I’ve seen people in our profession leverage these methods in the hopes their projects would be successful. It is my fundamental belief that all project managers and leaders should know all of the options available to increase the probability of project success.

How: About 5 years ago, I read the Agile Manifesto. Though it was written for software development, I discovered I could leverage some of the principles it defined in other areas. I then discovered the agile community. These progressive thinkers spoke less of maintaining the status quo and more of introducing new ways of doing things or refinement of the old. Though there are “agile” processes to follow and disciplines to uphold, many in the traditional project management community seem to be unaware of them.Some still think agile lacks both process or discipline. I hope to change that. I plan to tweet, blog, publish, speak, and mentor at every opportunity.

What: I had the pleasure of attending the PMI North American Congress in Washington DC this last year. Though I saw a very strong visual representation from the Agile Community of Practice, when I spoke to the random attendee, they had no idea what Agile was about. As I interact with both new and seasoned professionals of our Industry, I want them to know how agile can work in concert with their traditional methods. I want to see more projects succeed.

Like the image? Find it at Pictofigo

Pomodora Relationship

I have a dirty little secret.  I have an on-again off-again love affair with the Pomodoro technique.  Though I deal with a wicked case of ADD, I seem to keep it in check, thanks in part to my Personal Kanban.  The other method I use, though I admit not as commonly, is a pomodoro timer.  When things get really bad, I break out the timer.  And ya know, things get back on track!  You'd think I would learn. If you find yourself reading this blog, you'll find that I'm a proponent of  using simple techniques to get things done.  If you're looking for me to do a deep dive on policy, process, and procedure, you're in the wrong place.

So, how do I get some of my work done?  [1] I limit my work in progress (WIP) and [2] I limit my time (timebox). When I do both, I tend to stay focused and deliver more. The pomodoro technique, like other techniques I like, is pretty darned simple.

So, let's talk about my Piggy Pomodoro!

  1. Choose a task to be accomplished
  2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
  3. Work on the task until the Pomodoro rings, annotate the task you were working on
  4. Take a short break (I take 5 minutes)
  5. Every 4 Pomodoros take a longer break (I take 10 minutes)

As part of this process, I'm moving tasks on my Kanban from Backlog to Work in Progress.  If I take a break, I move it to Blocked.  When I return, I move it back to Work in Progress.  This allows me to visualize what I'm working on and know what I was working on before my break.

Have a Kanban or Pomodoro story?  I would love to hear it.

Why do I use a Piggy, you ask?  Because tomatoes give me gas and Chickens would just be wrong.

Image:  Amazon