I’ve come in a bit late to this thread but there are some good points made. The ‘language’ and terminology’ issue is important and I don’t think it’s surprising that some non-IT will people will be intimidated and put off by it.

There are also some rather deeper issues which people need to recognise, in my view:

- Firstly, we don’t have agile financial planning in organisations. We have waterfall financial planning where people have to secure funding months – years even – in advance. On a so-called ‘agile’ project, it is quite likely that the key decisions on cost, time, and scope will have already been made in secret, in order to get this funding. You just don’t know about it. Not so long ago I was involved in (what I thought) was the early stages of piece of work to define options, scope and so on, and was told later that the business area already knew how long it would take, what they would be prepared to pay, and even, astonishingly, what the technical platform would be. I only found out about this by accident. Furthermore it’s not a rare occurance. I wouldn’t go so far as to say that agile is often ‘window-dressing’ (I do know someone that has said this) – but it’s not far off it sometimes. If you’re wondering why stakeholders and users don’t turn up for your stand-ups or are reluctant to get involved generally, it’s probably because the decisions have already taken and promises made. In their view, how it gets delivered – be it agile, lean, fat, waterfall, pretty-spring-in-the-highlands, doesn’t make much odds.

- Securing funding DOES mean up-front-definition of what you are going to do. This is the reality of the world. (Not a world I would have created, but the world we’re stuck with). Waterfall attempted to address this but fails by assuming it is all a one-off exercise to be handed-off when ‘completed’. This is clerarly a nonsense. On the other hand, though, if you do accept that iterative or agile development is going to result in an evolved, changed, and improved product as you go along, you still need a coherent ‘whole’ to come back to. A system is greater than the sum of it’s parts. The individual pieces, stories, journeys, whatever-else, do take on a different meaning when assembled together. All of this needs to be understood, together with the business knowledge that goes along with it. So, in a away, there is a need for some ‘waterfall-esque’ activity – even if it just providing education to people (and by this I mean for IT AND the business/users – you can’t assume that latter are mystical deities with all the answers, necessarily. I get rather perturbed by the reverence in which the user is held by some agilists).

As a previous contributor wrote: “Some of the problems now faced in Agile have been solved by other communities – but alas, the communities don’t interact too well together”. This is definately true: The IT industry has a poor record of learning from it’s own past. and frankly, doesn’t learn or remember from what has gone before. Other professions do.

All the best,

Mike

Including this presentation from Agile2007 by a Product Owner (i.e. “customer”)
http://www.infoq.com/presentations/alexia-bowers-agile-leadership

It is not uncommon for a coach and customer to present together at this conference. Agile2010 is in Nashville, a high-quality source of information – attended by developers and their customers.

deb

I’m really pleased I posted this article now as I would not have heard of either your book or the SEMAT initiative which both sound like they’ve come from similar frustrations. I shall look forward to investigating both further.

Good to see folks questioning things and not accepting “just because”. I am about to launch a new book titled “SDLC 3.0: Beyond a Tacit Understanding of Agile” which is something akin to your perspective.

I agree about the “IT centricity” of our terminology and what amounts to Agile jargon. We know that most of the terminology is invented and relates to concepts and ideas that have much earlier origins. This differientiation has had success within IT but has also caused some to turn off; and it is definitely not business terminology. I believe that the world of Lean and “more for less” is now as important to customers as “being agile”. The business/customer understands “value-streams”, collaboration, waste reduction, cycle-time and throughput. They don’t care about daily scrums, chickens and pigs, YAGNI – in fact in my experience it makes IT look ridiculous.

The ideas presented in the book call for a “Complex Adaptive System of Patterns” rather than wholesale methods. I make a case for integrating practices independent of method brands such that experience can be leveraged. There are some universal truths across modern methods which serves a common ground (iteration & negative feedback, waste reduction, customer collaboration due to tacit knowledge). But each community (Lean, Agile, Unified Process) grew up from a different set of experiences, so the practices yield potentially unique value propositions. Some of the problems now faced in Agile have been solved by other communities – but alas, the communities don’t interact too well together.

The book presents a rationale for what Agile really is – a brand and a movement. And while the values of the Agile Manifesto are “superstitiously declared” as per David Anderson, the practices behind Agile are very sound, and are based on Systems Theory, Theory Y management, Emergence and other foundational science. For furthering the Agile movement beyond the “Trough of Disillusionment” as Gartner says, I believe that various bodies of knowledge – like Control Systems Theory, (or as Alistair Cockburn believes, Gaming Theory) can take us to the next level.

I have been blogging about these issues at http://www.fourth-medium.com/wordpress . And if you are looking for others that are thinking similar thoughts, check out the SEMAT initiative – http://www.semat.org/bin/view – which includes at least 4 well known Agilists – Robert Martin, Ken Schwaber, Alistair Cockburn and Scott Ambler.

One way or another unless you extract high quality requirements from “the customer” you can’t “add value” by rapidly designing/coding/testing application that solve real business problems.

My point is not that Agile is not customer focused in principle, but that none of the the debate and formation of the principles, methodologies and tools under the agile umbrella have ever involved the customer. The Agile customer is almost some god like creature we worship but are too in awe of to actually ask what they think. The process of Agile adoption and our ability to solve the bigger problem of realising business value would be a whole lot easier if we did.

However, I’m confused. I’ve been practising agile for three years now, and while I don’t claim to be the world’s biggest expert, I’m very familiar with it and similar practises. My understanding is the agile tries very hard to engage the customer in the software development process, so that we developers might understand them, their requirements and their priorities better, and they might better understand what we’re up to, what our risks are, and how we are progressing.

To my mind, this sounds like exactly the sort of engagement with customers that you say is lacking in agile. So clearly you mean something other than this – but I have not understood what that other thing is.

If an agile developer like myself doesn’t quite see what you’re getting at yet, then I feel as though you need to describe it in more specifics.

With respect,

Jonathan