AGILE IN ACTION

A short while ago I said that fixed-price contracts don't work . Over on the Scrum Development group there's a discussion about competitiveness, estimates and organization culture . Dave Martin said: People underbid because it gets them the initial contract as many clients will just go for the lowest bid. Once the project is underway, the costs start to escalate and the client has 2 options - pay up or write the project off and start again. The client is often better off writing off their initial investment and starting over but its amazing how often they don't do that and continue to burn money. Keith Sterling responded: This is why so many large consultancies stick to the waterfall method. By bidding low and stipulating a waterfall approach, yet knowing that 99.99% of all projects will undergo 25-35% change during its lifetime, they know they will be able to make up the shortfall in their bid with high value change requests. It's a well known fact, yet unwritten rule that most large consultancies in the UK base their business model on the volume of change requests they can generate during a project, and why most of these organisations have some of the biggest legal departments I have ever seen. Where is the sense in awarding business based solely on the price? Price is meaningless without a measure of the quality being purchased. If clients award business to the lowest bidder they're likely to receive low quality and high cost. You get what you pay for. And the client-vendor relationship will become acrimonious as neither party is satisified and it falls to the lawyers to fight it out. Deming predicated that driving down the price without regard to quality and service will drive good vendors and good service out of business . He was right but it's actually worse. As Keith describes, we now see companies making money from providing poor quality by charging extortionate sums for change requests. It's part of their business models. What a truly sad state of affairs. Wouldn't it be better to enter into and nurture cooperative partnerships for the long-term that are built on mutual loyalty, trust and confidence, and which share the risks and the rewards? If you treat your partners as extensions to your business and align incentives so that everybody works for the good of the partnership, then quality will return, cost will fall, speed of delivery will increase, customers will be happy and everyone will realise prosperity.

But 9 women can't make a baby in 1 month. Despite popular belief, there isn't a direct relationship between coder-headcount and productivity. Developing software is a creative and often complex process. It's not data entry. The other day Gus was asked by a very senior executive why his team of 16 people were far more productive than another team of 150. Both teams work at the same company. The short answer is the larger team is following a waterfall approach in a bureaucratic and political environment, while the smaller team has achieved agility in an organisation enclave. Process has a lot to do with productivity. Ironically many processes, apparently designed to increase productivity, are actually impediments to throughput. They're more concerned with putting ticks in boxes and producing intermediate artefacts than they are about delivering business value with production quality software. Jeremy Miller lists many of the scenarios that slow down a traditional team using waterfall: Waiting for missing requirements. Struggling through ambiguous requirements. Not having timely access to the business people. Delays from sequential hand-offs between disciplines. Testers and developers disagreeing over the interpretation of a requirement. Testers receiving code and not knowing what or how to test the completed software. Having completed code, but not being able to quickly deploy it for testing. Rework because requirements were misunderstood. Slow response time when the business people change their minds. Assumptions about requirements or architecture being overturned. Elaborate documents that quickly become obsolete. Code that was written because it will be needed later ; it never was. The Agile Manifesto values individuals and interactions over processes and tools . You can do away with prescriptive process and achieve significant throughput if you have a disciplined, colocated and cross-functional team (that includes the product owner ), with people who communicate effectively, collaborate intensively and focus on delivering business value. In an environment where they are trusted to self-organise and make decisions, and where they receive feedback continuously, I bet these people will always deliver more than a traditional team ( more a group than a team ) in a command-and-control environment. Why? Because empowerment and ownership breeds responsibility, commitment, accountability and motivation. You'll see delivery, early, often and regularly. Disempowerment and control breeds mediocrity, apathy, fear and demotivation. People turn up but they lack commitment and they don't really take responsibility. You'll see missed deadlines, a distinct lack of delivery, and ultimately you'll smell the dead fish of failure . Skills and practices also affect productivity. Who's more productive? The developer using test-driven development and continuous integration , who checks in code and integrates with others many times a day, and who collaborates with testers performing exploratory testing in parallel. Or the developer who codes for days (if not weeks) before checking in and integrating with others and then hands-off to testers for manual ad-hoc testing, bouncing back and forth as he fixes bugs until the code is working? I bet it's the first developer. Give me an agile process in a lean environment any day.

It's got to be more effective to deliver each minimal marketable feature to production, without delays, where it can earn value for the business than to batch and queue unvalidated decisions . Hasn't it?