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. Agile anti-pattern: Going to longer iterations This is another common theme among teams just starting with agile.  It...
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? Keep it very simple When dealing with an agile implementation, particularly in the case of a...

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? Do the simplest thing that works – THEN STOP! As an agile trainer and coach I often see new teams struggle with...
2. New to agile? Remember to respect people One of the Lean Principles is “Respect People.”  I think it may...
3. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...

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: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
2. Agile antipattern: Working overtime Ever feel like the guy over there to the left?  Yeah, me...
3. Agile antipattern: Insanity! (5 insanity antipatterns) It is sometimes said the definition of insanity is doing the same...

How do we work together? Seems like a simple question, right? How wrong you could be!  For an agile team, working together is vitally important, but it is also the hardest thing to accomplish.  Why?  Because we don’t normally work together very well.  Think about the stereotypical high tech company and their sterile cubicles with “resources” working hard in isolation.  This is a far cry from the PEOPLE on an effective agile team who work in an open, collaboration friendly environment.  (In case you can’t tell, I have a pet peeve about calling people anything except people – in my opinion it is degrading to call people anything else)  But this isn’t the only problem…

Once we get the team working well together, we still have those pesky PEOPLE known as managers and executives that want to pry into every little detail.  Sorry, but that isn’t very agile, so wouldn’t it be nice if we could keep them from doing it?  What about the product people constantly changing the focus of the team on a day to day basis?  Or how about fixing the problem of the development manager constantly trying to tell the team they can do more work than is possible?  All of these things and many more come into play when we talk about the seemingly simple question “How do we work together?”

Because all of these things add up in a hurry, I encourage teams to put together a rules of engagement document to make clear some of the most basic rules and interactions.  I do this in conjunction with having the team determine their definition of what “done” means.  Both of these items are completed prior to starting the first iteration.  For maximum effectiveness have the team, managers and executives all sign the document as a sort of contract among themselves.  Having executives sign the document is extremely empowering to the team and helps them recognize they have the full support of the organization to be successful!

Feel free to use my sample Rules of Engagement document for your team.  If you make changes, please leave a comment here so I can consider making your change to the master document I use when I train teams.  If you have questions about the document either leave a comment here or email me and I’ll try to get you an answer.  This way we all can learn and improve this document for the teams that will use it in the future.

Until next time I’ll make sure teams I train use a Rules of Engagement document because it provides a lot of help in Making Agile a Reality™ for an organization.

Related posts:

1. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...
2. New to agile? Work at a sustainable pace Question:  Which is better: a) Working nights and weekends to meet iteration...
3. New to agile? Tips for better daily stand-ups As an agile coach I have attended a lot of daily stand-up...

“Unfortunate truths” are things which are true – unfortunately!  I’ve heard the phrase used by defense lawyers and I have to admit it is pretty funny to hear something like “Well, my client would have been found not guilty except for the unfortunate truth that his fingerprints were on the weapon.”  Seems to me it was a FORTUNATE truth from the viewpoint of the rest of society!  We can look at the example I just gave and think it is pretty silly.  Then we turn around and do the same thing on our agile projects.  We might think hiding our head in the sand will help us avoid seeing the problem, but instead it just tends to make us look too much like the major piece of anatomy which is left sticking up!

For an agile team an unfortunate truth generally falls into one of two categories: a) something which shows we will not meet our iteration commitment, or b) something which shows we will not meet our project success criteria.  Members of new agile team tend to try to hide more unfortunate truths than longer running, successful teams.  I consider this one of the elephants in the room which needs to be exposed and removed.  But even on some successful agile teams there are individuals who tend to hide unfortunate truths.  Let me be very clear on something:

Agile is designed to expose risks early!

If you are not doing so then the process has broken down.  Remember, exposing risks early means there is more time to deal with the risk and make it be a non-factor.  By hiding unfortunate truths you are robbing the team of valuable time it might need in order to change the amount of “unfortunateness” (ok, maybe it isn’t a word, but it sure was fun to type!).

