What do you think?
Rate this book
Agile Contracts: Creating and Managing Successful Projects with Scrum
A methodologically sophisticated, comprehensive approach to applying the Agile fixed-price contract to IT projects while maximizing customer and supplier relationships
"Interesting and necessary for IT managers and IT lawyers." -Walter J. Jaburek, Dipl.-Ing., Dr. iur., Dr. techn.
Approximately 50 percent of software developers use Scrum, an iterative and incremental development method for managing software projects and product or application development, in their work. The benefit of Scrum and other Agile methods is that they can address shifts in a large project that traditional managerial methods cannot.
Written by pioneers and leaders in the field of Agile and Scrum, Agile Contracts is the only book dedicated exclusively to the legal, procurement, and project management considerations of Agile contracts. Providing templates, a toolbox, and examples of Agile fixed-price contracts, the book presents an alternative option to fixed-price, time-based, and supply-based contracts-reducing the risk for both the supplier and the customer with a contract that offers the possibility of flux and flexible scenarios as a project progresses.
Agile Contracts features in-depth chapter coverage
The Agile Manifesto of 2001 Agility from the perspective of procurement and the software provider The problems with traditional fixed-price contracts and time material contracts What the Agile fixed-price contract is and how it is set up Tendering based on the Agile fixed-price contract How to negotiate an Agile fixed-price contract Special guidelines for the legal framework of an Agile fixed-price contract Adaptable Scope System The Black Swan scenario Contracts and procedures for the featured methodologies Especially applicable within highly structured business organizations, Agile Contracts is a must-read for project managers, agile practitioners, procurement representatives, and IT lawyers.
"Interesting and necessary for IT managers and IT lawyers." -Walter J. Jaburek, Dipl.-Ing., Dr. iur., Dr. techn.
Approximately 50 percent of software developers use Scrum, an iterative and incremental development method for managing software projects and product or application development, in their work. The benefit of Scrum and other Agile methods is that they can address shifts in a large project that traditional managerial methods cannot.
Written by pioneers and leaders in the field of Agile and Scrum, Agile Contracts is the only book dedicated exclusively to the legal, procurement, and project management considerations of Agile contracts. Providing templates, a toolbox, and examples of Agile fixed-price contracts, the book presents an alternative option to fixed-price, time-based, and supply-based contracts-reducing the risk for both the supplier and the customer with a contract that offers the possibility of flux and flexible scenarios as a project progresses.
Agile Contracts features in-depth chapter coverage
The Agile Manifesto of 2001 Agility from the perspective of procurement and the software provider The problems with traditional fixed-price contracts and time material contracts What the Agile fixed-price contract is and how it is set up Tendering based on the Agile fixed-price contract How to negotiate an Agile fixed-price contract Special guidelines for the legal framework of an Agile fixed-price contract Adaptable Scope System The Black Swan scenario Contracts and procedures for the featured methodologies Especially applicable within highly structured business organizations, Agile Contracts is a must-read for project managers, agile practitioners, procurement representatives, and IT lawyers.
440 pages, Kindle Edition
First published January 1, 2013
6 people are currently reading
56 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 4 of 4 reviews
June 17, 2017
This is the least boring book on contracts and procurement I've read. It describes Agile Fixed-Price contract from different standpoints (buyer, supplier) and also gives a bunch tips on negotiating and convincing parties on using these types of contract.
October 18, 2018
The book starts with the usual description of agile and scrum (something too few know properly anyways) but it is fast-enough changing the topic to be more business-oriented.
The idea of the presented "agile fixed price contact" is simple: basically yielding a contract that defines a prototyping period (one would say) for which the same resources must be used from the implementor company and a longer implementation phase. The contract is made to be terminated at any time, but it has an indicative fixed price for the whole project that however only gets written in stone after the prototype period. The contract also covers that functions can be changed "freely" to something else and if the something else takes longer who will pay how much of the extra fees.
Also the contract encourages finishing on schedule and on less money by giving the implementors a bonus when things are done faster and cheaper: the implementor then gets x% of the remaining budget with no work to do for that. There are a lot of small adjustments and examples, but these are the key stuff to know.
The prototyping period helps when we need to give a fixed price contract for the requirements of the customer (when he works like that always etc) but we are not sure what to deliver. This is the case for any non-trivial project basically so most people either think they can over-engineer a waterfall-style document to defend their back (leading to contract discourses and bad / warlike business environment between customer and implementor) or just guess or pay hourly fees. This book compares the new method with the usual fixed price and the hourly-fee alternatives and describes a lot of practical knowledge (many from real world scenarios).
I already know projects where this could have worked: I know a project that my former company won for big money, just to later find out there is a hostile company in the picture who defends its already existing foothold for the software. This is not something one can always imagine (and the project was arranged by very senior project manager who could not see this beforehand) so an agile fixed price would have helped: if the other company for the same customer would still withheld information, we could re-negotiate prices after the prototype period, but if he would trick us in the prototype period and only later become hostile at least we would gain two-three months of time while they are more helpful. In any ways, it would be better.
Of course not a magic bullet, but usually works. Sometimes overkill, but mostly not an overkill if a waterfall-like fixed price contract would be in its place otherwise. The authors also tried to show the construct from multiple perspectives (customer, implementer, workers, etc.)
The idea of the presented "agile fixed price contact" is simple: basically yielding a contract that defines a prototyping period (one would say) for which the same resources must be used from the implementor company and a longer implementation phase. The contract is made to be terminated at any time, but it has an indicative fixed price for the whole project that however only gets written in stone after the prototype period. The contract also covers that functions can be changed "freely" to something else and if the something else takes longer who will pay how much of the extra fees.
Also the contract encourages finishing on schedule and on less money by giving the implementors a bonus when things are done faster and cheaper: the implementor then gets x% of the remaining budget with no work to do for that. There are a lot of small adjustments and examples, but these are the key stuff to know.
The prototyping period helps when we need to give a fixed price contract for the requirements of the customer (when he works like that always etc) but we are not sure what to deliver. This is the case for any non-trivial project basically so most people either think they can over-engineer a waterfall-style document to defend their back (leading to contract discourses and bad / warlike business environment between customer and implementor) or just guess or pay hourly fees. This book compares the new method with the usual fixed price and the hourly-fee alternatives and describes a lot of practical knowledge (many from real world scenarios).
I already know projects where this could have worked: I know a project that my former company won for big money, just to later find out there is a hostile company in the picture who defends its already existing foothold for the software. This is not something one can always imagine (and the project was arranged by very senior project manager who could not see this beforehand) so an agile fixed price would have helped: if the other company for the same customer would still withheld information, we could re-negotiate prices after the prototype period, but if he would trick us in the prototype period and only later become hostile at least we would gain two-three months of time while they are more helpful. In any ways, it would be better.
Of course not a magic bullet, but usually works. Sometimes overkill, but mostly not an overkill if a waterfall-like fixed price contract would be in its place otherwise. The authors also tried to show the construct from multiple perspectives (customer, implementer, workers, etc.)
March 22, 2016
Overly complicated legal jargon, that forces you to doze off from time to time. Nevertheless, the practicality of the book is priceless.
Read
July 23, 2018I'm not really able to rate the book because I stopped reading it after a while. Not because the book is bad but because of the entire topic "Agile in enterprises" annoys me. Almost all enterprises I know are not really willing to make the transition to "Agile". So, a book will not help. On the other side, people who understand what it is all about will properly not need to read it anymore ;-)
Anyway, I found some good aspects you may need in discussions with your customers.
Anyway, I found some good aspects you may need in discussions with your customers.
Displaying 1 - 4 of 4 reviews