NAYIMA
Aug
19

Agile Fixed Price revisited – part 2

Agile Fixed Price Projects

In 2003 I wrote a two part article on Agile Fixed Price projects: “The Price is Right” and “Do you want Agility with that?“. These two articles were combined into one chapter for the “Managing Agile Projects” book. The tips are divided into three sections, corresponding to three phases:

  • Qualifying: do I want to take this project on and if so, how?
  • Selling: how do I get the contract in such a way that we can succeed?
  • Implementing: now that we’ve got it, how do we make this project a success?

What’s changed since then? What have I learned since then? What would I do differently. Let’s revisit each of those papers and look if the advice is still right. Then, we’ll see some new lessons.

In the previous blog entry I revisited “The Price is Right”. Today, we’ll have a look at “Do you want Agility with that?”

Qualifying Tip 1: Make sure you have a committed customer

Agile fixed price projects require greater effort and involvement from the customer. A hard release date is a good indicator of a motivated customer.

The customer will be more motivated, more willing to think about solutions if there’s the pressure of a hard  deadline.

In retrospect: this is clearly insufficient. A hard business deadline, not some invented meaningless deadline, is one positive factor in many successful projects. It’s also present in many tales of deathmarches. Necessary but not sufficient. A limited budget is always useful too; beware of customers who have too much money (they do exist). During the sales, we must test the customer to see if they’re really committed to this project. Ensure that you get to talk to everyone who will be involved in the project. If they don’t have time to see you during the sales process, they won’t have time to help you during implementation. Ensure that their goals are aligned with the project’s goals.

Qualifying Tip 2: Make sure you get timely feedback

We need timely and regular feedback from the customer. We put those customer commitments in the contract.

Customer collaboration AND contract negotiation. The customer has responsibilities too and those belong in the contract. If we don’t get the feedback in time, we can’t run the project. I’ve stopped several projects because the customer didn’t honor those agreements. We either resolve the problem (the customer ensures they make some people available) or we stop the project altogether. Maybe we’ll restart the project at a time that’s more convenient for the customer. See Selling Tip 2: It works both ways.

In retrospect: it’s about more than feedback. We need to agree on the way we’ll collaborate.

Sales Tip 1: Many small projects are better than one big project

Success rates are higher for small projects than for large projects. We reduce the size of the scope to only include a minimal feature set. As a result, the customer pays less, gets value sooner and can postpone decisions. I reduce my risk, get a chance to prove myself with the customer and can test our relationship with a small investment. But don’t do projects of a few days only.

Small projects bring lots of advantages to customer and provider IF we can keep the startup and transaction costs of each project small. As an example, at one time we had a rule that no project could take longer than three months and that we had to deliver at least each month for customer acceptance. The smallest project (an extra feature in a product) took one week from customer request to delivery of the product CD. Many projects had weekly delivery for acceptance.

In retrospect: the advice still stands, but we deal with scope differently. Instead of creating lots of User Stories and selecting those that have high value, we start with the Business Value drivers and then derive the minimal set of User Stories that will deliver the value. Therefore, our scope is minimal and sufficient by construction, not by elimination.

Implementation Tip 1: Let the customer sort the requirements

User Stories are ordered by the customer and implemented, as much as possible, in that order so that the customer gets the high value stories sooner, can test sooner and reduces the risk of dropping high value features.

Implementing this way is good for the team: we’re working with value- and business-driven priorities, we have to make sure that the user stories are independent to give the customer the liberty to sort.

In retrospect: the advice still stands. If the stories have been derived from the Business Value drivers, we will already have this ordering.

As an aside: many agile teams get off to a wrong start when they talk about this to their customer:

Team: we need you to order the stories by value and we’ll implement them in that order.
Customer: why is that important? As long as you deliver the scope, in any order, I’m happy.
Team: well, if we mis-estimate and run out of time we’ll drop some of the lower value stories.
Customer: what? You plan to run out of time? And you‘ll drop my stories? Do you guys know what you’re doing?

Mitigating schedule risk is one of the minor advantages of implementing by value. It’s more about delivering value sooner, getting information sooner, keeping the customer involved and mitigating the risk of building the wrong thing.

Implementation Tip 2: Requirements as stories. Don’t sweat the details

The requirements for the project should be expressed as high level stories. These stories’ contents have some margin for negotiation. The specification becomes shorter and easier to understand. We put less effort in creating the specification and we can delay decisions. This only works if I have a pretty good understanding of the domain and the customer. I need a good working relationship with the customer to be sure that the details will get filled in just in time.