In closing this post I want to point out we all have different definitions of what constitutes an “unfortunate truth.”  For example, I might consider it an unfortunate truth my glass is half-empty.  Someone else could easily consider the same scenario fortunate because the glass is half-full.  My point here is simple – don’t impose your definition on the entire team by not raising the issue (umm, everybody, we thought we had a full glass, but we only have a 1/2 glass).  Every member on an agile team has a primary responsibility for exposing potential risks.  In fact, it is ok when looking at risk to be incredibly pessimistic so the worst case scenario can be turned into success!  Many times the risks are not real, but imagined.  This is fine, the system worked as designed if someone says your perceived risk isn’t really a problem.  However, when the risk IS real, having maximum exposure of the problem (ie, not hiding “unfortunate” aspects of it) combined with having maximum time to mitigate the risk often mean the difference between success and failure.  Help your team be successful by shining light on the unfortunate truths others don’t want to face.

Until next time I’ll be Making Agile a Reality™ by erasing one unfortunate truth at a time.

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
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 thoughts at 37,000 feet I don’t mind travel except for the part where you aren’t home!...

This is another common theme among teams just starting with agile.  It usually goes something like this:

1. The team has an unsuccessful iteration.
2. They determine all the unfinished work is testing.
3. During the retrospective they resolve to give more help to the testers so they can finish in time.
4. The next iteration is also unsuccessful.
5. The team determines once again all unfinished work is testing.
6. During the retrospective they decide the only way to have enough time for testing is to move to a longer iteration length.

Uh oh, Houston we have a problem!

This is not going to lead to success.  Think about it for just a minute.  The reasoning behind doing this is to give testers more time to test.  That sounds great in theory, but what are the developers doing during the extra time?  No, sorry, but they aren’t doing anything like sitting on their hands.  They are creating more software.  So if they are creating more software, when does it get tested?  Well, during the extra time of course!  But, but, the extra time was for testing the stuff they ALREADY created.  That’s right, we give extra time to test the stuff they created during the original iteration length, while then taking that time to create proportionally more software.  The result is pretty ugly – the testers now fall short by an amount of work which is directly proportional to the change in iteration length.  If the original iteration was 2 weeks, and the new iteration is 3 weeks, testers will fail to complete 50% more work in the new iteration length.  Bottom line, we didn’t make the problem better.

This is one of the worst antipatterns because for some reason people actually believe it should work.  Somehow they will wave a magic wand and developers will just slow down enough to let testers catch up with the new iteration length.  Sorry folks, it doesn’t work that way.  So what can you do instead?  You might try making a new rule:

There is no code except tested code

How does this help?  Well, developers can no longer say “I coded that already” for just one example.  It isn’t “coded” until it has passed testing.  This means developers get zero credit for anything which isn’t tested.  Now it is not just testers which fell short during the iteration, it is the team.  If testing is constantly falling behind and coders can’t just blame the testers, what are their options?  Well, for starters they can help the testers out.  Maybe figure out how to automate more tests.  Maybe use unit test-driven development so the software that gets tested is more solid and likely to pass the acceptance tests.  Maybe developers turn into testers in order to complete the iteration.  Believe me, the more times developers have to run tests, the more automation tools and frameworks will start to show up or become easier to use (and this is a good thing!).

This is based on the lean principle to improve the system by doing two things:  measuring UP and optimizing the whole.  I’ll almost certainly have blog posts on both of those topics in the near future, but feel free to purchase Mary and Tom Poppendieck’s books on Lean Software Development (see our books page) if you want to read about them.

Thanks for reading this entry.  If you were considering a longer iteration length I hope this post stopped you from making a big mistake!

Until next time I’ll be Making Agile a Reality™ by having my clients expose the real elephants in the room and getting rid of them.

Related posts:

1. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipattern: Using manual tests In an agile environment manual testing is fine – except for when it...

As an agile trainer and coach I often see new teams struggle with a simple question: “How much to do on a user story?”  A lot of people say the simplest thing that works is what should be implemented.  I agree with that wholeheartedly and even have a blog entry on how to figure out what the simplest thing is.  Unfortunately, lately I’ve found myself adding a bit to the sentence.

Do the simplest thing that works - THEN STOP!

There are developers who do the simplest thing that works and then keep going because they think the customer will want something more.  While they may be right, it isn’t their decision to make at that point.  Show what the team created at the iteration demo and see if the feedback from the demo says more should be done.  Don’t just assume it!  The extra work costs time and money, not to mention ongoing support costs if it actually goes to production.  The Product Owner needs to take all of this into account when deciding how far to take a story.

Oh, and while we’re on the topic, if you want to know how to have a great demo, read this blog entry.  It has some awesome ideas that all teams should try to follow.  The only thing I would add is to have someone other than a developer or tester be able to try the software during the demo.  Too many horror stories about how things were missed when developers went through demos too fast!

