Agile vs. Traditional... - Part III: Winning Through Integrative Thinking


Agile vs. Traditional Software Development: Why is the debate still going on? - Part III: Winning Through Integrative Thinking

In the previous article on this series, I described how a project grid can be used to better understand the characteristics of a project during its initiation phase. It may seem like a huge effort to classify each project using that type of grid, but once an organization has established a good classification method that works for its particular context, identifying the project profile becomes a quick process, worth of the investment in time and effort.

Understanding the profile of your next software project is the first step toward making informed decisions regarding the best approach for the development effort. While a lightweight framework such as Crystal or Scrum may be perfect for some types of project (e.g., the flagship Web application for a startup), it’s unlikely that any of the commercial agile models will address all the issues that many software projects face (e.g., larger and distributed teams, reuse of extensive amounts of legacy software, multiple stakeholders with conflicting interests, etc.). Instead of taking for granted that either you find a flavor of agile that will fit the needs of your organization, or you must completely dismiss the use of agile methods, a much more valuable approach is to determine, for each individual project, which agile concepts should be embraced or not. The decision to use an agile practice should come from its ability to improve customer satisfaction, costs, quality, cycle time, and/or productivity in your current project, not from the fact that it’s part of a well-established agile methodology.

As I wrote in part II of this series:

    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.

Most arguments against hybrid models are strongly influenced by a belief that the two opposing models, waterfall, and agile, are the two competing realities. The comment below, from a reader disagreeing with an article in which the author defends the hybridization of agile and traditional methods, illustrates this view:

    If I understand your thesis, you're effectively arguing for holding on to a portion of the status quo of project delivery: If it's too hard to do completely with agile practices, there's no shame - and in fact, even honor - in retreating to the warm security of planning everything up front, moving work products through successive phases and dining a la carte from the agile buffet.

    While there's certainly nothing stopping you from doing so, I have to ask "What's the motivation?" Why not be totally pragmatic and skip agile completely and just go all-in on waterfall? It's easier, right? Promising everything up front, hoping that things go 100% according to plan and you've padded the estimates enough to cover overages? Not bothering to surface problems or issues daily - skipping out on reviews. It's all a bit much, isn't it?

This type of stance is typical of a conventional thinker, one that believes that if your problem doesn’t fit all elements of a model, then you must choose the opposing model. In his book The Opposable Mind: Winning Through Integrative Thinking (from which I borrowed the title of this article), award winning author Roger Martin explains the difference between individuals who are “contented model defenders” and “optimistic model seekers”.

Contented model defenders, explains Martin, adopt a theory and then seek to support and defend it. As contented model defenders accumulate data in support of the theory they’ve adopted, they become more certain that their theory represents the truth, and more content that they have achieved their ultimate goal, certainty. Optimistic model seekers, on the other hand, don’t believe there is a right answer, just the best answer available now. They understand that all models are fallible, and the best current model will be eclipsed in due course, as will its successor models.

When we adopt the perspective of an optimistic model seeker, we stop thinking in terms of choosing between “agile” and “waterfall”, or any other model, for that matter. There is no reason to dismiss a model because it doesn't entirely fit your reality. Why not look at models together, rather than separately, in search for useful answers? Why not borrow from different methods and frameworks, to find a creative resolution to the tension between the two extremes of agile and waterfall?

Maybe your project is a complex legacy system, and because you need all the existing capabilities implemented in the new system before it can go live, the concepts of early delivery of working software and just-in-time requirements won’t add value to this project. Maybe your new system must be well documented in business jargon or it cannot go live due to the severity of the penalties the company would be facing in case of non-compliance, and thus the project needs to value good documentation as much as working software. Should you just ignore other agile practices that could be useful for your project only because it doesn’t entirely fit an agile model?

Just because a project cannot benefit from specific agile practices, it doesn’t mean that other practices found in agile methods, such as eliminating waste caused by partially done work, or getting user feedback for implemented features as early as possible, must be discarted. The concept of integrative thinking—the ability to hold two opposing ideas in our mind at once, and then reach a synthesis that contains elements of both but actually improves on each—has a good example in this TED talk. Graham Hill describes how he looked at two existing models, being a meat eater (which causes environmental and health problems), and a vegetarian (which would take away the pleasure he feels eating hamburgers), and instead of being contented with the opposing options that he was being pitched, found a pragmatic solution: become a “weekday veg”, which allowed him to cut 70% of his meat intake while still being able to enjoy a nice steak from time to time.

Approaches for software development should not be looked at as an "either-or" proposition, but rather as a "both-and" situation. Granted, it's much easier to be a “contented model defender”, merely following a methodology to-the-dot only because it worked in the past. The risk of this approach, though, is well summarized by Kieran Conboy[1]:

    Rewarding compliance to a commercial agile method might provide an undesirable incentive for developers to adopt a ‘square peg in a round hole approach’, forcing these methods into situations to which they are not suited.

Becoming “optimistic model seekers"--i.e., examining the characteristics of the project at hand, and questioning assumptions regarding what will work given its particularities--, is what allows project teams to develop a much superior model, one that works best for the present situation (but needs to be reevaluated at the next project).

