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.agileforall.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^®

Related posts:

1. New to agile? Keep it very simple When dealing with an agile implementation, particularly in the case of a...

One of the Lean Principles is “Respect People.”  I think it may be the most important lean principle.  When I teach a course and get to this principle I tell people I have yet to see any organization which does this really well.  They are all shocked to hear this so I go on to tell them why.  First of all, respect of people is not all about making sure employees have sufficient compensation and benefits.  In fact most salary surveys show being able to take pride in their work as the number one job satisfaction criteria.  In other words, respect the employee’s contribution and it will mean more than a few extra dollars!  But lack of respect is much deeper than just job satisfaction.

I ask groups about how their development process dovetails with release.  Almost every organization ends up cutting corners in testing in order to meet an arbitrary date.  Is that respectful of the people who do the testing?  Is it being respectful of the customer who pays for the product?  Is it even being respectful of the developers who rely on testing in the process to ensure the quality of their software?  What about when we give unrealistic delivery dates?  Is that being respectful of everyone on the team?  I sometimes hear managers tell me things like “If I didn’t give them an unrealistic date then they wouldn’t work as hard.”  Really?  What is going on in software development when we have to give unachievable goals in order to hit some other unknown date?  Clearly we aren’t respecting our teams enough to trust them to deliver.

As I said earlier, respecting people is vitally important.  One exercise I do in my courses is to have the attendees break into small groups and imagine they have the magic wand that spreads respect wherever they wave it.  The group then discusses where they would wave the wand immediately and what results they would expect after the wand did its magic.  The results are often startling discoveries of significant team and organizational improvements which can be easily achieved just by working differently!

At your next iteration retrospective you might want to suggest improving in the area of respecting people.  Use the group exercise above to uncover hidden areas for improvement.  Below are some examples from real classes:

• Wave the wand at the developers so they would understand the need for them to truly support acceptance test-driven development.  Without their support the testers are left to do manual testing which is inefficient and not a good use of time.  With developer support we could do far more testing and we would be working more closely with developers to ensure quality of the product.
• Wave the wand at the product council so they would understand the need for overall portfolio management with clear priorities.  Using the priority 1, 2, 3 system is not working because we always work on priority 1 items and we never know their relative importance to each other.
• Wave the wand at our team because we sometimes forget how hard it is to get real answers from our customers.  Once we start regularly delivering on our commitments our product people can build trust with our customer base and we can all start to work in a way which is much more agile.
• Wave the wand at our project managers who continue to try command and control in an agile environment.  Command and control doesn’t work in agile because of the speed and need for the team to be empowered to make reasonable decisions and solve difficult problems with guideance rather than interference.

As you can see, respect issues are everywhere.  Most teams would benefit from trying to improve respect over the course of a few iterations.  Try it and see where you end up.  I’m sure you will be pleasantly surprised.

Until next time I’ll be respecting people because it is a big part of Making Agile a Reality^®!

Related posts:

1. New to agile? Remember to eliminate waste When I teach any agile course I start out with the principles...
2. New to agile? Remember how to say “No” No.  Only two letters.  Very simple word.  Yet for some reason, with...
3. New to agile? Remember the power of automation As this blog entry is published I am teaching an agile/scrum course...

When dealing with an agile implementation, particularly in the case of a new agile team, we often make things too complex and difficult.  We tend to keep putting band-aids on the process until we have something that is overly burdensome and no longer useful.  I’ve now seen enough of this to know there needs to be an intervention!  So take a deep breath, relax and read how to simplify your life on an agile team.

The starting point is the 6 basic principles of what I call “Simple Agile.”  I mentioned I was going to be doing a talk for Agile Denver on this topic and I would follow-up with another blog post about the specifics, so here it is:

6 Principles of Simple Agile 

Let’s take them one at a time, but very quickly.  I’ll probably write more about each of these in a future blog entry.  Be sure to leave comments or questions if you want further clarification of any of them.

1. Collaborate

Very simply, “collaborate” to me means to communicate effectively with each other.  There is no place on an agile team for a lack of communication.  Communication needs to be as near to real-time as possible, and hopefully as high bandwidth as possible.  In rare cases people on the team may not choose to use the best communication method available, but that should be the exception not the rule.

2. Work together

If we communicate well then we need to follow it up by working together.  For example, a Product Owner, tester and developer have all agreed on what a specific story means.  This does not imply the tester and developer go off their separate ways.  Work closely together to make sure the shared understanding stays shared.  I’m not sure what to call this other than “pairing.”  I’m also in favor of pair programming for a lot of reasons.  It has been proven pair programming signficantly increases product quality without affecting productivity.

3. Honor priorities

Always, always, always work from a RANKED product backlog.  You must work on things in the order they appear in the backlog unless there are exceptional circumstances (like a story is too big to fit in the iteration so it is deferred until the next iteration in favor of a smaller story now).  Everyone should follow the rule “the next thing you do should be a task in the highest priority story you can work on.”  This implies more than one person will work on a story (swarming).  It should also mean teams have fewer open stories (limiting work-in-progress).  This will lead to delivering the maximum value every iteration.

4. Respect the customer, the process, the product, the team and each other

When does a customer know exactly what they want?  When they see it of course!  When do they know how they feel about your product?  When they see it.  Let them see it more often, gather feedback and utilize the feedback.  Respect the process by sticking to it and holding each other accountable for process success.  Respect the product by reducing complexity and technical debt.  Respect the team by not having unrealistic goals, being sustainable and letting them solve their own problems.  Respect each other by working together toward success and supporting each other at all times.  I could go on and on with this topic (it is a personal pet peeve), but I won’t.  If you get a chance, do the following exercise: On a piece of paper write down all the different ways respect of these things could be improved, and next to each write down a list of the downstream effects such a change would have.  You’ll be amazed how much difference this can make toward success.

