Lean Developer Weblog dedicated to lean and agile sofware development

Agile acquisition and fixed price

I have been quite busy lately and not been very active with this blog. However, discussion about agile acquisition has become more acute because there are few failed purchases in public discussion. I mean AKE and TEO, who's purchasing procedures have been questioned by Valtiontalouden tarkastusvirasto. See more (in Finnish)

General public and politicians typically react to problems by requiring more front-end design and rigor to the procedures. This makes the situation worse, because it increases unnecessary costs and bureaucracy.

At first we need to understand that hiring a designer is different than buying something that can be accurately defined before the purchase. When you buy design work minimizing the cost is not the only and not even the most important consideration. There are huge quality differences in the various solutions offered by the vendors. Comparing them is not straightforward and easy. One of them could propose a COTS solution, another something based on SOA and 3rd one a fully tailored solution. Obviously, it is not possible to define exact requirements without any idea of the implementation. Actually defining the exact requirements is exactly what the development project is supposed to do. If I knew exactly what I want I would not need the designer. The designer is hired for contributing while we work together to create the forthcoming software.

Because software development is a common endeavor with the buyer and the vendor, asking a fixed price is somehow skewed. I, as a buyer would probably get the maximum price with all of the risks included in the prise. If the competitive pressure keeps the cost too low, my vendor can very easily compromise the quality. It is also useful for me that my organization has an interest to lower the costs by removing unnecessary features. Prioritization is rarely happening in fixed price projects.

But I still have a budget, idea of return of investment. To keep the costs in bay I need to collaborate with the vendor to spend the money wisely. Monthly deliveries of done increments of functionality are a safe bet. If the vendor can not deliver, I have to stop the project (and have that allowed in the contract) and try something else.

Agile acquisition

I have added a comment to Agile Finland's forum
Neuvottelumenettely needs promotion

The Finnish law of public acquisition does not require that we do competitive bidding using comprehensive requirement specification. Public buyers does not, however, know the allowed negotiation procedure (Neuvontamenettely) that is more suitable for purchasing software development services. So, agile community should do promotion to improve the situation.

Read more details in the discussion chain. I have corrected the word neuvontamenettely to neuvottelumenettely.

Agile adoption strategy

In information security area, it is common to talk about strategy. I have used the following paper that condenses what is important: Information security strategy.

The case of agile adoption is similar though the details are different. In both cases we need some funding to make deep changes in the way we work every day. To even start we need decisions about who does and what and why just that. Large bureaucratic organizations love their process guides and still more they want to spend in developing tools for the forthcoming needs. It is not a coincidence that we have so many agile tool vendors. In the following I adapt the previous paper to agile adoption.

A strategic approach that works

1. Implement baseline practices
Typical organizations have a dysfunctional practices or a few of them. Starting with something that gives immediate and visual results is something that is needed to justify spending. Starting with Scrum-type retrospectives is a good choice because it gives us subjective measures of how successful we are when we continue. I like to call retrospectives Japanese quality circles to emphasize that agile adoption is a quality improvement initiative

2. Analyze your value stream
Now it is time to start what the consultants and coaches are so eager to sell you. Analysis will give you ideas of improvement. At least you must check the impediments of your agile adoption. If you don't have support of your customer or your upper management, it might be very difficult to succeed. I like Admed Sidky's agile adoption framework which gives you the order in which you should implement the agile practives.

3. Prepare business case for the improvement(s)
Now you must justify the adoption of the individual practices. Note, of course that they depend on each other. Creating a business case for each adoption step also gives you a view in which order your organization should go ahead. Of course you must consider risks as well.

4. Initiate your improvement programme
Now you are on your way with real money and as always with people and organizations you can't predict what happens. So you must use empirical process control to steer your way. You need to establish the part of organization that facilitates transparency, inspections and adaptations. Becoming public is a necessary part of this programme. People, all of them, are an essential part of this. They make the adoption successful, not the things ivory towers can deliver.

5. Manage and deliver the programme
If your agile adoption goes as normal, more and more of your problems will surface. Some of them can be handled by the teams, but some others need corporate level development projects. Of course, your programme has multiple deliveries.

6 Review progress
In continuous improvement initiatives like this you must have your Deming cycle installed so that you can really facilitate your way to success.

This is it this time - a draft that can be extended. Comments are allowed in this blog. Because I do not visit very often, it may take time before I publish them.