Agile, UX, Fixed Bid Projects and things in b/w
Often one sees this. Organizations giving in to the buzz about Agile and how good a model it is — leading to imposing it on all projects, ongoing and new. The project teams, which were till now, working like a well oiled machine (ok, with there share of jerks), somehow pulling their socks up at the right times, and delivering the projects as needed on time — look confused and murmur a question — “What was wrong with what we did?” “Why this Agile thing now” “What?? There is a two hour release planning meet? Seriously, two hours?” And you know, many exclamations like that!
Given the state of affairs, and keeping the discussion focused on contracts that are fixed bid type (where client decides how much money they want to spend, and in how much time) — few things are important to understand wrt Agile style of delivery.
One important thing to state, which experts often talk about:
One cannot just say- “Ok, its a great sunny day today — We have got a Scrum master so lets go Agile! Boooom!” Sorry, but its pretty possible that it could boom your deliveries, Sir.
Jeff Paton mentions about Josh Evnin saying -
“I finally figured something out. Agile development is a culture, not a process.”
There is a lot of weight and meaning in what Josh said. Lets try to understand. The success of Agile practices is most importantly about the adoption of its core values. The first thing any company or team should do before trying Agile is to set aside traditional models and focus on core Agile values, such as communication, collaboration, feedback, incremental delivery etc. These values should be internally promoted and practised so that the Agile process seeps is with ease, and is not something that is imposed.
This means, for example — In an ongoing project, teams agree, that they will practice much better communication here after. Could be in a form of daily update meetings, slack updates in a project channel or just anything that helps. Similarly, incremental delivery can be practiced by doing better scoping. So on, but the idea is to adopt the culture before the process. In fact, the process is then, a sort of manifestation of the culture.
Having understood this context — lets talk about how it can be adopted for Fixed Bid Contracts. We are talking about these type of projects, as they are much in common, and in general clients always want their work done in minimum cost and time. How do we do that in an Agile like culture, which is primarily about identifying the scope, and defining the delivery based on that? The delivery is incremental in nature, but that means it defines the budget and resources and not the other way round.
Scott Ambler, a while back, advocated around what he called the Iron Triangle of software development.
In essence, he mentioned that this triangle should be respected — and for a successful project delivery, at least one of the corners (out of scope, cost, and time) should be variable. He adds that it might not be always possible to vary just one factor — so to ensure quality, flexibility in other factors should be factored in.
All seems good. But in today’s context, you will often work with clients who advocate and work by the equation, time=money. Which essentially means a Fixed Bid Contract, where clients control both money and time (to a large extent, if not completely). Max Pool, for this situation, wonderfully derives, what he calls an Iron Line -
Now, given this scenario —
In most cases clients want control of Time and Budget — which is the case we are also talking about. This means, Scope is the handle with the organization delivering the project. Knock-knock — Come in UX.
I would single out “Requirement Gathering” leading to “Scope Definition” as the most important activity of UX experts. Factor them in from the onset of the project, and allow them to be on the forefront of Requirement Gathering phase, as that helps in setting up the Scope of future releases — which you can later refine as the Release Plan. Armed with the information around constraints of Time & Budget, the UX team (supported by Stakeholders), help define, what can be colloquially called — The First Cut.
The important thing to note here is that, in true Agile fashion, this First Cut is defined keeping in mind the larger product goal. This is the iterative way of thinking that Agile speaks about. Very important to note that this First Cut is not necessarily the MVP (Minimum Viable Product). More about it here.
We saw how the organization culture is supremely important to enable easy adoption of the Agile process — and how UX teams enable that methodology for Fixed Bid Type projects.
Leaving you with a superb quote from Jeff Paton in his Agile 2012 talk -
