Completing the Agile Development Puzzle

Completing the Agile Development Puzzle Bob Hartman is Net Objectives’ Vice President of Business Development and Marketing. He has over 20 years experience in the software industry and has seen it all. Maybe it is all those years in the trenches or maybe it is the gray in his beard or maybe it is living in Colorado, but I find his perspectives to be refreshing. He sees what organizations truly need and does a great job helping them. Recently, I had the chance to talk with Bob just after he gave a free public seminar called How to use lean principles to complete the Agile development puzzle This seminar was motivated by Bob's keen awareness that Agile – as it is usually taught – is not nearly as effective for teams and organizations as it should be. Teams only go so far and are left to struggle with how to improve, or must hire expensive consultants. Lean helps complete the picture. Here's a little more detail. To paraphrase a familiar quote, “Give a team Agile and they can work effectively until it breaks. Teach them Lean principles and they can continuously improve.” Clearly, he’s a recovering geek. But it is still true. The thrust of his seminar was to help people understand the lean principles that provide the foundation for Agile, so that they can be freed from the “Agile recipe book” to know how to adapt processes for themselves. They need to know the “Why” behind the “What.” Repeatedly, Bob has helped organizations compare the Agile practices they are doing now – especially what is not working as they had hoped – with the lean principles that inform those Agile practices to help them see where they need to go. Then, they can develop plans to get there. Knowing the principles gives Bob the “power” to see gaps. Here are some examples of problems that we see time and again in Agile teams. Agile problem: Testing happens at the end of an iteration. What usually happens: The Agile team runs out of time, so they push testing off to the next iteration. And then they push more testing off to the next iteration. And so on, always building up “testing debt.” Testing early is not a typical Agile process. Lean principle being violated: “Build Quality In.” Lean teaches another perspective on testing – it is essential right from the start. The goal is not simply to uncover defects but to prevent them in the first place. We want to build quality in, not test it in. Otherwise, just doing risk management. But building quality in (using TDD and acceptance tests up front), the team knows that the product is defect free. Agile problem: Trying to do more than in the current iteration than you had in the previous iteration. What usually happens: A team is pushed to go faster or get more done in the next iteration than they had done in the past iteration. The work piles on. And teams think there is something wrong with them or that the last iteration was just an aberration. Lean Principle: “Respect People” and “Do not multitask” and “Deliver Fast.” Teams usually don’t go faster than they have done. It is better to let them go at their established, sustainable pace, using disciplines rather than heroics. If they get their work done, they can always pull more off of the backlog, but should not be pushing stuff off. Piling on more work comes from fear that the team is not performing adequately, not going to get all of the features finished. But it is better to deliver whole features earlier to customers than to wait and wait and deliver a set of features late – the customer gets more value earlier Agile seems to be focused on improving teams. This is good, but may be sub-optimal. Teams end up focusing on their piece of the overall effort. Lean thinking builds on this to say, “let’s look at the entire stream of work we do, from the initial concept to cash in the door.” It helps management see their part in orchestrating something that will optimize the entire flow. For example, suppose you have a team that can turn a requirement into a finished p