We install a pull analysis system to create detailed specs just in time. We usually make this visible by having one or more columns on the kanban board that show this activity, so that we can quickly see if the customer is keeping up with the team.

In retrospect: the advice still stands, but how do you make it actionable? The best way is to start from Business Value Drivers and then to describe real Business Requirements. The specification and the contract shouldn’t fix implementation, they should specify the business goals to be achieved and the capabilities that must be delivered to achieve the goals.

Implementation Tip 3: Exchange Requests

If the customer wants to add a new User Story, they must first remove a number of User Stories for at least the cost of the new User Story. That’s the way we keep budget and timing constant. That’s the way we keep the price fixed.

Change Requests are evil. When we run a project (not only fixed price ones), we’re very strict on Change Control. Nothing gets changed in the scope unless we know there will be no negative effects. I don’t like change.

In retrospect: advice still stands. It’s simple, but very effective. A well-run project with Exchange Requests has a fixed price, fixed deadline and a minimum guaranteed value. The customer gets more value than expected, because they exchange high value new stories for lower value stories.

Implementation Tip 4: Put dropped requirements in a follow-up project

The User Stories that get dropped because of an Exchange Request are probably still useful (or they wouldn’t have been in scope in the first place). Never extend the current project, but define a follow-up project for these lower-value stories.

Fixed price, fixed deadline. The customer gets the system on the requested date. Qualifying Tip 1 means that the customer can’t afford to miss the deadline. If they want more, we’re more than happy to do another project.

In retrospect: the advice still stands. Moving deadlines reduce the value of the solution and demoralise the customer and the development team.

Implementation Tip 5: Let the customer use the software before the follow-up project

Let the customer use the delivered system for a while before starting the next project. The customer will learn a lot and come up with better ideas for the next project.

The best feedback comes from production use. Let the customer put the solution in production and start earning value. By the time we start the next project, the customer has more information and more money.

The problem is that we delay our income. I consider this a sound investment in a collaboration that’s valuable for both parties.

In retrospect: the advice still stands.

Implementation Tip 6: I’m the onsite customer

Not every customer can afford to have a full-time onsite customer in the team. In those cases, I as business analyst-project manager, can play the proxy customer role. This requires that the proxy customer knows a lot about the domain and that they know what they don’t know. Then we need to consult with the real customer.

Projects with a real onsite customer go measurably faster. Projects with a proxy customer are slower, but still faster than those with an off-site customer. We do need to be sure that we can get enough access to the real customers when we need it. That’s why we’ve agreed from the start how we’ll communicate and collaborate (see Qualifying Tip 2).

In retrospect: try to get a real onsite customer first. It may seem impossible, but if the project is value-driven you may be able to convince the customer. For example: “with an onsite customer avalailable N days, we can deliver the project one month earlier, which will bring an extra revenue of X“. If X is substantially more than the cost of N days, the customer would be stupid not to have an onsite customer.

Implementation Tip 7: Frequent releases, incremental delivery

Release frequenly for acceptance testing (for example once a week) and divide the project in one month increments that deliver a coherent set of functionality. The customer might discover that these increments are good enough to be used and will ask for incremental delivery.

The team and the customer need to learn to deal with regular releases. See how fast you can go today and decrease the “takt time” gradually.

In retrospect: the advice still stands. Unfortunately, I see more and more companies and team that go backwards, delivering fewer releases per year and increasing their cycle time. This leads to a vicious cycle, as releases get more complex and error-prone. Agile requires technical and operational excellence, otherwise frequent releases can’t be sustained.

Implementation Tip 8: Looking back to learn

Take time to look back and learn in a retrospective. Review actuals versus estimates to provide the basis for future estimates. Preserve new knowledge about risks and how to deal with them.

It may sound self-evident that you’d do this, but I’ve seen very few companies that learned from projects. In many cases there are retrospectives, but no actions or no time (or courage) to tackle root causes. Many projects feel like Groundhog Day: an endless rerun of the same mistakes with no hope of escaping. An ominous voice in my head keeps repeating “It is happening again. It is happening again.”

In retrospect: sound advice, but how do you make it actionable? Make sure that you find and tackle root causes using, for example, Systems Thinking techniques. Make sure that actions are defined and performed. Keep track of real project measurements, especially actual cost and time versus estimate.

And the score is…

Most of the advice still stands but the implementation should be described better to make it actionable.

