AGILITY: Extracting some Essentials
After reading the book Lean Software Development by the Poppendiecks (can be found in your popular bookstore) I felt somewhat enlighted. The authors shared their experiences and ideas about good project management and processing. Some of them I liked very much. Here is my personal impressions of Agility and XP. It should become clear that XP and Agility are not a magic bullet – the same goes for SOA, see my weblog entry Service-Oriented Architecture: What’s up with it?.
Decide As Late As Possible
On one hand a good thing, on the other impractical. Try to tell your customer he should trust you. I know of customers that examine the time reported to be accounted up to the minute. What would be the chances to persuade such a customer to decide as late as possible just because you tell him it is a good thing and it is an agile principle?
Deliver As Fast As Possible
Catchwords are: schedule, cost of deplay and tradeoff decisions. From the economical point of view the message behind those terms is apparent. For the software developer it means discomfort in most cases if a deadline will be overdrawn.When it comes to news or tutorial sites, speed is essential to be alwas up to date to the reader. This especially holds true for search engine optimization and online marketing as you can see with Erfolgsrezepte Online.
See the Whole
Seeing the whole means engaging a bird’s eye view. The whole from the point of view of the employees should be to have as much fun as possible during their work. For that personal habits should be followed. Superstition is another element mentioned in the book from the Poppendiecks. Superstition forces us sometimes to do things in a way that could not be followed easily with logic. More than that, the worker wants to see his beliefs reflected during his activity.
Seeing the whole for the company means relationships to other customers and partners. Here, contracts play an important role. Free yourself from the faith fixed-price contracts and paid-per-hour-contracts will be the only possible solutions. As we all know (if not drop a comment) a fixed-price contract is a dangerous mechanism when talking about the nowaday complex world of software technology. On the other hand some customers would nearly feel abnormal if not making a fixed-price contract. Perhaps they want to feel unhappy?
A shared benefits contract would be a good solution. The problem here is measurement. But this is the same problem as how to measure the productivity of a worker.
For your convenience, browse the following to find out more about Agility: