Are agile methods a divine gift for the lazy? Have you run across folks who use the adoption of Agile methods as an excuse to get out of work?
I was talking with a former boss and one of my favorite mentors yesterday about fast moving development teams that adopt Agile methods. We were discussing the examples of how adopting agile methods can truly help teams improve throughput, quality and communication. There are some great success stories out there. Then we talked about the common excuses.
I like to think of it as Agile for the Lazy. You have worked with them and spotted them on your teams. These are the folks are often well-intentioned, but are simply looking for an easy way out. Agile is like an amazing gift to them. Finally, a reason not to do the hard stuff!
Software development is hard. It’s detailed, tedious, requires extreme attention to detail (by someone) and requires rigorous organization to produce quality products. We’re all looking for better ways and methods. Agile can be perfect for folks wanting to find a quick exit.
In talking with colleagues, it appears that one of the most famous lines is “Agile is great, we don’t have to document anything anymore!” Here are some other lines you may have encountered:
- “I told them everything they needed to know in the stand-up meeting.”
- “Now that we’ve started Test-Driven-Development, there’s no other testing that we need to do.”
- “Why do we need a project plan?”
- “Well, we’re agile, why can’t you get the project/release out faster?”
- “The test and doc team just has to do a better job of keeping up.”
- “Now that we’re agile, we can add a lot more features/changes.”
So, how do you handle the lazy? First, let’s go back to the basics. If you are adopting Agile methods you need to know where you are going and you need a plan to get there. You will need a vision and you need to recognize that you have to re-engineer your internal processes for the Agile methods you are adopting. The overall plan should change as you learn, which is the whole point.
What about implementing change? Changing your processes means you need to look at your entire development life cycle as changing. You need to re-engineer to make sure that the Agile methods fit and work for the team, that tool changes or work flows are considered and communication methods are defined. The team will need training to understand how the changes will affect them. The team also needs supporting objectives and performance targets that will support the changes. You need to also choose how quickly process change can occur. What can the team absorb without derailing your development schedules. If things don’t work well in your environment, then you change. That’s the whole point.
Worst thing you can do is allow the lazy to control Agile adoption. You may end up in a situation where the entire process becomes dysfunctional and the team can no longer execute effectively because each person has their own interpretation of the vision and goals.
Here’s some excellent related posts that delve into this same topic:
From Kevin Schlabach: http://agile-commentary.blogspot.com/2008/10/agile-practices-as-gateway-drug.html
From Mike Cottmeyer :http://www.leadingagile.com/2008/10/agile-or-iterative-and-incremental.html
What about dealing with management who thinks Agile just means more projects/applications/features, faster with the same resources? Now that’s a topic for another day.
Let's Look at it Another Way... 