We have changed the way we do analysis: instead of discovering the scope and estimating value, we define value and derive the scope from that. This value-driven approach brings several benefits:

  • The scope is minimal and sufficient by design, so we spend less time on it
  • The project is value-driven, which make prioritising and assigning an onsite customer easier
  • We negotiate about value first, cost second. Customers have no problem paying if they’re convinced of the value.

I’ve learned that the techniques from the two articles need to be taken together. It’s not “Do you want Agility with that?”,  but “You need Agility with that”.

There are some more tips I’ve collected over the years. We’ll look at them in the next entry.

August 19th, 2009 | Category: agile, agile analysis, books
Aug
17

Agile Fixed Price revisited – part 1

Agile Fixed Price Projects

In 2003 I wrote a two part article on Agile Fixed Price projects: “The Price is Right” and “Do you want Agility with that?“. These two articles were combined into one chapter for the “Managing Agile Projects” book. The tips are divided into three sections, corresponding to three phases:

  • Qualifying: do I want to take this project on and if so, how?
  • Selling: how do I get the contract in such a way that we can succeed?
  • Implementing: now that we’ve got it, how do we make this project a success?

What’s changed since then? What have I learned since then? What would I do differently. Let’s revisit each of those papers and look if the advice is still right. Then, we’ll see some new lessons.

First, let’s re-read “The Price is Right“.

Qualifying Tip 1: Do I know what I’m doing?

I’ll only enter into a fixed-price contract if I can specify, estimate and plan the project as agreed, within a small tolerance.

I need to ask myself four questions:

  1. Am I familiar with the domain? If not, I’ll spend a lot of time learning and won’t be able to help the customer define what they really need.
  2. Am I familiar with the technology? If not, I’ll spend a lot of time dealing with stupid technology issues.
  3. Am I working with my usual team? If not, I’ll spend a lot of time building the team and I won’t be able to use velocity to estimate.
  4. Am I used to delivering projects of this size? I not, I’ll spend a lot of time scaling up my usual practices.

In retrospect: the advice still stands, not just for fixed-price projects.

Selling Tip 1: Don’t respond to RFPs, communicate

Don’t just respond to a written Request For Proposal but establish a real collaboration and communication with the customer.

We’re going to collaborate and communicate anyway, so let’s start now and see if it works before we’ve spend much time in this relationship.

In retrospect: the advice still stands. Some customers prefer not to communicate and keep providers at arm’s length. Do you really want to work with them? If so, plan on a large risk contingency.

Selling Tip 2: It works both ways

Ensure that the contract evenly distributes responsibilities and benefits between customer and provider. Make sure that the customer is committed to doing what you expect of them.

The most important goal of the sales process is to set up a working agreement between customer and provider than leads to success. Always “test” the customer: build in small commitments for the customer and see if they hold their part of the bargain.

In retrospect: the advice still stands. I won’t enter into an agreement that I think is unfair. I won’t start a project unless I have confidence that the customer will do what they’re responsible for. Too many projects go wrong because the customer agrees to do something and then doesn’t take up their responsibilities.

Selling Tip 3: Don’t underbid

Don’t quote a price below cost to win a contract with the intent of making it up later with extra costs.

No unfair contracts.

In retrospect: the advice still stands.

Selling Tip 4: Add enough slack to cover the risks

Do a risk assessment of the project. Add enough slack to the estimate to cover risk, estimation accuracy and (especially) the type of customer you’re working with.

How much slack needs to be added? That requires a lot of experience (see qualifying tip 1) and historical data. For example, what’s the fluctuation in velocity over the last few projects? How does this customer compare to previous customers?

In retrospect: the advice still stands, but I’d clarify that this is a “project buffer“, à la Critical Chain: the extra time does not get added to individual features, but is kept in a “global pot”. If things go better than expected, we add to the pot. If something goes less well than expected we take a bit from the pot. The state of the pot tells us if we’re on track.

Selling Tip 5: Real Business Requirements

Write the specification with the customer so that each feature is well-understood, adds business value and is testable.

We want to write a short, clear and actionable specification without technical detail and just enough functional detail to get started.

In retrospect: I didn’t emphasize this enough. We need to agree on Business Requirements, not System Requirements. What’s the difference? Business Requirements describe what the customer gets out of the project, the value that will be gained and the capabilities that are needed to achieve those goals. System Requirements describe how we will implement the capabilities. The customer doesn’t perform acceptance testing on implementations. The customer accepts when the capabilities deliver the expected value.

