Over the past decade, agile software development has evolved from a movement on the fringes,opposed to the traditional “waterfall” approach, to a mainstream enterprise practice. Now that agile is here to stay, let’s look at where it fits into your own organization.
‘Big agile’
No longer an esoteric art practiced by a few software development teams in the confines of an IT department, agile has now permeated the upper ranks of many large organizations. There is now talk of “big agile” — large-scale company transformations.
“It used to be grassroots efforts, a group of developers picking up extreme practices…and liking it, and then at some point, more teams picked it up, but isolated in IT,” says Hubert Smits, a senior consultant at the Cutter Consortium. “Now, it comes top-down from a management layer, often as high up as the vice-presidency or higher, and with that starts to touch on more parts of the organization.”
Today, some enterprises are basing their entire software development strategy on agile principles. And many others are at least partly agile, says Nathan Wilson, principal research analyst at Gartner Inc.
At a Gartner developer conference last December, he says more than 70 per cent of the people who attended put up their hands when asked if they were doing some form or agile in their organizations (“a big change from a couple years ago when it was kind of this strange thing that was done by a few startups off on the west coast”).
So, since agile has been adopted, at least in some form, by a good number of organizations, here are some tips from the experts on the right way to do it.
A committed relationship
First of all, don’t flip-flop, they say. If you have deep reservations about remaking yourself as an agile shop, that won’t bode well for your management or software teams.
Whatever approach you choose, you have to commit to it in body as well as spirit, says Israel Gat, director of the Cutter Consortium’s agile practice. There are plenty of enterprises that are adopting partially agile approaches, but they might end up getting only partial results, he says.
Gat gives senior managers a questionnaire to determine their willingness to change the way they work. Among other things, it asks how many product demos they’ve attended in person and provided feedback on.
“If the answer is ‘none’ I basically say, ‘Sorry, sir,’ or ‘Sorry, madam, you are not doing your job.’ It’s not going to happen based on just understanding. You’ve got to invest in it.”
The desire to become more agile has to come from the top in larger organizations, he says. “Change management is absolutely essential here and I can’t stress it too strongly.”
“If I work with a team of five or seven or nine on doing scrum [an agile management term], then there’s not much of a change management here because I am working with a bunch of guys who want to adopt a new software method. However, if we are talking about [an] agile or scrum rollout of 200 people, if not thousands of people, then this implies major changes.
“The DNA of companies, often times, fights such changes. So, at the very beginning of medium or large scale engagement I would be devoting a lot of time with various constituencies about how we should manage the change. If I don’t do it, I am dead meat.”
A middle ground?
Then there is the question of mixing agile with the traditional “waterfall” approach. Can it be done?
Not really, Wilson says.
“It’s not horrible, but you leave most of the advantages of agile on the table if you do that, because the big advantages of agile are around the change in the discussion between the consumer of the software, the user of the software, and the developer.
“So, if you run it through a whole requirements-gathering design phase and then you start your agile, you’re losing that feedback loop between the developer and the consumer, which makes agile so effective at producing targeted software that does the right thing.”
That doesn’t mean your organization can’t embrace only certain agile principles. It just means that a half-agile project isn’t going to go far. Agile isn’t necessarily good or bad for an organization, says Wilson, it’s just a tool that has its particular use. “We tend to think of it as more that certain projects may be better or worse for agile than [for] companies,” he says.
Requirements first
So, how should your company decide what an agile project should be? First of all, says Wilson, you need to think about “well-designed requirements versus fuzzy requirements.”
Agile is the right way to manage software projects with “fuzzy requirements,” he says. “If you’re doing something new, like a Web initiative or a mobile initiative, you want to get out there and you want to be cool on the mobile, and that may be all you really know up front. Agile’s really well suited to kind of discovering the solution on the fly, so to speak.”
More mature products and legacy services (he uses COBOL as an example), benefit less from an agile approach as their requirements are already well established and their function well understood.
Time-to-market is another big one, he says. If you want to get your product out pronto, you need your development team to work on the most important parts first. “An effective agile team can build the 20 per cent of the application that’s going to be used 80 per cent of the time,” he says. “And they can get that out very quickly. There’s no real equivalent way of doing that in a waterfall project.”
Greg Betty, CEO of Intelliware Development Inc., a Toronto-based agile software development firm, says agile can ease the angst many companies feel when trying to figure out what they want to do.“They’ll go through these huge phases and they get into the analysis-paralysis problem of they can’t figure out where to lash out,” he says. “And what agile does for them is it allows them to get started.”
Paul Kent, SAS Institute Inc.’s vice-president of platform and development, says that for his company, agile is “a very good way of prioritizing and cutting to the chase.”
“Especially in the solutions space, the whole idea of prioritizing a long, long list of features ahead of time and then working at it for 18 months has fallen by the wayside.”
In some large enterprises, approaches to software development are not necessarily called “waterfall” or “agile” but a distinction is made between how projects are conceived and managed. At SAP Canada Inc., for example, Riaz Raihan, the national vice-president of value engineering, industries and private equity, does not use these terms, though adherents of both camps would find SAP’s methodology familiar.
“For a company of this size and scale I think you need to have at least a few approaches,” he says. He compares development work on two of SAP’s major products: ERP software and HANA. SAP’s ERP software is changed incrementally, something that agile proponents would agree with.
Meanwhile, with HANA, while it was a new project that had rather “fuzzy” requirements, developers were given the freedom they needed to be creative—something critics say can be stifled using an agile approach.
“HANA was not born because we got feedback from the field,” Raihan says. “HANA was born because some smart people in development and our founder figured out the next wave of computing…they had much more free rein to think about HANA.”
Finding the right agile coach
Agile development is clearly much better understood than it was a decade ago, but while you may think you have a good grasp of its precepts, reading the manifesto isn’t good enough. It’s probably not a good idea to go agile alone, Wilson says. He recommends that enterprises hire consultants to get themselves up and running on an agile project.
“Now, you have to be careful,” he cautions. “There are a lot of people out there who want to coach in a form that means that they’re going to have a coach on-site in your company for the rest of time, and you don’t want that. You want someone who is going to teach you how to fish, so to speak, versus fishing for you.”
Agile may have gone mainstream, he says, but make no mistake, there is still a hard core of extremists out there that you should avoid. “You don’t want a coach that’s going to come in and say, ‘you have to do exactly the way the book says or you’re not doing agile and you’re no good’—so, somebody who’s not a zealot, somebody who’s much more flexible.”
It may take a little time to become fully agile—four to five years on average, he says — but with the right help, you’ll get there.
Brian Bloom is a staff writer at ComputerWorld Canada. You can find him on Google+. He covers enterprise hardware and software, information architecture and security topics.
