The toughest dilemma I’ve been dealing with over my past five years with a software consultancy house is “how do you make an agile project, or any project for that matter, successful with an inhibiting agreement with fixed key terms?”. Having tried various approaches, combinations of approaches and bending the continuum, I’ve arrived at the conclusion – “you don’t, and there is no way around it.”
Here are some lessons I’ve gathered over that period of time – about the projects that have been a success and had the same common denominator – a time-material agreement.
Trusting and earning trust
- let’s start small, or even very small
- let’s see after a week or two what both parties bring to the table
- let’s look back at that initial period and decide if we can work efficiently together
Playing for the same team and sharing the same goal
- both parties are vested in growing the client’s business
- mutual understanding that long-term success benefits both parties more than any short term wins on either side – this leads to mutual respect
- thinking in ROI categories by all people involved on both sides
- we love suggesting killer features – hey, at the end of the day everyone benefits
Minimum overhead
- no debates on what’s in scope and what’s out
- no debates on what’s a bug and what’s not
- no debates on what’s a bug and what’s a CR
- hey, no CRs!
- no development of features we don’t believe in
- no more waste!
Endorsing agile
- there can be no real agile with an inhibiting agreement underneath. Give your success a chance!
- agile is still the best approach to software development
- agile and time-material fit. No more artificial agile, calling it agile, iterations being just another name for weeks etc.,
Iterations and priorities
- you’ve changed your mind about your business direction – very well, we’ll play right along
- ”no offence, but the feature you’ve started working on is pointless now that the competition already has it” – “none taken, let’s build something they don’t have yet, and let’s start today”
Business driven development
- you show needs, we advise, you decide, we do it
- you need to grow your business in an optimal way, we’re there to help you achieve this goal even if it means taking a suboptimal route from the IT perspective at times
Longevity and sustainability
- long-term motivation based on a common goal achieved together in small steps, not on bonuses, management pressure, fear and contractual penalties
- long-term perspective motivates against taking intentional shortcuts that would remain unnoticed for a long time but are very costly when eventually TSHTF
- this model has a significant impact on team morale which leads to attracting new team members and inhibits departures thereof
100% transparency
- you get billed for the time we’ve spent working on your project. Every minute of it and not a minute more. No rounding up!
- pay for what you get. Time spent on our self-development, training, company meetings is NOT billed!
- if we think there’s a problem ahead – we tell you immediately
- if we don’t think the feature is worth spending time on – we tell you, you might reconsider
Actions instead of words
- PoC instead of multi-page specification and implementation documents
- PoC instead of estimations, negotiations and assumptions
- get an MVP ready and show it to the clients ASAP
- estimate you budget and milestones based on facts (real team velocity) not promises (initial estimates based on documentation)
author: Tomasz Liberski