Implementation Tip 1: No Change Requests

Never allow Change Requests that increase the scope, cost or duration of a project.

Never. It’s a slippery slope: with each little change the project gets more out of control. I don’t like change.

In retrospect: the advice still stands, you should use “Exchange Requests” instead and only allow changes that are beneficial to the project.

Implementation Tip 2: Spend your slack wisely

Resist the temptation to “slack off” because there’s slack time left.

The project buffer should only be used when things go wrong. Avoid the temptation to “gold plate” features because there’s time left. The team should be energised and motivated to get their work done in time.

In retrospect: how do you implement this? Critical Chain recommends planning with “50% certainty” estimates, estimates that will be too short 50% of the time, to avoid Parkinsons Law. I recommend building a team that’s motivated to deliver quality and business value.

Implementation Tip 3: Simple, honest and correct tracking

Track progress using a simple burndown chart, but only count things that are DONE.

If you have a clear definition of done for every piece of work (and you can have definitions for each column on your kanban board), then you can simply record how much work is done versus how much work you expected to be done. For most projects, the expected amount of work done curve looks close enough to a zone around the diagonal from 100% to 0% done, so that a simple burndown chart, updated regularly, is enough to know where you are. Make sure that the information is visible and understandable to everyone involved.

In retrospect: the advice still stands. The important part is to be able to say that something is done. I’m very strict in this: I prefer seeing the burndown “flatline” because no story is done, than to see fake progress because something is “90% done”.

Implementation Tip 4: Manage your project

The job is not about specifying, estimating and planning perfectly. The job is about delivering what the customer needs.

Attack your risks or they will attack you.

Don’t shield the team. Help them to avoid and solve problems.

Good project managers don’t seem to do a lot and lead pretty uneventful lives.

Success comes from setting up the right project (qualifying) the right way (selling) and then doing all the daily work to keep it on track (implementing). It’s all about actively managing the project with a light touch.

In retrospect: the advice still stands, but to explain how you do this would require (at least) a whole book and lots of experience. Look for the project managers who have a reputation for “calm, quiet” projects that deliver and learn from them.

And the score is…

I still stand by what I wrote then, but I need to explain some of the tips in more detail.

I’ve learnt a lot more about writing contracts and discovering real business requirements.

I’ve also learnt that these tips aren’t enough to run a project, fixed-price or not. Agile (or professional) techniques aren’t an option, they’re necessary. Those are in the second part of the article.

August 17th, 2009 | Category: agile, books
Aug
15

Agile Tour Toronto

Summer in Toronto

CN Tower in TorontoI enjoyed Toronto very much last year, when attending Agile 2008. It has all the attributes of a big, vibrant city but also quiet parks and lakeside where it’s easy to relax.

The most striking thing about the city is its people: they seem very relaxed and easy going, they take the time to enjoy life, they serve Belgian beer and they stop for red traffic lights. Toronto’s inhabitants come from all over the world. The city is one big melting pot where people from all sortsd of backgrounds live and work together. Of course, I’ve only seen the city in summer. I wonder what the city looks like in winter.

Agile in Toronto

This fall, on October 20th, the Toronto Agile community organises their first Agile Tour Toronto. An energetic group of organisers ensures that this will be a day of fun, learning and meeting other people interested in everything Agile. When Gino Marckx is involved you can be sure that it willl look good, be well tought-out and be enjoyable. Gino is also one of the organisers of XP Days Benelux. He’s clearly applying the lessons we learned organising the XP Days. It’s great to see ideas spread. I’m looking forward to the Agile Tour Toronto retrospective results, so that we can learn more.

Go to Toronto

I won’t be able to be there, unfortunately. But you can! Why not send in a proposal for a session? The deadline is September 10th, but if you send in your ideas now you will benefit from feedback to improve your proposal.

If your company wants to connect with the local Agile community, why not sponsor the event? You’ll reach the smartest IT people in the area.

Have fun in Toronto!

August 15th, 2009 | Category: agile, XP Days Benelux
Aug
06

The cost of confusing requirements and solutions

A simple requirement

danger_workaroundsImagine this situation: the CIO of a large company decrees that from now “all applications we develop must be browser based“. This becomes a non-negotiable constraint for every new project.

Unfortunately, a browser platform is not the best platform for all types of applications or all environments. A browser based application may not deliver the best user experience or support intensive workloads. It may be hard (or impossible) to access peripherals. It may be impossible to clearly show complex data sets. And when the network goes down, everybody’s work grinds to a halt.