5. Do the simplest thing that works – then stop

Everyone in the product development industry has a tendency to do too much with every feature.  We even have a name for it: goldplating.  It is very easy to fall into doing it.  Ever hear something like “While I was in the area I did XYZ.” or how about “The story didn’t say to do this, but I knew the user would want it so I did it.”  Both statements should never be heard on agile teams.  We should do the simplest thing that works – then stop.  Ask the customer (remember we are respecting them by getting them involved) if we hit the mark.

6. Improve every iteration

Remember, 1% better every 2-week iteration will make a team more than 25% better after a year.  Big improvements aren’t needed, just a lot of small ones.  This might be the most key principle of “Simple Agile” because it enables us to understand we will never be perfect.  Keep trying to get better and you will.

These 6 principles are designed to get teams back to thinking of what is important.  They draw heavily from the principles of lean software development.  In many ways they could be considered rewordings of those principles.  I believe in these principles.  I believe they make a huge difference when teams believe in them as well.  How many are you violating and what are you going to do to get back to doing the basics?

Until next time I’ll be Making Agile a Reality^® by continuing to coach teams to do the basics well, then improve.

Here is a copy of the presentation I used at Agile Denver.  It doesn’t have a lot of detail, but feel free to use portions if they help get points across to your team.

Updated December 23, 2009: You can also see the presentation at SlideShare.

Related posts:

1. New to agile? Remember to respect people One of the Lean Principles is “Respect People.”  I think it may...
2. New to agile? Lean principles can help! Ever see a trash can look like that?  I know I have...
3. New to agile? Tips for better daily stand-ups As an agile coach I have attended a lot of daily stand-up...

Agile teams often get to a point where they have a number of problems which must be addressed.  During retrospectives these items keep coming up and not going away, so the team decides to try and fix the problems.  In order to do this the team starts by identifying a few tactics which they believe could resolve the issue.  Good teams will even decide to assign a person to the action items in order to keep the team accountable for actually doing the actions.

Do you see a problem with this technique of problem solving?  I do!  The team has identified symptoms and wants to resolve them, but they have done no root cause analysis.  In other words, unless they get lucky, they will only be putting a band-aid on the problem.

There are several techniques for getting to the root cause of a problem.  I’ll describe one which works reasonably well, and then describe another which has phenomenal results.  The first is usually called “The 5 Why’s Technique” or something similar.  This technique starts by asking why a particular effect happened.  Then no matter what the answer is, asking why that happened (2nd why).  This continues until “Why” has been asked 5 times, at which point you should have reached the root cause or be very close.  I took the following example straight from the Wikipedia link:

The following example demonstrates the basic process:

My car will not start. (the problem)

1. Why? – The battery is dead. (first why)
2. Why? – The alternator is not functioning. (second why)
3. Why? – The alternator belt has broken. (third why)
4. Why? – The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)
5. Why? – I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)

As you can see, replacing the battery would not have fixed the entire problem.  Too often I find software teams asking “why?” only once, which will almost universally lead to a band-aid fix.  Asking “why?” 5 times can help, but it rarely shows the interdependence between problems.  It is a good method, but it is not the BEST method, and as readers of this blog know, I don’t accept mediocrity!

The image you see above is the cover of “It’s Not Luck” by Eli Goldratt.  The book is a novel which describes the Theory of Constraints Thinking Process.  This book, when applied properly, can be a catalyst for change which has incredible effect.  Unfortunately, the “when applied properly” clause of the previous sentence can really be a bother.  The Thinking Process is not complicated, but it is extremely difficult to do well.

When done properly it can take all undesireable effects (problems) and trace them back to a very small number of root causes.  Usually 10-15 problems can be traced back to 1-2 root causes.  Now instead of applying 10-15 band-aids you can focus on one single fix which changes everything for the better!  Imagine fixing 10-15 problems by addressing just 1 or 2 root causes.  Wouldn’t that be amazing?  The amount of time and effort saved is mind-boggling.

So, how does it work?  Well, that’s the secret sauce.  You can buy the book and figure it out from there.  Unfortunately, doing this from “inside” an organization is extremely difficult.  It is very hard to divorce yourself from the knowledge and preconceived notions you have about potential solutions.  You often will end up with the band-aid you expect if you are not extremely careful!

Fortunately, there is a better way.  Agile For All now offers a one day Agile Constraints Assessment Workshop.  For a very reasonable cost you can have myself and Richard Lawrence from Humanizing Work come to your location and facilitate the Thinking Process for you.  As outsiders we have no preconceived notions about your problems or potential solutions.  This allows us to facilitate the workshop so the process does the work rather than having everyone jump right to answers (which are usually incorrect or you wouldn’t need this!).  Over the course of the day we will help you understand the true goal of your organization, the problems you are encountering, how they relate to each other, the root causes, and most importantly a plan to effectively address the root causes.  If your organization or team wants to get better, let us help!  Also note, it is called an “Agile” constraints workshop, but that is really just marketing spin – the workshop will be effective for any type of organization, regardless of methodology or problems.

If you want further information on the Agile Constraints Assessment Workshop, please email info@agileforall.com.

Until next time I’ll be Making Agile a Reality™ for more teams by helping them identify and eliminate root causes of their problems!

Related posts:

1. Agile antipattern: Hiding unfortunate truths “Unfortunate truths” are things which are true – unfortunately!  I’ve heard the...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...