2. The Agile Mind-Set Is More than ProcessesWhy is the agile approach such a big deal to developers? They see it as a bigger change than how software is developed.
Agile is a way of working and of thinking about work, says Mike Sutton, who runs agile consultancy Wizewerx. "It challenges entrenched thinking. It's painful because it forces organizations and individuals to confront waste, inefficiency and shortcomings (personal, professional and organizationally). It covers every part of the organization: engineering, stakeholder management (regular quality feedback and refactoring), team interactions (geeky developers must now talk to each other and the rest of the world — heaven help us) and customer satisfaction."
You can mess with the methodology to some degree, but if you don't adopt the mind-set wholeheartedly, assert developers, don't bother. "I'd hope my CIO understood that half-agile is very, very dangerous," says developer John Overbaugh. "If the organization wants to test out agile, we need to pick a project or two to be agile. What we don't want to do is make each project 'somewhat' agile." Doing so, he feels, dooms all to failure. Part of what an agile developer rejects is cultural impediments and attitudes, including a management demand for command and control, or customers and business analysts expecting to throw the requirements over the wall and ending up with an "agile" result.
That's why support from the top is critical to making agile development succeed in an organization.
Often, its adoption is from the bottom up — developers seeing agile as a solution, and then selling it to senior management. . . or trying to. CIOs need to adopt the agile attitude, these folks say, or it won't be accepted successfully throughout the company.
Process-oriented managers who are used to the waterfall model may have a hard time adjusting to the different philosophy, and that can cause friction.
In the waterfall model, software development is seen as flowing steadily downwards (like a waterfall) through different stand-alone phases: requirements analysis, design, implementation, testing, integration and maintenance.
Agile developer Tim Ottinger suggests that IT managers begin by looking at agile values, to learn whether they can really buy into the methodology. "Agile requires a certain release of control and change of values," Ottinger says. "If they've enshrined long hours and centralized control, or if they're suffering through relational problems (labour/management style), or if they want larger commitments done faster instead of more measured, regular success. . . well, you see. There is a reason that some companies have a lot of trouble transitioning."
So what are those values? Jeff Tucker, software engineer at Milliman Care Guidelines, explains, "Agile is basically the idea that requirements change because people change. You develop software so that you get rapid feedback and can accommodate change rapidly and easily. . . . As long as you're doing something that realizes that benefit, you're agile. A lot of executives either don't understand that and therefore fail to see the benefit, or they're extremely dogmatic about it. And either of those situations is a disaster that's either happening or waiting to happen."
Sutton adds, "If you look at the UK's only real huge scale agile success, [global service provider] BT, it took the CIO, Al-Noor Ramji, to provide real executive leadership and say, 'You have to do agile.' That is the best support for the real innovators in development teams to roll out process agility." After BT nailed the process (Scrum, XP and a few others thrown in) and they agreed on a language for now (Java/JavaEE), says Sutton, their ongoing task became challenging people and entrenched cultures.