Agile vs. Traditional Software Development: Why is the debate still going on? - Part II: Methods are a means to the end of project success, not the end themselves
"To this end we see the emergence of post-Agilism, which tries to retain a lower-case-a agile mindset but deprecates elements not suited to the project."
Cennydd Bowles
In the first article in this series, I contrasted two projects: creating a lightweight, single-use web-based application (let's call it Project A), and building the replacement for a complex legacy system with many integration points (Project B). Figures 2 and 3 depict the profile of projects A and B based on the criteria defined in Figure
Figure 1: Project grid from BealProjects.com
(Adapted and expanded from the project sizing grid found in the whitepaper “Business Analyst: The Pivotal IT Role of the Future”, Management Concepts, Inc, licensed to Hewlett-Packard Company, Oct. 2007. Hat tip to Otto Fox for pointing out a salient criterion now covered by the "designated product owner".)
Figure 2: Profile of project A
Figure 3: Profile of project B
As mentioned in the previous article, project A would be a good candidate for a lightweight approach to software development. For an online application that isn't mission-critical, a "good enough solution", with short time-to-market, that you can evolve later, may indeed provide more value than waiting for the perfect product to be ready. Requirements volatility (especially regarding feature relevance and user experience) is high, and the project team will benefit from constant communication with surrogate end-users to elicit and validate requirements. An agile approach that encourages face-to-face communication and continuous re-prioritization of requirements would help evolve the product in the right direction to meet customer needs.
Smaller projects (i.e., with mostly Level I or II classifications) with high level of uncertainty regarding the problem and/or solution domains (Level III for these aspects) tend to be good candidates for agile practices. According to Reifer, Maurer, and Erdogums (“Scaling Agile Methods” -- IEEE Software, ISSN 0740-7459, 07/2003, Volume 20, Issue 4, pp.12-13),
A sweet-spot agile project typically involves a small, self-organizing, collocated team of fewer than 20 developers[1] and one or more on-site customers. The team usually works together with unstable or emergent requirements, relying mainly on an oral culture based on high-bandwidth, face-to-face communication.
Project B, on the other hand, would benefit from a more in-depth, explicit requirements phase at its early stages, than agile approaches suggest. Agile prioritizes timeline over virtuosity, and allowing requirements to "emerge" during development may be detrimental to achieving the desired results in a project of such complexity. Problems can go from the lack of coherent vision impacting the effectiveness of user feedback (as discussed in the first article on this series) to loss of system reliability throughout the project.[2] A comment left by Kieryn Phipps in this post from January 2010 offers a good analogy for the difference between using evolutionary design in a simple system versus a complex one:
Recently at an agile conference, I heard the metaphor of the development of a house described in an agile way to illustrate the point of making sure that a product was thought of as a whole to ensure earlier functionality. It goes like this: Avoid building each component separately in sequence (eg. build the foundation, then the walls then the roof) because that way the product is not usable until entirely completed. Instead, start with basic usability and improve - so you would build a simple shack, add an extension, improve the walls and add an extra floor, install furniture etc, so the product is usable after each small step.
Expanding the metaphor, the problem with this method is that you are never ever going to build a skyscraper that way, and sometimes a skyscraper will be needed. (...)
I think the solution in cases like this might be some kind of hybrid method where the architecture required is identified and developed in separate projects (possibly managed in a non-agile way) with the usable features being prioritized and built on top using agile.
Many agilists argue that you can't pick and choose which agile practices to use and expect an agile method to work, insisting that you must follow all the principles behind the Agile Manifesto, or all tenets of XP or Scrum or Crystal, to call yourself "agile". Their concern is understandable, considering the fact that many companies declare that they are "going agile" while refusing to abandon their plan-driven, budget-scope-schedule approaches (obviously with disappointing results). However, it's unreasonable to expect that the adoption of agile practices will automatically cause a project to generate business value. Agile practices are not intrinsically “value-adding”: they must be aligned to business needs in order to provide true value.
Clearly, most projects do not fit the “ideal scenario” for agility. That doesn’t mean that such projects can’t benefit from adopting a more lightweight approach to software development--only that project teams shouldn’t blindly follow one of the existing “flavors” of agile methods (or even all agile principles). There is no silver bullet capable of completely removing the risks of missed schedules, blown budgets, and flawed products, either in traditional or agile software development.
Software developer and entrepreneur Joel Spolsky provides a good example of the importance of exercising judgment :
Here’s the story of Trello. We wrote the first line of code last January. By the time we hit 700 lines of code, the product was useful, and we immediately started dogfooding it in-house. We probably could have brought it to market after three months. That would have been ever so lean. There was a strong temptation just to dump it on the world super-early and spend the next year iterating and improving.
We didn’t do that. We worked for nine months, and then launched.
I couldn’t stop thinking that you never have a second chance to make a first impression. We got 131,000 eyeballs on 9-month-old Trello when we launched, and it was AWESOME, so 22% of them signed up. If we had launched 3-month-old Trello, it would have been NOT SO AWESOME. Maybe even MEH. I don’t want 131,000 eyeballs on MEH.
Smart companies avoid one-size-fits-all solutions, bringing together practices and techniques from agile and non-agile approaches to create their own hybrid methodologies, adapted to fit each project profile. As Alistair Cockburn wrote in his book "Agile Software Development: The Cooperative Game, Second Edition" (Addison-Wesley Professional, 2006),
"Start by recognizing that no single methodology definition can possibly suit all projects. Don’t even think that the Rational Unified Process, Unified Process, or the Something Else methodology will fit your project out of the box. If you follow a methodology out of the box, you will have one that fits some project in the world, but probably not yours."
A project grid like the one described in this article, or presented in this handout from Kent McDonald, when adapted to an organization’s specific needs, may help increase the understanding of the boundary conditions in which certain software development practices go from appropriate to inappropriate. If a new project doesn’t share the same characteristics of another that succeeded using a particular method, it’s unreasonable to assume that the same method will work without any determination of where the true benefits came from, and whether they can be repeated under the new circumstances.
By taking a closer look at how your company is developing software, and what is working for projects with different profiles, it’s possible to leverage winning strategies and hybrid approaches to make your software initiatives equally or more successful in the future.
Read on: Agile vs. Traditional... - Part III: Winning Through Integrative Thinking
Author : Adriana Beal received her B.S. in electronic engineering and MBA in strategic management of information systems from two of the most prestigious graduate schools in Brazil. For the past 10 years she has been offering consulting assistance throughout the software development life cycle for organizations implementing large, complex software projects. Adriana recently joined e-commerce team at Hewlett-Packard. She is also the founder of Projeto 100%, a movement making significant changes in the lives of families trapped in poverty in Brazil.
[1] According to this study, 3-7 people is considered the optimum team size for medium-sized software applications.
[2] For discussions regarding the risks of evolutionary design in the case of complex and mission critical applications, see for example “How extreme does Extreme Programming have to be? Adapting XP Practices to Large-scale Projects” (Lan Cao et all., Proceedings of the 37th Hawaii International Conference on Systems Science) and "Refactoring as Meta Programming" (D. A. Thomas, Journal of Object Technology, 4 (2005), pp. 7-12).