The long laundry list of software development pros’ problems with the Agile methodology includes inadequate training, poor leadership, rigid adherence to Agile principles that don’t fit the project, and more. That said, there are Agile problem areas that are slammed more often than these, including required meetings, inadequate documentation and issues related to short iterations.
Need for speed crimps Agile documentation
Some people think that Agile calls for doing hardly any documentation. They complain that they can’t give the kinds of reports they used to give, calling Agile reports “Cragile” -- or crappy Agile – or Scrumbutt.
“That’s the phoniest belief about Agile I’ve ever heard,” said BigVisible Solutions Agile coach Mike Dwyer. Agile entails doing documentation that has value, he said, not “your earned-value estimated nonsense or spending six weeks writing a proposal to prove that you have done something, when all that you’ve done for the past six weeks is write a presentation.”
The problem for developers, however, is that there’s little time in Agile’s short-iteration scheme to write enough documentation, development pros told us. Iteration cycles are every three weeks, “boom, boom, boom,” and it’s hard to fit doing documentation into that cycle, said Huckleberry Carignan, lead QA engineer at Vistaprint, a print services provider.
Veteran software tester Chris York agreed, saying he has never seen managers call for adequate documentation in Agile projects. They ask for concise, but not complete documentation. That means testers are left with short pieces of stories they have to try to put together, “It’s nearly impossible,” said York. “We always got concise, but we never got complete, documentation. There’s nothing that really tells you how things work.”
Developers grump about Agile meetings
Meetings are a cornerstone of the Agile methodologies and a thorn in the side of some developers and testers. Known as daily stand-ups, daily Scrums and other names, Agile meetings often draw the most heated criticism of all Agile practices.
Kern hears more complaints about Agile meetings being done poorly than anything else. “Usually, when you dig deeper, it’s because the meetings are like dumb status meetings; just like the same old same olds,” he said.
Some tools and/or practices used in Agile meetings seem demeaning and infantile to some participants. Complaints center on having to stand; huddles; the use of talking sticks or cards; and dollar penalties for infractions like sitting, drinking coffee, speaking out of turn, etc.
York recalled of being in one Agile manager’s meetings. “You held a Kush ball when you spoke. The manager wanted us to throw the ball to each other. Somebody threw the Kush ball and hit the new projector. Now suddenly the Kush ball was no longer being thrown. It felt like grade school.”
Distributed development teams are another challenge related to Agile’s focus on meetings. Making Agile meetings and Agile’s reliance on constant communication work is difficult for global development teams, said Carignan.
“Having the communication smoothly enough in a global environment is hard, especially with time zone differences,” Carignan explained. “If we’re in Lexington, Mass., and we’re trying to work together with people in Venlo, Netherlands and Switzerland and Australia, it is pretty difficult to get that communication smoothly to work in Agile method.”
On the other hand, veteran software tester Chris McMahon has worked in distributed Agile teams that succeeded in communicating well. Those teams mixed written and voice communication, using multi-channel real-time chat applications, voice-over-IP, wikis, IM and remote workflow tools like defect trackers.
Kern has been in many good meetings, ones that went beyond being simple status reports to identifying obstacles and ways to remove them. Those meeting leaders and participants succeeded in getting people on the same page and making plans; gaining consensus on each person’s role in the plan; creating contingency plans and so on.
Estimates for iterations not based on reality
Requirement goals or stories must be realistic and accurate, or required features don’t get produced in an iteration, said Scott Barber. The result is usually recriminations, project slowdowns and technical debt.
Typically, iterations are two-to-three weeks long. That quick delivery of features is very attractive to businesses and is seen as a main reason to use Agile instead of waterfall and other development methodologies. Focus too intently on that one aspect of Agile and forego others at your peril.
York has seem missed estimates kill projects. “You have to be dead on with your estimates otherwise the whole thing is screwed up,” he said. “There’s not enough time in the next iteration or the next to catch up when a goal is missed. He’s seen estimates being way off the mark in three Agile projects. In those cases, York said, at the very end, the project manager cut out what didn’t get done and then claimed it all got done. The result was debilitating technical debt.
If you don’t get everything done in one iteration, you have to change your plan and go back and fix things before technical debt builds up, wrote software test veteran David Christiansen in his article, How to deal with iteration issues in Agile.
An even better approach is not planning too far in advance, said Crispin. Her Agile team avoids missed estimates by estimating only a sprint or two in advance. This gives them the ability to switch priorities very fast, to be very agile.
Agile’s short iterations lead to burn-out and mistakes
Business managers love short iterations, but they wear people out, developers told us.
Management is getting away with short iterations today because of the recession, said York. “People are going to burn out and start leaving. And as soon as the economy picks up, people are going to start switching jobs because they’re tired of being pushed to the limit.”
Dwyer sees testers feeling the pinch of short iterations the most, largely because they’re not allowed into a process earlier. Carignan agreed, noting that the expectation is often for test and QA teams to get their work done in the last eight days of a three-week iteration, a time when testing and production is happening almost simultaneously.
Need for speed crimps Agile documentation
Some people think that Agile calls for doing hardly any documentation. They complain that they can’t give the kinds of reports they used to give, calling Agile reports “Cragile” -- or crappy Agile – or Scrumbutt.
“That’s the phoniest belief about Agile I’ve ever heard,” said BigVisible Solutions Agile coach Mike Dwyer. Agile entails doing documentation that has value, he said, not “your earned-value estimated nonsense or spending six weeks writing a proposal to prove that you have done something, when all that you’ve done for the past six weeks is write a presentation.”
The problem for developers, however, is that there’s little time in Agile’s short-iteration scheme to write enough documentation, development pros told us. Iteration cycles are every three weeks, “boom, boom, boom,” and it’s hard to fit doing documentation into that cycle, said Huckleberry Carignan, lead QA engineer at Vistaprint, a print services provider.
Veteran software tester Chris York agreed, saying he has never seen managers call for adequate documentation in Agile projects. They ask for concise, but not complete documentation. That means testers are left with short pieces of stories they have to try to put together, “It’s nearly impossible,” said York. “We always got concise, but we never got complete, documentation. There’s nothing that really tells you how things work.”
Developers grump about Agile meetings
Meetings are a cornerstone of the Agile methodologies and a thorn in the side of some developers and testers. Known as daily stand-ups, daily Scrums and other names, Agile meetings often draw the most heated criticism of all Agile practices.
Kern hears more complaints about Agile meetings being done poorly than anything else. “Usually, when you dig deeper, it’s because the meetings are like dumb status meetings; just like the same old same olds,” he said.
Some tools and/or practices used in Agile meetings seem demeaning and infantile to some participants. Complaints center on having to stand; huddles; the use of talking sticks or cards; and dollar penalties for infractions like sitting, drinking coffee, speaking out of turn, etc.
York recalled of being in one Agile manager’s meetings. “You held a Kush ball when you spoke. The manager wanted us to throw the ball to each other. Somebody threw the Kush ball and hit the new projector. Now suddenly the Kush ball was no longer being thrown. It felt like grade school.”
Distributed development teams are another challenge related to Agile’s focus on meetings. Making Agile meetings and Agile’s reliance on constant communication work is difficult for global development teams, said Carignan.
“Having the communication smoothly enough in a global environment is hard, especially with time zone differences,” Carignan explained. “If we’re in Lexington, Mass., and we’re trying to work together with people in Venlo, Netherlands and Switzerland and Australia, it is pretty difficult to get that communication smoothly to work in Agile method.”
On the other hand, veteran software tester Chris McMahon has worked in distributed Agile teams that succeeded in communicating well. Those teams mixed written and voice communication, using multi-channel real-time chat applications, voice-over-IP, wikis, IM and remote workflow tools like defect trackers.
Kern has been in many good meetings, ones that went beyond being simple status reports to identifying obstacles and ways to remove them. Those meeting leaders and participants succeeded in getting people on the same page and making plans; gaining consensus on each person’s role in the plan; creating contingency plans and so on.
Estimates for iterations not based on reality
Requirement goals or stories must be realistic and accurate, or required features don’t get produced in an iteration, said Scott Barber. The result is usually recriminations, project slowdowns and technical debt.
Typically, iterations are two-to-three weeks long. That quick delivery of features is very attractive to businesses and is seen as a main reason to use Agile instead of waterfall and other development methodologies. Focus too intently on that one aspect of Agile and forego others at your peril.
York has seem missed estimates kill projects. “You have to be dead on with your estimates otherwise the whole thing is screwed up,” he said. “There’s not enough time in the next iteration or the next to catch up when a goal is missed. He’s seen estimates being way off the mark in three Agile projects. In those cases, York said, at the very end, the project manager cut out what didn’t get done and then claimed it all got done. The result was debilitating technical debt.
If you don’t get everything done in one iteration, you have to change your plan and go back and fix things before technical debt builds up, wrote software test veteran David Christiansen in his article, How to deal with iteration issues in Agile.
An even better approach is not planning too far in advance, said Crispin. Her Agile team avoids missed estimates by estimating only a sprint or two in advance. This gives them the ability to switch priorities very fast, to be very agile.
Agile’s short iterations lead to burn-out and mistakes
Business managers love short iterations, but they wear people out, developers told us.
Management is getting away with short iterations today because of the recession, said York. “People are going to burn out and start leaving. And as soon as the economy picks up, people are going to start switching jobs because they’re tired of being pushed to the limit.”
Dwyer sees testers feeling the pinch of short iterations the most, largely because they’re not allowed into a process earlier. Carignan agreed, noting that the expectation is often for test and QA teams to get their work done in the last eight days of a three-week iteration, a time when testing and production is happening almost simultaneously.
