How do you sell an agile project? Most customers expect to buy software by time-and-material or by fixed-price-fixed-scope contracts based on detailed requirements. These models can not create a fertile environment for collaboration between customer and supplier. In this presentation, we will report on our experiments with commercial contracts that supports an agile development process, based on concrete examples of win-win contract types. We will outline the different aspects of these contracts, as well as experiences creating and delivering software solutions under these contracts.

Agile development has grown a lot since its rebeleous 2001 start. In fact, it has grown to be the mainstream way of developing software.

The time has come to drop the word ‘agile.’ Agile development is just modern practices in software development. There is no need to explicitly mark practices as Agile. There is no need anymore for opposing camps. Keeping the word Agile and things like “the Agile conference” is holding the development of modern SW development practices back.

This session will be in debate form to discuss the above mentioned motion.

To make lasting changes, we need to visualise the situation, understand the system, know how to improve it and work together. The Theory of Constraints tells us how to do all that.

In this game, we apply the “Five Focusing Steps” process improvement method from ToC. Step by step we use Agile, Lean and Real Options techniques to make our “work” more fun and productive.

After the simulation game, you’ll be able to apply these techniques to your work.

You’ll be able to use the open source “Bottleneck Game” to share these techniques with others.

Max. 60 players

When my Scrum-style backlog grows up, it wants to be an FDD feature list … or is it the other way round?’ Why does Feature-Driven Development (FDD) organize its feature lists into a hierarchy? Why does FDD use a specific template to name the items in a feature list? While a Scrum-style backlog for a single team may never grow to more than a couple hundred items, backlogs serving multiple teams may easily do so and become hard to work with. We compare Scrum-style backlogs and FDD-style feature lists, and consider the relative merits of different ways of working with large backlogs.

I propose that the larger issue with Agile Contracts is not that we don’t know how to write them. After all we know how to deliver Agile projects, so a contract can simply describe that process. The problem is with making Agile Contract commercially competitive; against suppliers who are offering the promise of delivering the perfectly predicted dream - offering the certainty that people crave. This is a prisoners dilemma, with organisations driving themselves towards a sub optimal solution. Through game theory we will explore ways in which to improve the appeal of the agile offering.

Bob Scoble Esq. and Ted “Theodore” Logan are about to embark on a new technology start-up venture when a mystical figure with a fondness for beagles and the Galapagos Islands appears before them, promising great prospects for their new business if they first agree to accompany him on a unique adventure. They accept. Spotting a theme common across the many amazing conversations they have subsequently, Bob and Ted decide to follow the XP principle of doing extreme amounts of the practices that work: they implement the world’s first completely Darwinian complex systems risk management program.

Agile development has taken a number of concepts and principles from the study of complex adaptive systems. But since the birth of the Agile Manifesto, the study of complexity has not stopped. In this talk I give a number of ideas copied from complexity experts, and I will review what fitness landscapes, patches, power laws, and incompressibility could mean for agile software development.

For almost a decade our community has claimed that agile is a risk-driven approach. Yet there is very little published material on agile risk management. Traditional risk management is based on avoidance of external variations. While, traditional project scheduling treats tasks homogeneously from a risk perspective. Lean pull systems and Real Options Theory provide new means to manage overall business risk in technology projects. This tutorial describes 3 techniques that evolved in the kanban community that increase sophistication of risk management and provide improved business agility.