Agile is Fragile

Interrogating Agile values to better serve MVP delivery through trust between a client and an agency

Agile — a fragile approach to MVP

“The word ‘agile’ has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”

— Dave Thomas, 2014. Dave was one of the original signatories to the Agile Manifesto.

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

Agile methodology has been widely adopted by agencies in Melbourne, including Portable. It’s seen as a process by which a product is iteratively produced and improved, where costs, effort and prioritisation is made transparent and efficient for both the client and the team executing the work.

Alongside, we’ve seen the adoption of the “Minimum Viable Product” — or MVP — concept from Lean methodology. It’s a concept that requires a team to put forward the smallest effort possible to get a product or service to market, in order to learn from what users value, what they actually use and need in order to continually improve the product once it’s off guided rails.

These are both fundamental tenets that I believe in, champion and adhere to — at least for the pitch phase of a project. Both agile and MVP sensibilities align with our core principal of designing and making for users, otherwise known as user centred design and design- thinking. In agile, the team is multidisciplinary with stakeholders in the team tasked with creating and prioritising functions to be built that users need the most to solve the relevant problem. In MVP, the team is tasked with basically the same thing — defining the smallest set of functions that users need in order to solve a problem by using the product or service. So why do agile and MVP seem to rub uncomfortably against each other when in development?

Agile promises a process, not a product. And MVP is a product.

Essentially, once the scope of MVP has been decided, there is little room to use a pure agile process. The set of functions are known, and form a set of requirements that no matter how agile you make things, still need to be produced in order to get to launch. All agile’s core principles are put to the test, but in the relationship and power dynamic of client and agency, agile almost always loses out.

A deeper dive into “Agile”

So what’s agile, really? Principles of agile are taken from a manifesto developed by a group of leaders in Extreme Programming in February 2001 in a ski resort in Utah.

No doubt you’ll notice something they have in common.

I don’t know if there’s more to be said that the founding fathers were indeed, all fathers and no women were part of that group. Yet, there are more and more female digital producers who are the managers tasked with seeing out the principles in action, and therefore, for changing them to suit the realities of the projects that they are delivering. What are the consequences of applying a gendered, or feminist perspective to project management of agile delivery? (Whoa, dig further into this)

The four values of the Agile Manifesto:

1. Individuals and Interactions Over Processes and Tools
2. Working Software Over Comprehensive Documentation
3. Customer Collaboration Over Contract Negotiation
4. Responding to Change Over Following a Plan

It’s hard to challenge any one of these four values. I love them. What’s challenging is trying to get a client to sign off on these values in order for an agency to get paid to deliver an MVP product. When we work with a client who needs the promise of a product, we need to rethink the agile values and sometimes even turn them on their head.

Individuals and Interactions Over Processes and Tools

A team is made up of individuals, and they interact with each other in a collaborative effort to get the job done in the best way. Values, insights, partnerships, great products… these are the outcomes of individuals interacting, and this is probably the most rewarding part of working in a very talented team of designers, developers, and other stakeholders who all shape a product.

But getting there doesn’t just magically start the day after the ink is dry on a contract or scope of work. Clients will often want a team to adhere to processes and tools that they have confidence in. This might mean processes and tools that they are familiar with. Which isn’t a bad thing for either the agency to try and learn to assess whether to adopt, or for the client to try and up-skill in the processes and tools used by the Agency to deliver a project. What’s key here is that there’s a learning process whereby a client and an agency have to learn about each other’s processes and tools, and then… then can come the trust needed to prioritise individuals and interactions. Because without trust developed through a shared participation in process and understanding of tools, individuals and interactions can see like cowboys and cowgirls chatting a lot over Slack, without anyone really knowing if they’re on the right track.

Discussing the processes and tools must come first to pave the way to the real value in individuals and interactions.

Working Software Over Comprehensive Documentation

Everyone loves something that just works. The trouble is defining what “working” means. And unfortunately, this is most often done by documenting it, often in the form of User Acceptance Criteria, or having a system architecture diagram, a training manual, or quality assurance test that tells if software is working in IE11 — if that’s something a user needs and they can’t get Chrome because they’re working in Government or some such thing. What’s MVP of documentation? Just enough written down to refer to so the team (client and agency) can know that a product is working the way it’s meant to.

The other side of documentation is that a client may not necessarily want to tie its future to just one agency. The client needs enough documentation so that their product is able to be transitioned to another agency or in house team if anything should go wrong in the project delivery.

It’s again an issue of trust, but it’s also just risk management. What’s the MVP? Just enough documentation to make sure you’re able to understand a product and it’s inner workings enough to brief it into another team midstream. So how do we handle it? We apply principles of transparency to our work, our approaches, our assumptions, and environments in which we are working the functions are documented (in JIRA or similar issue tracking software alongside formal statements of work). As far as possible, we use tools (such as Github and Sketch) that combine the documentation and the work by letting the work be its own documentation that’s readable by other agencies doing the same type of work.

Documentation must be comprehensive enough for all stakeholders to agree and know that software works.

Customer Collaboration Over Contract Negotiation

I haven’t yet found a contract using agile methodology to sign that doesn’t require many hours of negotiation. It’s counter-intuitive, because we could either just sign a contract saying as an agency, we will work with a client to put all our talent and focus in a set number of hours (a sprint) towards a goal that we articulate together. Maybe the client who will sign this is out there, somewhere. In fact please just wave at us if that’s you, you magic Unicorn, and let’s do this!

