Fixed Price & Agility

Customers’ Agile maturity level is often low. Also, special attention should be paid to the start-up phase:

• To set the rules of the game that will prevail throughout the project
• Share a common vision of the project’s scope

The vision of the project

• The client doesn’t have specifications, but they need to have a vision of their project
• The client’s vision is the only fixed point of reference for the project. The rest will change all the time. This information is therefore essential!
• The vision should specify (must fit on 1 page on one side)
  • A summarized list of the app’s key features
  • A vision of the ROI of the application
  • Goals and motivations to achieve them
  • Risks

Template:

+Expectations: Ergo, performance, quality, project management, techniques, etc.

+Objectives: Issue of deadlines, issues of scope, etc.

+Risks: Risks as seen by the client

+Out of scope: What the customer or service provider decides to exclude from the scope

” Deriving scope from goals :

In the future, this will be one of the most important software development topics, and I want to raise awareness about it. “

Specification by Example – How Successful Teams Deliver the Right Software – G. Adzic (Manning, 2011)

Decide as late as possible

There are 2 strategies in problem solving:

• Width: funnel approach
• In depth: tunnel approach

Often, people prefer the in-depth approach because it allows you to quickly reduce complexity

Disadvantages of the In-Depth Approach:

• It forces structuring decisions to be made at an early stage

Width Approach:

The feature is fully implemented in a single iteration

In-depth approach:

The feature is implemented over several iterations

Advantages of the width approach:

• Allows you to have all the major features (in simplified version) very quickly => acceptance + interesting
• Allows you to de-risk projects that are heavily driven by deadlines
• Adapts better to changes of mind. Helps avoid code rework

Disadvantages of the width approach:

• Unnatural approach
• Never Make a Choice => Block Developers

Redo the Backlog

The Backog is the most important + driving instrument!

In response to a tender, the one submitted to the client is often

• Riddled with errors
• Not read by the customer

That’s why itis necessary to do it again with the client at the beginning of the project:

• List the requirements
• Estimate requirements => yes with the customer!
• Prioritizing requirements

Advantages of redoing the backlog and costing with the client:

• Be sure to have a shared initial vision of the software
• Putting the customer at ease during requirements bartering
• Have a prioritization that takes into account the true business value
• Have a Backlogthat uses business vocabulary

Mistakes often made:

Conduct the workshops

For the customer to benefit from an Agile approach, you must agree to give them time to “mature” their needs

Ban the practices of:

• Do as many workshops as possible at the beginning of the project to scope the requirements
• Force decision-making to secure your quotes

Best practices for conducting workshops are:

• Do the workshops as the sprints go
• Frequently deliver functional software and have it tested by the customer
• Explain that some of the costing are budget envelopes that must be respected
• don’t let people believe that each domain owner has a right to make a decision => the only one who decides is the Product Owner (including the technical aspects)
• Look for the minimum decision that everyone agrees on and develop it (breadth approach)

Start Developments

Project managers tend to start developments too late. They want to have as many inputs as possible before starting: storyboard, graphic track, functional framing, etc.

Cons:

• Heavy financial investments without any software production => !! risk
• Symptomatic of an in-depth approach: we want to simplify everything from the beginning of the project

Advantages of starting developments relatively early:

• The act of producing code naturally helps to align the client’s expectations.
• Until any lines of code have been produced, the client feels free to question everything from one workshop to another.
• Project de-risking => an operational software is the main measure of progress (7th principle of the Agile Manifesto)

Take care of your customer relationship

Take care of the quality of your customer relationship!!

Take the same project and the same team

• Case 1: The customer is in a good mood towards you
• Case 2: Customer is in a bad mood towards you
• The difference between the 2 is at least a 10% margin

How do you develop a quality relationship?

• Be predictable
• Tell the truth
• Say the same when it’s hard
• Say it early
• Choose your lies, or you’ll hang yourself with them
• A relationship of trust is created drop by drop, but is lost by the liters

Be Engaged

