Hating Agile development isn’t just a knee jerk reaction to change. Instead, it’s a reaction to an organization’s poor execution of Agile, according to Agile veterans. Too frequently, Agile projects are unknowingly sabotaged by chief executives, project managers and others who
The examination of Agile projects is part two of SearchSoftwareQuality.com’s Agile backlash series. Agile veterans cite the most common mistakes they see being made in Agile adoption and implementation. What’s behind the Agile backlash was examined in the previous installment.
Agile mistake #1: You adopt Agile without a clearly-defined reason why.
Do your due diligence before choosing Agile for a project or organization, advised Mike Dwyer, principal Agile coach for BigVisible Solutions, Boston, MA. Too many organizations adopt Agile without defining the expected results or how those results will be measured. From the top down, everyone has to be focused on common goals, he said. He recommends examining desired results in every sprint, iteration and project, asking if practices moved your team closer to what your goals were.
Make sure Agile fits your projects, said Lisa Crispin, director of Agile Software Development at ISV Ultimate Software Group. Agile development doesn’t make sense for every project and development organization. “CXO-level executives should work with all departments involved in software projects to determine if going the Agile way makes good development process and business sense for all,” she said. Crispin -- who is co-author of the book, Agile Testing: A Practical Guide for Testers and Agile Teams -- recommends some key metrics to use in Agile development in this article.
Agile mistake # 2: You keep business and development teams separated.
Treating software development as a separate thing from the business is a common mistake. Too often, experts say, chief executives don’t know that all departments have to be involved, and development and business teams resist collaboration.
Inter-department collaboration is a new concept for most software teams. Veteran developers have often worked in lone-coder situations, said Crispin. They’ve gone off for several months and returned with a product. Meanwhile, non-IT executives and business-side staff are uncomfortable with software people coming over and wanting to know how they do their jobs.
“As software becomes more important, collaboration is going to have to happen,” said Crispin. “Breaking down the walls has helped my own team work more efficiently and deliver higher quality software.”
Agile mistake #3: You fail to acknowledge, react to, or find ways to work around and give team members time to adjust to cultural change.
A lot of organizations and project teams do a pretty good job on paper planning the Agile transition, said Scott Barber, president of PerfTestPlus, a Palm Bay, Fla.-based software testing services firm. “Strategically, it all looks very good; but then -- on the whole – they underestimate the impact of cultural changes.”
Organizational change is hard for everybody. Some people work better in one environment over the other. In moving towards Agile, every person has to handle their responsibilities a little differently, said Barber. Managers should expect a reaction to that change.
For example, Barber said, consider the team that is moving from a very sequential, dated process with lots of sign offs to one that’s very in line and collaborative with a group agreement, as opposed to an individual signing off. Often, people who are very used to this other process have a hard time understanding how to do their job in the new environment. Some people manage to switch their thinking and work habits very well. Others don’t.
Agile is far more than a process change. For some development and business veterans, the Agile ways is counterintuitive. “Too often they’re given one project to figure it out,” said Barber. “In my opinion, that’s an unreasonable expectation.”
Agile mistake #4: There is inadequate training from the top down.
Organizations that don’t invest in long-term education are going to do a bad job whether they do Agile or waterfall, Crispin said.
“Companies that skimp on training are usually looking for the quick fix, the silver bullet,” said Dwyer. “And a lot of them say, ‘Oh, we can get the books and read them.’ And they can. And they can get better at it. It will just take years of mistakes and failures.”
The very popular two-day ScrumMaster and other Agile certification programs draw a lot of fire. Sure, education is a good thing, said Agile Manifesto co-signatory Jon Kern. “It’s good ifjust a couple of days of training in a process which, if applied to a team in an Agile way, actually helps take a non-Agile team and move them further ahead in the process.” Then again, he said, this type of organization problem won’t do enough of the other Agile practices to really make a difference.
Our sources have seen companies put two-day-certified ScrumMasters in charge of enterprise-level Agile transitions and projects and/or consider that one course is adequate for anyone involved in an Agile project.
On his first Agile software project, 15-year-veteran tester and developer Chris Young worked with a team that was just adopting the methodology. The leader had a certification, but not a wealth of experience. The team was given a one-day basic, very basic, training. None of the team members were experienced in Scrum, the chosen Agile methodology.
The training day consisted of an example that “nobody would ever do or use, and it was set up so that it would work nicely,” said Young. “When we started doing our real work, the first iteration we did we only booked ourselves up at 65% of capacity.” They missed the deadline badly. The goal on the second iteration was reduced even more, and the team met 90% of goal. On the third iteration, since we hit the really low – around 50% mark – deadline. “So, the Agile leader bounced it back up to 100%, and we missed it badly again.”
Naturally, said Young, the ScrumMaster blamed the misses on the development team, saying “What’s wrong with you people? Why can’t you get this?”
Agile fails because people in organizations figure that they’re so smart they don’t need to listen to or hire the veterans coming off the line, said Mike Dwyer. The really smart ones do nothing without a leader with experience on the team. “Get somebody who’s been there, not somebody who waves a certification,” said Dwyer. “Don’t get somebody who says they’ve been there. Get somebody who actually is scarred and tattered, has made a lot of mistakes and figured out how to correct them.”
Agile mistake #5: Blame Agile for failures that have nothing to do with Agile.
Frequently, our sources have heard development and business pros criticize Agile when Agile wasn’t the root cause of their problems. Barber has seen cases where either Agile didn’t fit the project or the transition is more expensive to complete the transition. “So the leaders and teams come back and say, ‘Agile sucks. It doesn’t work. It’s broken.’”
Even teams well-schooled in Agile can make mistakes that slow down or damage projects and expensive to untangle. “We’re a really rocking Agile team, but we’ve still had problems in production,” said Crispin. “What’s going on? They’re not bugs, not software bugs technically; they’re people making mistakes and screwing up the data. Then it takes a long time to untangle it and it’s expensive.”
Agile calls for vigilance
Of course, there are many ways to kill any development project; but these five mistakes are the most common and egregious, our experts said. They all center on a failure to take stock, plan well and make quality a top priority.
Agile doesn’t call for perfection, but it does call for reflection followed by action, said Dwyer. It is still evolving because its practitioners see no end to the ways organizations can be more Agile.
“It all boils down to being individually as competent as you can be and being very observant of the cause and affect around things that you and/or your team is doing,” said Kern. “It’s a challenge. It’s not easy to be perfect in life, and it’s certainly not easy to be perfect in software.”
Read more of the Agile series:
Have your experiences with Agile been good, bad or in between? Do you agree or disagree with the statements made in this article? Let us know. Write to us at firstname.lastname@example.org.
This was first published in June 2011