Last week I went along to an Agile Evangelists Meetup in London. The speaker was Kim Lennard, who works for consultancy firm Equal Experts and is currently working with one of their clients, O2. Her background is in managing Agile transformations, which is what she has been involved with for the last couple of years at O2.

There was no fixed “theme” for this particular meetup, but instead, Kim ran a sort-of “open-space” forum, where we were all invited to come up with questions/topics, and then we voted for whichever ones we wanted to discuss first. Once we’d voted, it turned out that nobody really wanted to talk about the topic I’d suggested, which was “how do you implement agile in a company which has geographically distributed teams” (even cheating and voting three times for my own topic didn’t work) but rather, people seemed to want to talk about “How Fixed Bid & Agile Go Together“. There were a lot of agile consultants in the crowd, clearly, and I was outvoted 😦

How Do You Do Fixed Bid With Agile?

Not being an agile consultant, I didn’t really know what a “Fixed Bid” contract was, or how it worked. Basically fixed bid contracts have an agreed up-front cost, and payment isn’t based on the amount of time or resources expended so you can understand how this might seem incompatible with agile. Interestingly, Kim said it was always a good idea to find out why a contract was being done on a fixed-bid basis, rather than cost-plus, for instance. I got the general impression that fixed-bid contracts were difficult to deal with and if possible, it would be favourable to convince the client to alter their contract basis. Of course, that’s unlikely to be possible in most cases, I would imagine.

Great Expectations

Kim’s first bit of advice for dealing with fixed-bid contracts was to manage expectations appropriately. Fixed Bid is a harder environment, and you have to manage the risks associated with it.

You have to be smart about how you manage expectations

One way of doing this is to get the client involved on a day-to-day basis, so they can clearly see and understand the challenges and issues you experience every day. These challenges and issues represent the risks to the project – if the client sees and experiences them at first hand, just as you do, then their “expectation” will be accordingly adjusted. I liked this bit of advice and I would also encourage this “good-practice” to be extended to all agile projects, not just fixed bid!

Great Expectations are good, Realistic Expectations are better.

When I was at university, I decided to catch up on some of the classic literature that I had widely ignored during my school days, and embarked upon a mission to read the likes of Dickens, Dostoyevsky, and that other bloke who did the plays. I started with Oliver Twist by Charles Dickens, which I loved, and then went on to read Great Expectations, which wasn’t as good as I thought it would be. Haha. Aside from that being an awful joke, it highlights the need to manage expectations appropriately. With fixed bid contracts it’s essential to highlight areas of risk and make sure you don’t over promise & under deliver – you have to be pragmatic and realistic. Let the client know exactly what represents a risk to delivering on time & on target. In other words, don’t give your client Great Expectations unless they’re also Realistic Expectations.

What are the Risks?

Kim identified a number of factors which could contribute to projects not delivering on time or on budget (i.e. risks), and these are:

• Over-promising. This leads to under-delivering, obvs!
• Not knowing your team’s velocity. Maybe they’re a new team, and not very well established. This could mean that you under or overestimate the velocity from one sprint to the next, leading your client on a merry dance, and thus risking their trust.
• Relationship with the client. How well do you know your client? Do the clients understand you and your team? Is there trust? Do you have shared goals and a shared ethos? If the answer is “no” to any of these, then you have yourself a risk!
• Dodgy requirements! That old chestnut 🙂 If the requirements are unclear or subject to change, then this is certainly going to impact your delivery and as such this must be flagged as a risk.