Skip to Content

Agile Principles

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:

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Kalle Pokkinen
    There is an obvious danger in the Agility approach that is not very often reflected in books and articles about the Agile methodologies.

    Agile methodologies should not be the first experience of development methodologies for most people if any, unless they are part of a team that has a number of experienced developers.

    Why? Well, simply because the developers with no methodology experience are unable to reflect this towards any other way of doing things. This again leads to missunderstandings where it is thought that anything that is structured or formal is bad as it is not Agile.

    Agile methodologies work well in senior, experienced teams (which can includes some juniors), but these teams already work naturally in a more “agile” manner, not because they specifically follow Agile methodologies, but rather because they have the experience so that they don’t require the same level of formality and written guidance than more inexperienced individuals need and can change their approach on the fly if the project requires it.

    Conclusion: In my experience agility works if the seniority condition is met, it is not a golden hammer, but it has it’s points. Just remember not to follow it blindly throwing away “old” good practises that work, just adapt practises that make sense and improve on the quality of your work.



    1. Klaus Meffert Post author
      Hello Kalle,

      I completely agree to your statements. There should be not a command to strong of agility in teams consisting of many junior developers and not enough senior staff. Additionally, I see agile principles as an addition, from which one can pick the best working elements suitable for his project. This includes seeing the manifesto not as an unbreakable package but as an agile mechanism itself, IMO.

      Being honest, it was observable with some publishers that they praised agility like a wonder, although warning of the dangers partially.




Leave a Reply