Thanks for reading this.  Until next time I’ll be helping teams in Making Agile a Reality™ by putting up a stop sign when they start trying to gold plate features!

Related posts:

1. New to agile? Keep it very simple When dealing with an agile implementation, particularly in the case of a...
2. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
3. When in Doubt Ask “How Will I Know I’ve Done That?” Tired of not knowing exactly what to create or test? Get in...

As an agile coach I have attended a lot of daily stand-up meetings.  I can’t count the number of times I’ve been in a meeting that went something like this:

Scrum Master: OK everyone, it is time for our status report.  Let’s start with Joe.
Joe (delivered in a boring monotone voice): Yesterday I did A.  Today I will do B.  Nothing blocking me.
Scrum Master: OK, now Bill.
Bill (delivered in a boring monotone voice): Yesterday I did C.  Today I will do D.  Nothing blocking me.
Scrum Master: OK, now Jane.
Jane (delivered in a boring monotone voice): Yesterday I did E.  Today I will do F.  Nothing blocking me.
(continue in this pattern until all have given their answers)
Scrum Master: Thanks everyone.  Great status meeting.  See you all tomorrow at the same time!

Can 15 minutes possibly be any more boring and useless (please don’t answer that because I REALLY don’t want to know there is a worse fate than being in this type of daily stand-up meeting!).  So, what can you do to change things?

For starters, the daily stand-up meeting IS NOT A STATUS MEETING!!!  We don’t need a status meeting.  Status is what we get from our task board and burndown chart.  Why have a meeting to cover what we can just look at either on the wall or in whatever tool we use for our project?

When I tell teams it is not a status meeting I inevitably hear ”If it isn’t a status meeting, then what is it?  It sure seems like a status meeting with the 3 questions we are supposed to answer!”  I even have to grudgingly admit I can understand the confusion.  It is very easy, even for good agile teams, to fall back into the “status-like” method of doing daily stand-up meetings.  But it isn’t a status meeting and there are ways to improve:

1. If you aren’t already “doing it right”, start!  In other words, for starters, answer the 3 questions and move on.  Don’t allow too much interaction about the answers – that can and should happen outside of the daily stand-up.
2. Do it “right” and don’t allow outside observers to participate.  Remember the chicken and pig scenario.  Only “pigs” get to participate.  This is their time, if someone wants to say something to the team they can do it at another time.
3. Use a “talking stick” or some other token which has to be in someone’s possession for them to speak.  This stops people from talking over one another and also stops side discussions.
4. To make the meeting less “status-like” the project manager/scrum master should be a bystander!  They can start the meeting by calling on someone to go first, but then they should back off and stay in the background.  Each person who speaks picks the next person who will speak.  An important note here – it is not necessary for the Scrum Master to be at the daily stand-up!  The team should still go forward, even without the Scrum Master.
5. Don’t make the meeting about moving index cards, sticky notes, online tasks or anything else similar to these things.  You can update the task board outside the meeting.  The meeting is about exchanging information not the ceremony of updating status.
6. As each person answers the question “What did I do since we met last?” everyone should be thinking to themselves “Is there anything that person could help me with based on what they just completed?”
7. As each person answers the question “What will I do before we meet again?” everyone should be thinking to themselves “Is there anything I know which could help that person with their new item?”
8. Start the meeting on time and invoke some sort of penalty for late arrivals – the latest getting the worst penalty.  Keep it fun, but it it needs to be meaningful at the same time.  This is about respect of other people.  If we don’t respect the people we work with enough to show up on time for this meeting then we have a big problem that agile may not be able to solve!
9. Encourage collaboration by having another question after everyone has spoken – Who needs to talk to someone else for help or to give help?  Then do it!  This encourages people to be thinking thoughts like #6 and #7 above.
10. If the daily stand-up is being done over the phone be sure to have everyone say their name clearly and loudly enough for everyone to understand it.  I’ve seen people on new teams never know who was talking and then not be able to help someone because they didn’t know who to help!
11. DO NOT TRY TO SOLVE PROBLEMS!!!  This is a meeting to expose problems, not solve them.  Not everyone has to be involved in solving every problem, and in fact that will cause more disruption than benefit in most cases.
12. Stick to 15 minutes or less for the meeting.  If the team is too large to have it done in 15 minutes then analyze why the team is so large and whether it should be split in some fashion.  Remember, because of the number of communication channels involved, the ideal team size is 7 +/- 2.  I usually say that is ideal, but you can go larger if you are willing to put up with the pain.  If it is larger than 12 you really need to look at why.
13. If the meeting is in person, then actually stand during the meeting.  It is a proven fact meetings will take less time when everyone is standing rather than sitting.
14. If managers will be participating (I only have them participate as pigs if they are actually doing work!) then consider having them go last.  Sometimes a manager can set the wrong tone for a meeting just by the words they use and how they say them.  When they go last this issue is avoided.  It also helps keep the meeting shorter
15. In order to focus on completion and success, consider changing the questions to “What did I COMPLETE since we last met?” and “What will I COMPLETE before we meet again?”  This tends to help with focus as well as making people painfully aware tasks should be able to be completed in less than one day.

