и коммент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.
http://java.dzone.com/articles/why-agile-so-hard-sellIt'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.
