Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

Why Is Agile So Hard To Sell?

12.17.2009
| 9963 views |
  • submit to reddit

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.

From http://www.leadingagile.com/

Published at DZone with permission of Mike Cottmeyer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

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

Nice annalysis, Mike. The other thing I am seeing is that managment does not have or is not willing to apply the resources to really manage the product in an agile way. Therefore they are likley guessing about features and how the customer uses the product. What we need is a way to help the product managment team be more agile. Rod Claar http://effectiveagiledev.com/Articles/tabid/70/EntryId/13/Agiles-Impact-on-Product-Development.aspx

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

it's a hard sell because it claims ignorance on the part of managers and executives, if on the other hand, we as developers simply say... oh, i need to talk to the customer as i have a problem with understanding x,y,z; or "it would be nice to do an early release and get a feedback" and so on, without even saying anything along the lines: "We are going to go agile" or whatever the latest 'agile' that claims the excellence and advancement on my/developer part and ignorance on part of management; that will change things. Until we stop making them (management) feel stupid and inferior 'agile' anything will be a hard sell.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.