I’m going to stop at 15 items this time.  I have several more, but I’ll save them for a future post.

Thank you for reading this.  If you have suggestions, please leave a comment.  I’d love to expand the list!  Until next time I’m going to be Making Agile a Reality™ by helping teams convert boring daily stand-up meetings into vibrant information sharing and collaboration meetings!

Related posts:

1. New to agile? Don’t settle for mediocrity James Shore recently changed the entire focus of his company. This blog...
2. Agile antipattern: Doing Agile! I spent the past week in Orlando, Florida  at the Agile Development...
3. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...

When I teach any agile course I start out with the principles of lean that Mary and Tom Poppendieck have written about in their books.  The very first of these principles is Eliminate Waste.

What does this really mean in practice?  Let’s start with a definition – waste is anything which does not add value.  We’ll leave the blog post about what value is for sometime in the future.  For now let’s focus on what some non-value adding activities could be.

High on my list are two things we often take for granted: a) email and b) meetings.  Let’s start with email.  How much of it do you get?  How much of it do you read?  How often do you read email?  Now on the other side – how much of it do you really need to be getting and reading?  Last year I had a blog post on how Outlook is causing problems with agile teams which may be worth reviewing.  It is astounding how much time we waste each day on email.  Take some of the tips in the Outlook blog post and see if your productivity improves.  Then remove yourself from some mailing lists that you never really pay attention to.  Finally, try to empty your Inbox by doing something with each message – delete it, delegate it, or do something with it (file it or answer it).  If you need a more serious intervention try this book:

Now, what about meetings.  I won’t say a lot here about them because we all know in the past 30 days we have probably been to one or more meetings that we shouldn’t have been required to attend.  Do yourself and your organization a favor – send out agendas for meetings you call.  Ask others to do the same.  This way people can make logical choices about attending each meeting.

What other wastes are there?  An astounding number.  Here are some of the big ones:

1. Partially done work – any work in progress is waste because it isn’t delivering value yet.  Try to minimize the amount of work you scrap.  Do this by concentrating on high priority items and getting them completed.  Remember, “just enough, just in time“, not “almost finished, but not quite!”
2. Extra features – 64% of features are rarely or never used (Standish Group study).  Look at each feature very carefully.  Cut out the lowest value half before you even start.
3. Complexity – I’ll have a lot more of this in a future blog posting, but suffice it to say that agile architecture and agile design are NOT oxymorons.  Keep in mind that you are always trying to do the simplest thing that solves the current problem.
4. Paperwork – need I write more?  It is 100% waste to create paper by reformatting things available digitally.  It is 100% waste to create a status report rather than having status be visible as a result of doing work (think about the taskboard and how it shows status).
5. Delays – are there any points in time when your process gets delayed?  A delay is always waste.  It is time which can never be recovered.  If your process has lots of periods where things are delayed, then those areas need to be closely examined.
6. Churn – task switching, project switching and other switches cause churn.  If you are working on more than one thing at a time you are losing efficiency and causing waste!  Organizations need to recognize that shared resources while sounding good end up losing a lot of productivity to churn.
7. Silos – when everyone has their own area of expertise the team will suffer.  It is nearly impossible to get “flow” through the process when there is a handoff among nearly everyone on the team.  We often have this in miniature when we do design then do coding then do testing, while still calling it agile.  I call that Wagile (pronounced waj-il) for Waterfallish Agile.  This will cause waste as people responsible for one part of the process wait on others to deliver something to them.  That’s before we even consider the wastes inherent in the waterfall process alone.
8. Lost knowledge – this is one many people miss.  Why do we do “Lessons Learned” meetings at the end of projects if we aren’t ever going to learn those lessons???  We need to make sure the things we learn are captured and easily accessible to others.  This is absolutely vital to improvement.

