This, That, and the Code

Just a thought… Has anyone ever applied the ideas of Extreme Programming to Business Development.

I wonder what applying them in the business context would do, or if it makes sense for projects in general?

The following is culled from the XP practices guide and changed to apply to business where possible.

The Planning Process, sometimes called the Planning Game.

The planning process allows customers to define the business value of desired features, and uses cost estimates provided by the company’s employees, to choose what needs to be done and what needs to be deferred. The effect of this kind of planning process is that it is easy to steer the project to success.

Small Releases.

Agile teams give the client a working product, and update it frequently on a very short cycle.

Simple Design.

A product built in an extreme way should be the simplest solution to customer’s current requirements. There is not much building “for the future”. Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in this extreme system it is brought about through “refactoring”, discussed below.

Testing.

Extreme teams focus on validation of the product at all times. Employees develop products by identifying ways in which the product does not match a customer’s need and then design a minimal change to the product that would make it do so. Customers provide acceptance tests that enable them to be certain that the features they need are provided.

Refactoring.

Extreme teams improve the design of the system throughout the entire development. This is done by keeping the process free of duplication, communicative, simple, yet complete.

Pair Programming.

All employees work in teams. Two employees to one position.

Collective Ownership.

Everyone owns all the product designs. This lets the team go at full speed, because when something needs changing, it can be changed without delay.

Continuous Integration (May not be practical with brick and mortar designs)

Quick prototyping is key. And it should be possible to prototype the system at least daily. This keeps all the product developers on the same page, and enables very rapid progress.

40-hour Week.

Tired employees make more mistakes. Extreme teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.

On-site Customer.

An extreme project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a product process.

Standards.

For a team to work effectively in pairs, and to share ownership of the products, all the employees need to document designs in the same way, with rules that make sure the product designs communicate clearly.

It’s interesting to see how these rules sound when placed in a Business context.

Agile Development | RSS 2.0 | Comment it , or trackback this post.