But all the nice developers and project managers say “Yes boss!” and struggle to find workarounds for these difficulties, to satisfy the users. All of these workarounds make development and maintenance more complex. Users make do with what they receive and add more workarounds to deal with the deficiencies in the applications.

The real requirements

What he really meant was that from now on “all applications we develop must run on a small number of standard environments, be easy to deploy to all our users and centrally managed so that development, release and application support costs stop growing.” What’s the difference between this statement and the previous one? This statement sets a goal and constraints within which creativity can flourish. The first statement stifles creativity and stands in the way of achieving the real goal.

How do we find out what the real goal is? Because someone had the courage to ask “Why?” until it was clear what value we were generating for whom. As the “Discovering Real Business Requirements for Software Project Success” book says:

A requirement describes some value we need to deliver to someone.

Do your “requirements” fit this definition? Why not?

The value of analysis

The difference in value and cost can be staggering. The first statement costs the company lots of money and frustration from everyone who uses, develops and supports hobbled, complex applications. It’s a world of compromises. It doesn’t have to be this way. The second statement gives us a fighting chance to achieve the goals.

All it requires is someone to play the role of analyst to help the customer clearly describe what they need. Someone who acts like a detective to discover the real motives and issues.

A good analyst creates options and keeps them open as long as possible. The “Discovering Real Business Requirements for Software Project Success” book helps to get to the core of the problem. This fits well with a quote from “The Toyota Product Development System: Integrating People, Process and Technology“:

  • Classical product development reduces the number of solutions early.
  • Lean product development reduces the number of problems early and leaves as many solutions available as possible, for example by set-based development or by using tradeoff curves.

Is there someone who has the courage and skill to ask the right questions? Who has the tenacity to dig until they find the real business requirements?

August 6th, 2009 | Category: agile analysis, lean, Real Options, Toyota way
Aug
05

Agile Role playing

Agile Team Roles

Rob Bowley has picked up the Agile Roles and Responsibilities Portia and I described on the Agile Coach site.

I had several goals when we published these:

  • Explain what’s expected of people as they join an Agile team
  • Create a smoother transition from traditional roles into Agile roles
  • To emphasize the importance of every Agile Team member implementing the Agile values
  • To make it clear that the whole team works together to take up all the responsabilities we’ve listed

The role and responsibility descriptions are a starting point for your team to agree on responsibilities. Each team should customize the responsibilities to fit their changing circumstances. I’m sure we can improve the descriptions and explain the responsibilities better.

I am not my role! I’m a free man!

S: So, you’re a java developer.
P: I’m not a java developer.
S: I’m sorry, I thought you said you developed in java.
P: I currently develop in java. That doesn’t mean I AM a java developer. I keep my options open.

I now regret using the word ‘Role’. It is almost universally misused:

  • People will identify with the roleand thereby limit themselves: “I am an X, so I can only do Y”
  • People will identify with the role and thereby limit others: “I am an X, so I’m the only one who can do Y”
  • Roles can lead to Silo Thinking: “It’s not my responsibility, it’s not my problem because it’s not my role”. This gets  especially bad if the roles are equivalent to positions or even departments. Imagine the dysfunctions you could create if you had an Analyst department, a Development department and a Test department each trying to optimise their own little goals.
  • Roles get tied to compensation and evaluation, so that every responsibility you take outside of your role is at best a waste of time and could well be detrimental to your career.

Because many people have had negative experiences with roles, they react negatively to those Agile roles. To me, roles are no more than convenient sets of responsibilities. The important thing is that we as team members take those responsibilities.

I’m just playing

I see roles as an actor sees them. Today, I play an Agile Coach. Tomorrow, I’ll play an Agile Project Manager. Yesterday I played Agile Business Analyst because we urgently needed to work out some User Stories.

Another metaphor is that roles are like programming interfaces. An interface means I can expect certain things of anyone implementing the interface. One object can implement many interfaces. An interface can be implemented through the collaboration of multiple objects.

A common misconception is that everyone on an Agile team must be able to play every role. We all play roles according to the need of the team AND our abilities (and interests). But the more people who can take on a role, the less chance there is of that role becoming a bottleneck. Multi-skilled teams can react quickly to changes in needs.

Which roles do you play? Which responsibilities do you take on? Do you get typecast?

August 5th, 2009 | Category: agile
« Newer Entries