Some examples of areas of waste which can usually be eliminated:  meetings, emails, status reports, and approvals.  Areas of improvement include creating less architecture (just enough), less complex code (simplest solution that solves the problem, consider refactoring and pair programming), prioritization (work on highest priority item first, complete it, then move on), cross-functional teams (pair programming, shared code ownership, look for mentoring opportunities), and reducing churn (reduce the number of active projects, only work on one task at a time until it is either blocked or completed).  Other things to consider include coming up with at least one action during every retrospective which will help reduce waste, eliminating something entirely for an iteration followed by deciding which small parts need to return, and making a rule that email should not be used for communication unless the email is less than 2 lines in length.

I know a lot of these things are difficult to change, so let me tell you a story to make the importance clear.  As a trainer I have done many seminars and courses where one of the exercises is to create a value stream map of a process.  I specifically tell attendees to pick a process where time is critical to their organization.  Most end up picking something like a bug fix process.  Once the value stream map is created we then calculate process efficiency by dividing value added time by total time.  The average efficiency has been about 16%, although I’ve seen numbers lower than 1%!  The second half of the exercise includes redrawing the value stream map by making changes that could eliminate waste.  The efficiency usually goes up by a factor of 2-3X.  There are huge gains in productivity just waiting for us to take them. 

Do you have any good ways you’ve eliminated waste which aren’t mentioned here?  If so, be sure to leave a comment so that others can learn from you!

Make eliminating waste a mindset in your organization and you will be successful in Making Agile a Reality™.

Related posts:

1. New to agile? Remember how to say “No” No.  Only two letters.  Very simple word.  Yet for some reason, with...
2. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
3. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...

If you lived through the past few decades you have undoubtedly heard the time “Just in Time” (JIT) as applied to manufacturing.  This is the lean breakthrough that allows companies to get rid of large amounts of inventory and unfinished goods.  In a nutshell it means that parts show up just in time for manufacturing, and production happens just in time for purchase.  This is the opposite of “Just in Case” manufacturing where production was at a given level and usually ramped up as high as possible.  Agile is based on lean, so you’d expect it to have similarities to JIT, but in my opinion it goes far beyond JIT!

Agile is definitely based on JIT.  You can see this in many of the practices.  User stories are created when they are needed and not before.  Releases happen when there is appropriate value in releasing, not before and not after.  Each iteration has a commitment which is met on time.  I’m sure there are other examples, but these few suffice.

What is missing in JIT is the answer to what is getting delivered or received just in time?  This is where the phrase “Just enough, just in time” comes in.  You don’t simply want it in time, you want just enough of it – regardless of what “it” is!  Let’s look at a few examples:

• User stories – we don’t need every user story for the release prior to the first iteration.  We need just enough user stories to get started.
• Documentation – we certainly don’t need “just in case” documentation, but I also believe it is a fallacy to think agile teams can be effective with zero documentation.  We need just enough documentation to make sure the team is successful.
• Architecture – at the start of the project it doesn’t make sense to build out a fancy architecture which is going to change anyway.  Agile teams should be striving to build just enough architecture to support the user stories in the queue.
• Planning – at iteration planning we don’t look at things outside the iteration.  We do just enough planning to make sure we can accomplish our goal for the iteration.
• Collaboration – agile teams certainly have high levels of collaboration, but that is because that level is just enough to help them be successful.

These are just some examples.  I am sure there are many more.  If you are new to agile and you remember “Just enough, just in time” you will be heading down the right path.  As a newbie you may went to err on the side of “not quite enough” at the beginning (take this as just a hint) because it is easy to do “just a little too much” most of the time.  Our old ways lead us down the too much path very easily.  You can be successful doing too much, but not as successful as being not quite enough and adjusting.  When we start at too much we tend not to change because we are still seeing some success.  Don’t fall into that trap.  Keep scaling back and eliminating waste!

Hopefully this blog post is providing just enough wisdom, just in time to get you going!

Related posts:

1. New to agile? Remember a user story is more than a card! What’s wrong with the user story on the card?  It seems to...
2. New to agile? Remember to eliminate waste When I teach any agile course I start out with the principles...
3. New to agile? Remember how to say “No” No.  Only two letters.  Very simple word.  Yet for some reason, with...