Apr 15, 2015
When Agile Is Done Badly
Agile development has become very popular in the high tech world, to the point where most companies think they need to be a part of the movement even if they are not sure why or how. Like anything that requires a measure of discipline, agile development requires knowledge and training. If you listen to how people describe their agile implementation, you can tell who gets it and who doesn’t. “We do Scrum. We have daily standups." The most common way to do agile badly is to add daily standups to a waterfall process. What often happens is that someone decides to go agile, and tries to implement some of the principles without understanding the purpose. It seems like all software companies are running “daily standups” even if they aren’t following an agile process. The result is often just more meetings than before, because the new daily meetings get added to the weekly status meetings, department meetings, etc. It becomes an opportunity for managers to collect status reports more often, instead of a chance for engineers to collaborate. “Standup was quick today. We were done in only a half hour!" When standups are used as management status meetings, it is easy for them to get out of hand and run for a long time, often even up to an hour per day. This kind of time commitment is detrimental and demoralizing to the team, but the happy manager often doesn’t notice. Try to remember that a standup is supposed to be a quick team huddle, not a status meeting. Keep them short! “We work in sprints. We develop in one sprint, and then test in the next one." Another way agile gets off the rails is by turning big waterfalls into mini waterfalls. One of the key agile principles is that you work until you are “done”, and each piece of work should be completed in a single sprint. That means really done - coded, tested, code reviewed, documented, etc. How can you consider a story done if you haven’t tested it? Forcing teams to complete work inside a sprint is difficult, but once the team gets the hang of it, you will see that they are more productive. “Well, it would have been done, but the QA guys didn’t finish their part." In a true agile team, success is measured at the team level. Either work is finished, or it is not, but it is never the fault of one person or one discipline. If you have static roles and boundaries, you are not working at peak potential, and that is not agile. “We work in sprints. My manager tells us what will be in each sprint." Agile methods were developed in response to the old idea that you can define a project's requirements, team capacity, and schedule ahead of time and reasonably expect to finish on time. If you have worked on a waterfall project, you know that it doesn’t work. You need to let the team members define their capacity if you want them committed to finishing the work. At Apperian, we are committed to following Scrum as carefully and completely as possible. It makes us work faster, smarter, better. How is your team doing?