Following on from the announcement of the Flexible Contract model that supports agile development at the Agile 2013 conference, Susan Atkinson and Gabrielle Benefield have released a version of the contract under Creative Commons licensing and made it available for download.
How do we embrace agile software development, while protecting business transactions from harm, and dispute? The legal profession is risk adverse, and seeks permanence over change. But complex software development require adaptation to change. This article summarizes one angle on this debate.
Tom Arbogast, Bas Vodde and Craig Larman have released a sample chapter from their upcoming book on scaling Lean and Agile. The chapter deals with the difficult topic of writing contracts for agile development.
Agile and Lean projects are run differently from traditional projects. But will those projects' contracts support or undermine Lean and Agile concepts? Here are some tips on how to write an effective contract for a Lean or Agile project.
In large organizations and projects, it's not unusual for an Agile team to find itself shackled to a non-Agile partner/vendor/supplier. Friction ensues, energy is wasted. While the solution might appear to be: "hire better teams", Scott Ambler goes to the root of the problem, providing a strategy for creating better RFPs: ones that attract Agile teams.
While the Agile Manifesto says "Customer collaboration over contract negotiation", contracts are a reality for many developers and firms. Peter Stevens has analyzed 10 different types of development contracts, shedding light on how well each style fits an agile project. He has uncovered a couple that seem to fit much better than either fixed-price or time-and-materials.
Traditional software contracts have often pitted the customer and vendor against each other. Several Agilists in the past have taken a stab at defining an Agile contract which improves the relationship between the customer and the vendor. A working group is collaborating on OpenPlans taking a step further in this direction and coming up with a reusable Agile contract.
In this presentation at RubyFringe, Obie Fernandez shares his experience selling consulting services for both Thoughtworks and Hashrocket and gives advice on how developers/consultants can deal with clients by setting minimal requirements, saying "No" and how to choose hourly rates and much more.
Contracts are the seam that tie together different organizations. Traditional contracts are based on mistrust and a CYA philosophy. Fixed price contracts don't take into consider the uncertainty of software development. Time-for-money projects are not based on value delivered - a team can work for a long time and not have much to show for. The Agile community is looking for something better.
Last year Ternary COO Alexia Bowers walked a mile in a project customer's shoes, and told us how it felt in this Agile2006 Leadership Summit presentation. She stressed the need to meet deadlines through creative solutions, instead of simply cutting scope.
In Harvard Business Online this week, Donald L Sull and Charles Spinosa wrote about the practice Promise Based Management - using promised commitments in the organisation to enable organisational agiity, encourage entrepreneurship and stimulate collaboration.
In a recent newsletter, Scott Ambler looked at why fixed price projects tend to overrun and often fail to solve the business problems they set out to conquer. Scott named the key problems in fixed price projects, identified the bad habits they encourage for customers and developers, and ended with a call to revisit how we fund our IT projects, offering an alternative.
On the high-volume ScrumDevelopment newsgroup, an interesting question has appeared, once again: "Is it possible to run SCRUM with fixed price contracts especially custom projects?". Ron Jeffries, Mike Beedle and others offer replies from experience.