• Talk about your possible solutions
• Show your commitment to finding a solution quickly

Develop solidarity

• Never argue with a customer!
• Conduct customer/supplier team retrospectives
• Find solutions to your customer’s problems, even without immediate counterparties
• Involve your customer in finding solutions to your problems
• Get out of controversial topics with a 50/50 solution
• Be able to negotiate => define your flexibility levers!

Be Competent: Deliver Quality Software

• If your team delivers quality software, a budget, a deadline can become negotiable
• If you deliver sh*t, nothing will be negotiable!

Your goal: the success of the project

• On a project that is going wrong:
  • The margin is no longer controllable or predictable
  • On a project that is going badly, it is very difficult to negotiate an amendment / extension
• To make money, your project has to go well, it has to succeed
• Your first concern should be: the success of the project

Define your leeway

• Success, yes, but not at any cost
• Define tolerance thresholds with your agency, based on:
  • The history of doing business with this client
  • The Customer’s Potential
  • The strategic nature of the project for your company
  • Etc…
• Translate these thresholds into margin flexibility
• Manage your project within this leeway
• When you approach the limit of this margin, refer to your agency

Monitor the balance of interests

• Keep respect for mutual interests in mind at all times
• When you start to see an imbalance in the relationship, say so, and take action!
  • E.g. you are below your financial goals even though the health of the project is good
  • E.g. you are above your objectives, while the client has cut 30% of the scope

Limit your requests for money

• Before asking for money, find other solutions:
  • Together with the client, remove unnecessary requirements from the backlog on a regular basis
  • Be technically smart: offer equivalent, but cheaper solutions
  • Swap a “banana peel” requirement for a cheap wow effect
  • Transfer tasks to the customer
• As a last resort:
  • Negotiate an endorsement / extension cord
  • Let the customer know early, so they have time to find solutions
  • You won’t be able to do it 50 times. So choose wisely when and what to ask for

No time lag

• Do everything you can to reach your date goals
• A postponement of the date hurts the margin very badly
  • Better to staff 1 developper now, than to extend 2 weeks 1 full team
• Secure your production with the width approach

A contract template

• Agile contracting is a difficult subject in which lawyers are poorly trained
• There is no typical Agile contract that everyone agrees on:
  • Difficulty in defining changes in scope
  • Difficulty in collaborating in a way that is highly engaged
• Most of the time it ends up with:
  • A more or less traditional fixed-price contract => risk borne by the supplier
  • A contract under management => risk borne by the client

Pain points

• I tried for a long time to write an Agile contract:
  • Perimeter management with the barter of Effort Points at that’s fine…
  • Flexibility lever, collaboration at this is where it goes wrong
• People are able to hear that there needs to be a lever for flexibility, but not always to write it:
  • The flat-rate contract model is still very much entrenched!
  • If my project goes off the rails and people find out that I’ve signed a contract like that, ouch!
  • Our legal department is never going to accept such a thing!
• Collaboration:
  • How do you define collaboration? How do you define non-collaboration?
  • It is impossible to invoke a breach of obligations by one of the Parties on a concept so difficult to define

So what is (are) the solution(s) ???

2 types of contracts

There is no one-size-fits-all solution, but a contract tailored to each project

I’ll tell you:

• a contract signed with a customer
• an alternative to this contract (not signed)

Agility: Heads / Tails Side

• You have understood that in an Agile project, there are things
  • What customers like: change their minds, no tunnel effect, …
  • What clients don’t like as much: the flexibility lever, the sharing of responsibility, the freedom of the parties, etc.

My advice

• Without a project, there is no Agility => in Presales Phase , your priority is to make your customer dream!!
• And what about the subjects that make people angry? :
  • The first time , bring up the subject in a physical meeting
  • See how the customer responds to these comments
  • If the customer is receptive, or knows agility, this type of speech becomes an ASSET!
  • If the customer isn’t receptive, don’t talk about it anymore. Re-open the topic once the project is won