Customer collaboration really assumes a couple of things. One, that a client has resources and expertise and a representative who can truly be embedded in the agency’s delivery team, in order to collaborate at all times. It also assumes the client can be collaborative, instead of being top-down requirements driven or simply relaying the enthusiastic winds of management. In order to even be this collaborative, we need to trust each other. And often, clients will be spending money with the trust that it will achieve what is within the contract that governs the rules of engagement, and expectations and accountability for both sides. It’s really hard to draw up a nebulous contract that a client or an agency feel comfortable signing. Often the negotiations in a contract are really helpful in each party learning about the core values of the other, what they will argue about to the tee, and what they will be willing to agree in principle about and have worded such.

Once a contract has been negotiated, collaboration becomes a protected space by which the boundaries and responsibilities are known. Collaboration can then flourish because of the trust established through the boundary-testing exercise that is a good contract negotiation.

Negotiate over the contract so collaboration becomes a contracted deliverable.

Responding to Change Over Following a Plan

This is the core value I don’t want to touch in any way. At the outset, have a plan, and have an idea about what can be re-negotiated and respond to change, as well as the hard-requirements that the team (including the client) will not be able to deviate from.

Over time, more unknowns become known. Over time, hopefully trust also grows between a client and an agency, so when the need for change become apparent the team will feel comfortable in acknowledging the need and proposing a different course of action. To me, this is the core of being agile. If in all three prior values, this one is referred to and put forth as the only value that matters, an agile methodology can be adapted to benefit the product or project. And with trust, we can change.

Have a plan on how to respond to change.

Toward trust and transparency, and the agency to change.

If we look at some of thinking behind the Agile Manifesto, or the problems that the group was trying to come to grips with, they feel very real, yet… not quite in step with the reality of a traditional client-agency relationship.

“People would come up with detailed lists of what tasks should be done, in what order, who should do them, and what the deliverables should be… The variation between one software and another project is so large that you can’t really plot things out in advance like that.” — Martin Fowler

Does this sound familiar? Eerily so. Many hours are spent doing exactly when scoping, estimating and planning an MVP project delivery within an agile method. Clients need to know what they’re getting, and the team needs to know in what order things should be approached and the dependencies between them.

Hidden cost 1: agencies will try to plan for uncertainty

It’s no secret that every fixed cost quote or effort estimation will contain a hidden “fat” item line producers will build in. It’s to account for the contingency that we can’t always account for the variations we’ll face in trying to build an MVP. I’d like agencies like Portable to be more upfront about these risks and for this to be shared between clients and agencies.

Sometimes, these uncertainties and problem-solving for them happens at a rate faster than a team can formally communicate, estimate and mitigate within the scope of the sprint. Often also, these un-planned activities happen faster than the team members can log time to the issue, and the planned time is exhausted before the producer finds out that a planned block of work has exhausted its time allocation by double and they have to bear the bad news or hide it somehow.

What would it look like if agencies weren’t always trying to cover ourselves for the risk of tackling the unknown?

Hidden cost 2: agencies and client don’t plan on being violently transparent

Sometimes “violent transparency” (coined by Michael Church, noted Agile critic) isn’t the best basis for trust, and there are healthy limits to transparency for the team to feel like they can do their best work. For example, the agency team will often need time to think, experiment and tackle different solutions to a problem, without being under the microscope or feeling obligated to keep the client up to speed on the micro-processes in order to arrive at an informed set of recommendations to discuss with the client and the rest of the team. The same courtesy needs to be extended to the client by an agency. For example, requirements or MVP scope will need to change based on new information the client receives about their internal organisation strategy or market research with users. The client may not be in a position to discuss all the details of this imperative to change, nor should they expect to be held captive while work stops until the agency team understands the whole story. I’d like agencies and clients to trust that each team member is applying their expertise in their own areas of responsibility in order to take a considered opinion to the project without needing to provide full transparency on every decision to the team. However, if that’s what’s needed to build trust in the first place, it becomes a bit of a chicken and egg scenario with no happy players.

What would it look like if providing full transparency was allowed for as a cost to the project, both in terms of time and effort as well as potential delays to delivery?

Hidden cost 3: being agile and changing tack costs time

In the best cases, client and agency are one team, finding out about the project’s progress together and forging through with alternative paths when blocked or facing challenges through collaborative decision making. This nitty gritty of communication is often not (able to be) allocated a line item in a quote or a story point in agile estimation, but it should be. It’s healthy and necessary, and — if agile is not to be fragile — this communication and team problem-solving activity is paid time that we need to count on.

Often it’s seen as a cost to things “not going right”, or “not going to plan” that the agency bears the burden of, and sometimes carries guilt about. For the client, it also take time to come to terms or bring up the need to change, and sometimes to get support from the wider stakeholder group in order to implement. I’d like the cost of changing to be taken into account so that it’s billable (both for the agency as well as for the client’s internal resources), or finds another path for accounting for the time spent, even if it means cutting the scope of MVP.

What would it look like for a project to allow for ambiguity and embrace it as much as certainty?

I don’t have the answer to all these things, save that I try to be brave and ask the questions and build the trust along the way with our clients, so we can answer them together.

When in doubt, consult this handy checklist for healthy Agile conditions.

Thanks HBR! https://hbr.org/2016/05/embracing-agile