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 product instantly. A wave of the wand and a perfect product is created. They would be really impressed with themselves. But then, suppose it takes shipping 6 months to get it to the customer and it takes billing another 9 months before the purchase order is sent and product support does not get the support manuals for 15 months. Now, it appears that neither the customer nor the business is getting much value from that instant product. There is lots of room for improvement.

Lean gives the eyes to improve the entire value stream.

That is why we teach Lean and Agile and Test-Driven Development and Patterns in an integrated way. They all work together. And the people doing the work also work in an integrated way.

That is why we believe in offering Implementing Scrum for Your Team as something for whole teams – business and technical – rather than sending people one at a time. Integrating people from the get go is the most effective path to success.

Enjoy the show!

Talk to us

I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to [email protected] with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you.

Recommendations - Training by Net Objectives

• Lean-Agile Software Development
• Implementing Scrum for Your Team

Music used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I'd encourage you to subscribe to his feed.

For more information, contact [email protected] or visit us at http://www.netobjectives.com/