Why Is Agile So Hard To Sell?
What I find incredibly interesting is why defining value is so hard.
Agile proponents have been beating the value drum since the very
beginning. Put the customer in the room... understand their needs...
build what ever they want... deliver software in small increments...
get constant feedback... converge on the optimal solution... deliver
value early and often. Agile is all about delivering value. Why wouldn't a management team embrace a set of methodologies so focused on giving them what they need the most?
Here is my take...
Agile
is (in large part) a reaction to misapplied waterfall development and
naive application of project management principles in ways that are
inconsistent with how software actually gets built. It was is a
reaction to dehumanizing, process and artifact driven management
approaches... processes that assumed with enough procedures, we could
somehow commoditize the practice of software engineering. We wanted to
take the uncertainty out of a craft that is really a blend of
engineering and art. Our desire was to make everything predictable and
repeatable.
We were trying to treat people like machines that
could be infinitely sliced across tasks, tasks that with the right
level of process and planning, with the right level of project
management and oversight, would somehow magically roll up into working
software that our customers would want to buy. Guys like Jefferies,
Cockburn, Schwaber, and Sutherland were beginning to realize that
successful projects were really the result of high-performing,
committed individuals, working together in small teams, all directed
toward shared outcomes.
XP, Crystal, and Scrum were born through
the realization that these small empowered teams delivered the best
outcomes and were the most successful over time. As these agile
approaches were beginning to emerge, they all shared this disposition
toward small teams, close customer interaction, and frequent delivery
of value. The funny thing is that if you talk with most folks working
for small companies... this is kind of what they do naturally. Folks
are not assigned to a single role... you have a team of high-performing
individuals working together for the sake of their collective survival.
Big companies seem to have messed this up... but I digress.
Fast forward 10 or 15 years...
Now
we have pockets of agile within large organizations... sometimes we
might even have agile across entire large enterprises. We are exploring
agile methods and trying to see if they can deliver on the small team
promise... but in the large. The main difference with these larger
organizations is that value isn't the same as it is in a small team or
a small company. There is not a direct correlation between team
performance and business outcomes... there is not a direct connection
between what the team delivers and what we can sell to our customers.
It takes the output of too many small teams coming together to deliver
anything of value.
Agile methodologies have typically treated
the team like a black box. We give them a prioritized product backlog
as an input and we get valuable working software as an output. But
now... we have to coordinate the output of several teams... maybe even
dozens of teams... into some sort of coordinated deliverable. We are
having to deal with getting tens or hundreds of people working together
in a coordinated fashion. When that is our context... the message of
teamwork and collaboration... close relationships between the team and
the customer doesn't resonate. The only way many of these organizations
can get any sense of comfort... any sense they that they are
responsibly managing their part of the business... is to ask their
teams to commit to the big up front plan
As an organization, we
know that we need to deliver value as fast as possible. We know that we
need to be able to respond to change. We know that we need to deliver
with more predictability and with higher quality. We have an intuitive
sense that what we are doing isn't working. We want to get benefits
that agile talks about. We suspect that something like Scrum or XP can
help... but we can't figure out how to apply the small team concepts to
our particular business problems. That's why you get the classic "agile
will never work here " comments. There is an inherent disconnect
between the team level guidance agile methodologies talk about and the
bigger concerns your senior executives are struggling with.
There is a gap between value at the team level and value at the enterprise level.
At
the end of the day, our community needs to develop guidance that helps
our executives get the benefits of agile but focuses on real,
enterprise class value delivery... value defined in terms of real
results and real business outcomes. So, why is agile a tough sell? We
are asking our leaders to trust a process that focuses on team based
outcomes but doesn't give them a credible way to articulate how the
development organization is going to deliver on the more complex
objectives of the business.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Thierry Lefort replied on Thu, 2009/12/17 - 3:32am
It's all about money and the small increments at the end of the agile process scares clients. It's like a never ending story.
What clients like in waterfall is that they are no turning back once they have validated what they want it's no longer there problem. It's the developer's team problem.
In agile, clients are massively involved they have to say what they want and they have to assist meetings every week to monitor how developments goes, worst, during developments you are going to unveil some black spot they don't want to speak about.
That's why basic clients don't like agile, an agile project confront them with there greatest fear, the fact that sometimes they don't know what they want and they want you to find the best solution and they want to be able to blame you for having done the wrong choice.
Sometimes the first priority of clients is not having the perfect product matching exactly what they truly want and need. No, what clients want is not to be blame in case of failure.Menschens Kinder replied on Thu, 2009/12/17 - 7:09am
in response to:
Thierry Lefort
Wow Thierry, that's what I call hitting the nail on the head !
That's the reason why and your description is perfect !
Rod Claar replied on Thu, 2009/12/17 - 12:18pm
John Brown replied on Fri, 2009/12/18 - 9:11am
"Agile" is not hard to sell in my opinion. If you take a look at agile manifesto, I bet it's difficult to find people who do not agree with the values and principles.
But that's not people are usually selling. The worst agile zealots are trying to push e.g. XP everywhere and happily ignore reality. There are factors like money, (fixed price) contracts, law, system complexity (required level of upfront analysis and design), team skill level, geographical distribution, customer availability, system criticality etc. that must be taken into account.
If you are building a space shuttle software for NASA you certainly need a different approach than when you are building a small web-based intranet application. Iterative and incremental approach is definitely good but certain amount of up-front analysis and design is often needed especially with complex domains. Walking Skeleton-type incremetal architecture building allows scalability. Architecture doesn't just "happen" as some agilists claim.
The art of software development is to find the best situationally aware approach that suits the specific context.
Stop selling "agile". Start looking for context specific ways to win.
PS. I have seen some "agile" "Scrum" teams that were in reality code-and-fix style cowboy teams who eventually failed miserably.
Wal Rus replied on Sat, 2009/12/19 - 1:41pm