Moving Towards Selling Agility

Companies are in various stages of readiness to adopt XP. Managers understand CMM but not XP. They need to be sold on AgileMethodologies and not on ExtremeProgramming. Since developers want the work environment to get better they will help to install agility. Starting with "XP-incompatible" practices companies can be brought to a higher level of agility by installing it where they need it. The point is to move from 0 agility upwards.

In some companies the sales department is selling what the production floor can't deliver. You can't just tell them "we're changing the way we sell" and have them change overnight. The changes need to be introduced gradually.

Companies need to learn how to use the knowledge they acquire in their day to day business. Many companies make the same mistakes over and over. Rather than trying to break the cycle, however, we must bend the cycle. The transition must be smooth and un-noticeable.

Now we're extreme.

As I think about this, I'm still not sure that it isn't better to have the project hit RockBottom? and then throw everything out and go with a clean slate. But maybe I'm too extreme. -- IainLowe

Surely after having hit RockBottom? the project will be in a state where a change is strongly desired. But then you'll have to explain the (methodology) mistakes made (or else I don't see how you would sell agility. See FirstLawOfBadManagement) My bet is that you can best persuade any important actor (and don't forget the others too) in the project before a total collapse. Arriving after the battle is far too easy. Coping with the project in its current state can be very hard, but then you have material and people available. In my particuliar work environment, we don't have agile teams to sell to customers; rather we have to teach agility to customers. --ChristopheThibaut

I like that Moving is in the title of this page. We can use agile principles to sell agile methodologies.

I'm not sure what bending the cycle involves. The image of stepping out of the cycle to gain a clear perspective of where the problems are is appealing to me. That may be extreme but Courage is one of the ExtremeValues.

I believe one of the first steps is to remove some of the current myths about software development.

software development is not predictable (we cannot foretell on the basis of observation)
software development is not speculative (theoretical cannot replace demonstrable)

Once these myths have dispelled, the habits and behaviors associated with these myths (e.g. BigDesignUpFront) need to be exposed as flawed. This is done to preclude the FirstLawOfBadManagement.

This may well invoke fear. I see this necessary for the buyer to be WillingToChange. Which has me thinking, do we only look for customers with ExtremeValues?

Now we have the buyer interested, scared but open to other ways. Now we can teach the buyer, but you have to sell them the need to be taught first.

This approach will not work if the fear invoked triggers a flight response. However, if it invokes a fight response we may have a potential buyer.

When I wrote it, bending the cycle meant fixing repeated mistakes incrementally instead of all at once. You can't engineer agility.

I think that Courage may be the most basic or maybe the "first" value because without it we remain trapped by our fears in our old ways. We need to confront our problems head on and solve each one once and for all. We speculate because we are afraid of failure (and thus rather than try we guess) and we predict because we are afraid of uncertainty (so we prepare for every contingency).