Press Release

Agile Development on the Agenda at Gartner's Application Architecture, Development and Infrastructure Summit in Sydney, July 20-21, 2015

CIOs are under pressure to support fast-evolving digital business scenarios but are finding traditional project and development methods unsuitable, according to Gartner, Inc. Enterprises are increasingly turning to agile development to speed up projects and illustrate their value.

Speaking ahead of the Gartner Application Architecture, Development and Integration Summit in Sydney next month, Nathan Wilson, research director at Gartner, said that executed well, use of agile methods has the capability to transform IT-business relationships and have a major positive impact on IT value delivery. However, the value will be delivered only if the CIO and the entire IT management team are dedicated to the culture change that is necessary for success.

"Done well, agile development can be an integral part of the portfolio of methods that the CIO uses to deal with increasing business demand for innovation," said Mr. Wilson. "Done badly, agile development will create a lot more problems than it solves."

Gartner has identified 10 guiding principles for agile development:

No. 1: Agile is not one thing

Agile development methodologies are a set of approaches to software development that share a common philosophy but are sharply distinguished in the details of their implementations. They therefore tend to be adapted to different sorts of problems. Sophisticated organizations with a lot of experience may well use more than one of these approaches, but an organization that is getting started should select one approach and master it before attempting other approaches.

No. 2: Agile is not a "pick'n mix" methodology

Agile methods are highly systematic. Every component element of the methodology is crucial to the success of the methodology. A common mistake is for an organization to embrace some elements of an agile methodology, such as the sprint, but to ignore or play down other elements, such as managing "technical debt." Such organizations enjoy the kudos that comes from rapid development and release of new code, but they are storing up trouble by failing to address technical debt.

No. 3: Embracing agile is a joint business-IT activity

The full benefits of agile cannot be achieved without engaging with business leaders, management and the user community. If the rest of the business does not have an immediate appetite for working in a new way, careful planning and communication will be needed to bring different communities of managers and users on board.

No. 4: With agile, it is important to walk before you try running

Experienced agile practitioners can tackle large-scale developments — the equivalent of climbing Mount Everest. But it takes many years to develop the necessary skills to be able to take on such large-scale software projects. Any organization that is starting out on the agile journey needs to start in the foothills to develop the confidence and competence to take on larger tasks.

No. 5: Embracing agile is embracing continuous learning

Agile practitioners must be committed to continuous improvement in quality and cost-effectiveness, which means that every development is analyzed for lessons that can be used to improve policies and working practices. This analysis and learning are not the responsibility of a small number of senior practitioners; they are fundamental components of the workload of all agile practitioners. Furthermore, the learning is not just appropriate to the programmers who are directly involved in software development; it is also essential for all the related skills, such as project management, architecture, quality assurance and IT budget management.

No. 6: Agile is about teams and teams of teams

The basic organizational unit of delivery in agile development is a small team, typically expressed as "seven, plus or minus two" people — both developers and quality assurance. From an HR perspective, managing agile teams involves walking a fine line between keeping productive teams together and moving individuals between teams to encourage cross-fertilization of ideas. If people are moved too frequently, the teams fail to develop into highly productive units; if people are not moved between teams enough, then each team starts to become isolated and diverges from the other teams. It is important to note that physical location of teams is much more important with agile methods than with conventional approaches to development.

No. 7: Documenting, managing and eliminating technical debt is a core concept of all agile methods

Technical debt is the difference between the state of a piece of software today and the state that it needs to be in to meet appropriate and necessary requirements for quality attributes such as reliability, performance efficiency, portability, usability, maintainability and security. All development creates technical debt. The difference with agile methods is that technical debt is recognized and added to the backlog, not swept under the carpet. Any organization that seeks to embrace agile methods must put in place the necessary elements of the chosen method dedicated to ruthless refactoring and the elimination of technical debt.

No. 8: Working with third-party development service providers on agile development demands special care and attention

Many user IT organizations have a long history of outsourcing application development to specialist service providers. While there is a role for service providers in agile development, it is a very different commercial model and a very different engagement model. Since colocation with business users is axiomatic to agile methods, the opportunities for sending large amounts of work offshore are somewhat limited, so some form of supplemental staffing is likely to be a more useful model.

No. 9: The impact of agile goes well beyond the software development teams

An integral component of the agile methodologies is the concept of "continuous delivery." Agile methodologies are predicated on continuous engagement with business managers and users, and lead to the delivery of a continuous stream of new and modified software into the operational environment. This demands significant changes in working practices for both business governance and relationship management and the infrastructure and operations teams.

No. 10: Other software development methodologies will still have a place in your portfolio

In most commercial and public sector organizations, the application portfolio will present many different classes of development problems, some of which will be well-suited to agile, while some may be better-suited to incremental, iterative development and some to a modified waterfall model. Agile is not "better"; it is simply better-adapted to some problems, but not so well-adapted to others.

The latest enterprise application trends, technologies and strategies, including agile development, will be discussed at the Gartner Application Architecture, Development and Integration Summit 2015 in Sydney on Monday and Tuesday, July 20 and 21. Follow #GartnerAADI on Twitter for updates.

Contacts

About Gartner

Gartner, Inc. (NYSE: IT) is the world's leading research and advisory company. The company helps business leaders across all major functions in every industry and enterprise size with the objective insights they need to make the right decisions. Gartner's comprehensive suite of services delivers strategic advice and proven best practices to help clients succeed in their mission-critical priorities. Gartner is headquartered in Stamford, Connecticut, U.S.A., and has more than 13,000 associates serving clients in 11,000 enterprises in 100 countries. For more information, visit www.gartner.com.

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.