Kurt Haeusler – Offers and Pricing in Agile and Lean Software Development


Is there a way to shave years off of the trial and error implementing Agile?
Find Out Now.


One of the most important aspects, and also one of the most forgotten, for establishing how effective our investment in agile and/or lean software development effort is, happens very early in the process before “the team” is even involved. All too often a well-meaning manager makes a deal for a new project, typically based on either a time & materials, or a fixed-price / fixed scope pricing model, hands it to the Scrum team, and wonders why motivation and customer-relations suffer, quality drops and the projects fail to meet financial expectations.
Several years ago, there was some discussion about the hybrid “agile fixed price” approach, and some similar ideas, everyone assumed the matter was resolved, and there hasn’t been much talk about it since. These ideas didn’t seem to take off and fixed price / fixed scope and T&M still dominate.
This talk draws from more recent discussions in various communities such as flow-based development, lean startup, and the no estimates movement, and explains how the type of offer we make is a significant factor determining the extent to which we can leverage the potential of agile and lean approaches, it lists the problems with traditional and hybrid pricing models, presents a list of alternatives, and provides some basic dos and don’ts to help us discover which model is appropriate for our own contexts.
The talk deals very little with contracts as the speaker is not a lawyer, and contracts seem to be highly country-specific anyway. This talk is very much more on the customer collaboration side of things, and reducing risk via small batch sizes so that the importance of contracts is reduced to the level where the contracts themselves are mere formalities.

Kurt Häusler spent years as a programmer but the more he learnt about the nature of knowledge work and product development, the less suitable he found the management systems in place for allowing knowledge works to actually serve the needs of the customers. So he became a manager in order to create the type of company where he would want to be a developer again. He considers himself a servant leader, lean manager, systems thinker, Stoosian, rightshifter, Kanban expert, culture hacker and practitioner. He is working on adding coach, game player and story teller to that list.

Related posts: