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. [Read more...]
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. [Read more...]
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. [Read more...]
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… [Read more...]
“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! [Read more...]
This is another common theme among teams just starting with agile. It usually goes something like this:
- The team has an unsuccessful iteration.
- They determine all the unfinished work is testing.
- During the retrospective they resolve to give more help to the testers so they can finish in time.
- The next iteration is also unsuccessful.
- The team determines once again all unfinished work is testing.
- During the retrospective they decide the only way to have enough time for testing is to move to a longer iteration length.
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. [Read more...]
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? [Read more...]
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. [Read more...]
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! [Read more...]