Too many software projects offer unsatisfactory outcomes, including projects using commercial agile frameworks. By understanding the flawed thinking behind the stance of the contented model defender, business analysts can opt instead to turn into optimistic model seekers, looking at each new software project as an opportunity to combine traditional and agile practices to establish a winning approach to delivering valuable software.

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] Conboy, Kieran. “Agility from First Principles: Reconstructing the Concept of Agility in Information Systems Development. Information systems Research Vol. 20, No. 3, September 2009, p. 332

Like this article:
  8 members liked this article


Russell posted on Wednesday, December 7, 2011 3:32 AM
I couldn’t agree more with “all models are fallible, and the best current model will be eclipsed in due course, as will its successor models”.

But today's reality is the waterfall approach to system-software development has been eclipsed for a myriad of reasons.

Why can’t we all just step back and agree that the following values make sense to adhere to in any type system-software development effort, including the likes of a complex legacy system you described.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

It just so happens that the folks who came up with these values, needed to give this ‘eclipser” a name and they choose agile.

If you do not agree please take each of the values as they are exactly written and convince me that as they stand they cannot be applied to your complex legacy sytem development effort.
Marc Thibault posted on Wednesday, December 14, 2011 1:42 PM
From the right vantage point, religious wars can be fun.

- A fixed-price, no-exit contract with penalties for late delivery. (F-35s?)

- When you need to know what the product will be before you commit to a date and a price.

- When failure has consequences.

- When "in the fullness of time" is not a milestone.

- When scope creep is not an opportunity.

- When delivering is more important than billable hours.
Adriana Beal posted on Friday, January 6, 2012 9:15 PM
@rpanonne: My apologies, for some reason I didn't receive notification of your comment, and only now saw it here on the website. Let me try to answer your question now.

"But today's reality is the waterfall approach to system-software development has been eclipsed for a myriad of reasons."

See, it frustrates me when the discussion goes back to "waterfall vs. agile". Sure, waterfall has been eclipsed, and many project teams have never adopted waterfall, even though they are not agile teams either. Waterfall is not a good approach to software development, never was, unless you are talking about a very small project that can be completed quickly and efficiently in a steady sequential flow.

"Why can’t we all just step back and agree that the following values make sense to adhere to in any type system-software development effort, including the likes of a complex legacy system you described.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Why? Because sometimes you need to put as much emphasis in processes as in individuals and interactions, or in comprehensive documentation as in working software. The things agile favors aren't necessarily more important for project success. Two quick examples:

1) In my first agile project, too much emphasis in individuals and interactions over process and formal procedures led to individuals pursuing their own interests and prevented the team from creating a single vision for the product out of a diverse set of needs and wishes from multiple stakeholders. Until process started to be valued as much as individuals and interactions, the project remained a mess.

2) In highly regulated environments, try to bring into production working software that is not well-documented. You will not be able to do so, and what you are left with is a system that may work well, but cannot be made to add value to the organization because it cannot get approval to go live.

Feel free to write back with additional comments, I'll be happy to continue the discussion with you!
Russell posted on Saturday, January 7, 2012 2:16 AM

Clarification - while there is value in the items on the right, we value the items on the left more. The what, why, who, when and how of system-software development and delivery is not one person’s vision alone nor should it be cast in stone; it needs to be a “shared” vision through evolution, negotiation and compromise between individuals, the team and the organization.

Specific to your #1 – seems to me the root cause of this problem was not the value itself but how it was interpreted.

Specific to your #2 – I am a firm believer when documentation is needed it is just as important to include its creation as part of planning/tasking out what it takes to get the feature (story/requirement) done.
Adriana Beal posted on Saturday, January 7, 2012 6:32 AM

I understand that the items in the left are just valued more, and still believe that this approach is not necessarily advantageous for all projects (while accepting that it's a positive approach for some projects).

Regarding #1, I'm not sure I follow what you are saying.

Regarding #2, I know many agilists that agree with your view, which I consider an "evolution" from early agile proponents who insisted on producing a bare minimum of low‐fidelity artifacts developed for the sole purpose of building the software for a specific iteration while ignoring important documentation intended to be utilized beyond the scope of development.

Still, I've seen in practice the statement "Working software over comprehensive documentation" do more damage than good, causing agile teams to overvalue "working software" and dismiss the importance of having documents capable of communicating what the software does and why it does it, with serious consequences for the organization after the product was deployed.
RequirementOne posted on Wednesday, July 25, 2012 9:32 AM
Thanks for a great article and some good considerations regarding Agile vs. Waterfall. I have worked in many projects over the years and I have found that having a pragmatic and flexible approach to how you manage a given project is key to setting the stage for your project execution. I have outlined some of our thoughts and experiences in this video blog:

RequirementOne posted on Wednesday, July 25, 2012 9:35 AM
Not entire sure why the link as not hyper linked, here we go again:
Adriana Beal posted on Wednesday, July 25, 2012 11:13 AM
Thanks, requirementone, for the compliment and the link you shared (will check it out as soon as I find the time).


Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC