New to agile? Lean principles can help!

Ever see a trash can look like that?  I know I have – plenty of times.  I have 3 kids so I sometimes even see it in my own house!  It is amazing how kids can walk right past a full trash can and decide it is not in their best interest to empty it out!  But I still love them 🙂

Anyway, back to the point of this blog post…  Too often our process, even our agile process, of software development looks like that trash can, and like my kids we all walk right past it without emptying it.  We tend to forget some of the basics about agile because we are focused on the process and doing the various practices well rather than taking time out to remember the principles that drive those practices.  Or better yet, we should be LIVING those principles by BEING agile, not doing agile.  In order to do that we really need to know and live by lean principles.  I’ve touched on some of them, but in this blog post I want to say a little bit about each one and why I think it is vitally important.

Too many people see the lean principles and they zero in on just one.  Below is the entire list as given by Tom and Mary Poppendieck in various presentations, books and on their website.  I know other people see the lean principles differently, but I’ve always been able to make this list of 7 work, so I prefer to use it.

Lean Principles

1. Eliminate Waste
2. Build Quality In
3. Defer Commitment
4. Deliver Fast
5. Improve the System
6. Respect People
7. Create Knowledge (and be able to use it!)

These 7 principles all work together to help teams “think right” when they are being agile.  Because I believe these principles give a solid agile foundation I teach them during the first few hours of almost every course.  I’ll write a simple paragraph about each to hopefully lead you down the right path when you start trying to use them.

Eliminate Waste

Sounds simple, but can be exceedingly complex because we often think incorrectly about waste!  As a simple example consider fixing critical product defects.  Is that waste?  Believe it or not, the answer is yes, it is waste!  Why?  The definition of waste is “anything which doesn’t add value” where value can be defined pretty broadly (customer value, internal value, etc.).  Fixing a critical defect is not adding value because we are spending resources fixing something which should have been correct originally.  As a result we aren’t generating any internal or external value which would be incremental to the initial expectation of a functioning system.  Waste comes in many forms though.  Read my blog post “New to agile? Remember to eliminate waste” for a lot more information on this one.

Build Quality In

This is very different from “testing quality in” which is the normal way quality is accomplished.  Building quality in means quality is accomplished at every point in the process.  Quality is accomplished by PREVENTING defects rather than finding them.  Ok, that sounds odd because obviously a tester can’t stop a developer from actually creating a defect.  But that isn’t quite what this means either.  It really means preventing defects from getting further along in the process.  While a tester can’t prevent a developer from creating a defect, they CAN prevent the developer from checking in code with that defect.  They can also keep that defect from getting further downstream because it has already been detected.  To get the most out of this it is necessary to have a significant test-driven development practice including both Unit Test-Driven Development (UTDD) and Acceptance Test-Driven Development (ATDD).  Google either and you will find many articles explaining further.

Defer Commitment

No, this doesn’t mean telling the business a release date a day before it happens.  That’s not deferring commitment, it’s just stupid.  Deferring commitment means making decisions at the point in time they make the most sense.  This can be done as long as not making the decision doesn’t cost time or money or otherwise endanger the organization.  Unfortunately the software project culture is based on other engineering disciplines where it is often possible to gather enough information up front to make meaningful decisions.  In software it is nearly impossible to get enough information to make all decisions accurately, therefore deferring some decisions makes sense.  Next time you are making a decision, the first thing you should decide is whether the decision really needs to be made right away, or if it can be deferred.

Deliver Fast

It is important to point out this does not mean to hack.  It means to deliver as quickly as possible with high quality.  A phrase I like to have teams remember is “You want to be able to deliver value as fast as possible now, and even faster in the future.”  You can’t do that if you aren’t careful about how you are adding value!

Improve the System

Improve your software development system.  It would be even better if you could improve your entire “value stream” including things which are done upstream and downstream from the development process itself.  But usually agile teams aren’t allowed out of their specific area.  That limitation should not stop you from trying to have your team continuously improve.  A couple of things to think about in this area are metrics and flow.  How can we measure things which make sense to drive the behavior we want?  How can we increase our ability to deliver value faster?  Keep improving in your answers for those questions and you will continue to improve.  As I’ve said before:  A team which gets 1% better every 2 week iteration will be 25+% better after a year!

Respect People

I believe this is an area where almost all software development companies fail miserably.  I say this because of the way most development organizations run projects.  Usually there is a nice plan in place to have development take a certain period of time followed by a certain period of time for testing.  Unfortunately development usually takes too long which means testing gets squeezed.  Is this respecting the testers?  Is it respecting the customers?  (Hint: If you think the answer to either question is “yes” then please get some professional help!).  An organization needs to respect all of the people in the organization.  The people in each department need to respect the people in other departments.  The organization and departments need to allow people to work in a way which lets them take pride in their work.  A bit more on this topic can be found in my blog entry “New to agile? Remember to respect people”

Create Knowledge (and be able to use it!)

Don’t lose necessary knowledge!  Don’t store it in a disorganized way!  Don’t make people waste time hunting for information which should be readily available!  Yes, I used exclamation points!!!  This is important not just for productivity, but for the health of your computers.  Surveys show 13% of laptops are damaged due to “worker anger.”  I believe it is in response to being frustrated by not being able to find information fast enough 🙂  Seriously, how frustrating is that?  One thing which usually helps is to use a “point of entry” approach to knowledge.  By this I mean having a single place where “finding information” starts.  From this single entry point people can be led to the proper location for certain types of information.  This stops people from searching all the wrong places first.

Now that you know a little bit about all of these, ask yourself a couple of simple questions:

1. Which principles are embodied in the agile practice of building a product using iterations?
2. Which principles are embodied in the agile practice of having a daily stand-up meeting?

If you do this honestly you will see that all of the 7 principles could be embodied in both of those practices.  In fact, this will generally be the case for all agile practices.

Now comes the good part though…

When in doubt, go back to the principles!

When you have a difficult problem that keeps coming up, ask (preferably as a team rather than an individual) which principles are we violating and can we do anything about it?  You’ll be amazed how much improvement you can make when you start paying attention to these 7 simple principles.

I’ll be writing more on some of these topics in the future.  This blog entry is just a taste because entire books have been written on the topic.  Go to www.agileall.wpengine.com/books for the Poppendieck books on lean.  You can also go to www.poppendieck.com to see more from them on these topics.

Until next time I’ll continue to teach teams these 7 principles because I believe strongly they are one of the keys to Making Agile a Reality^®