There is a familiar expression among technology practitioners that goes, “the right Agile is the one that works for us.”
It’s as equally accurate as it is consolatory.
At the core, being Agile is about wholly embracing four beliefs for making software better.
Believing is not what makes Agile hard.
What makes Agile hard is what comes after we start believing. How we practically go about redefining our business processes to stay true to these values.
Much has been written on the psychology of why new habits are hard to sustain and the common mistakes that lead to failure. Among these factors are external threats like friends and family who don’t share the mission.
For software development service providers, it’s hard to be Agile when our clients are not.
The Fixed Cost Conundrum
“It’s a lack of clarity that creates chaos and frustration.” - Steve Maraboli
In the world of work made for hire, clients bring us their product ideas and we estimate the cost and time to deliver. If the terms are agreeable, a contract is executed and the work begins.
Everybody’s happy, right?
In the beginning, usually yes. That’s because fixing scope and cost early on is often an exercise in long-term dissatisfaction.
To illustrate, let’s take a look at the process by which products are brought to life.
Liability is greatest when we skip steps, pushing assumptions from one side to the other.
In a service model, most new work comes in from the left in the form of client ideas.
I’ve had ideas presented to me in conversation as loosely as “it’s a mobile app that does x, y, and z” and as “formally” as approved mockups prepared by an inappropriate designer (a red herring of non-iterative process).
In all cases the desire is for our team to then wrap a fixed cost and timeline (more waterfall) around product requirements that are, at best, 50-70% unclear.
What options do we have then?
- Pad the estimate to protect against risk
- Push for a contract billed by the hour
- Bill for upfront time to better define the work
- Invest unpaid time to better define the work
- Push it back to the client to define better
- Reject the deal
The first three options push all the liability to client-side. Not typically well received.
Option four pushes the liability onto us. Not ideal and not supportable.
Option five begins a vicious circle and with option six, nobody wins, not even the next team that gets the deal because presumably they inherit the original problem.
This is precisely the friction of “customer collaboration over contract negotiation” in a vendor-partner construct.
Solutions, Not Problems
“Oh trouble please be kind, I don’t want no fight and I haven’t got a lot of time.” - Cat Stevens
The process between Agile vendor teams and Waterfall client teams threatens the spirit of adaptive product development.
All too often, the conflict results in Agile or Agile-aspiring product teams reverting back to less effective methods rather than pushing toward incremental improvement. The path of least resistance.
But the “client” is not “always right.”
At the same time, rigidly defending our internal process can also come with a price.
So how do you inspire Agile practice with outliers?
You Own What You Create
“Tell me and I forget. Teach me and I remember. Involve me and I learn.” - Benjamin Franklin
A former colleague once said to me, in the context of shareholder agreements, the whole process would be a lot simpler if investors just wrote a note saying “I give you this money because I know you’ll do the best you possibly can to achieve what you set out to achieve, and if it doesn’t work out I understand it’s because sometimes shit happens.”
Utopian maybe, but it points to a powerful notion: trust is the most sacred contract.
Collaboration succeeds when trust is active.
Our friends at Pivotal Labs have a unique process for client collaboration - a practice called “pairing” that started with developers but has since evolved to include designers and product managers.
At The Development Factory, we’re also advocates for the “we do” principle of andragogy.
One practice I’ve found to be tremendously helpful in building trust and mitigating contract risk is to conduct story time rituals with clients.
In Scrum, story time is an informal process better known as “product backlog refinement” (some teams also incorporate story time into the “inception meeting”).
The purpose is to connect the team to the bigger vision, ensure stories are clearly defined and initially estimate level of effort.
User stories are a format for defining product features, spoken from the point of view of the end user and focused on goals, not implementation details (which are later defined with the help of the whole team in the exit criteria or “conditions of satisfaction”).
User stories define features from the POV of an end user or customer. The goal of the user is explicit in the story, leaving the rules for implementation to be defined by the team.
What’s so empowering about user stories for clients is that it’s an accessible process.
The format is intentionally liberated from developer terminology and it anchors all feature discussions to customer or business objectives:
*Why do we need this? *
Do we need this?
Once all parties are aligned about purpose, it becomes much easier to map features back to constraints (time, budget) and (re)prioritize together.
Usually everything that was once non-negotiable becomes a flex point. We can now agree to defer a feature to a later phase or we can agree to implement a feature in a simpler way that still meets the objective.
With this Agile approach, we can begin to see how collaboration actually facilitates contract negotiation, while also establishing trust and teamwork that will continue to reap rewards throughout the project lifecycle. Big returns for an upfront investment of just one full or half day.
Now we’re ready to leverage the benefit of tools like Pivotal Tracker for story and progress tracking and even invite our clients to join into our Pivotal projects!
Let's talk about your unmissable opportunity. Book free consultation session with one of our partners.