You may be familiar with a little concept called Minimum Viable Product.
It’s the idea that in order to test a product you expose an early version of it to your target users, collect relevant data, and learn from that in order to iterate.
That may sound like common sense, but think back to Windows 98—the classic boxed software you remember installing and having to wait a year or more for the next update. Not experiencing any improvements until the next physical copy of software was in your hands.
Back then it was all or nothing. But life in digital has moved us toward adopting more agile approaches to development.
What if you can take the idea of Minimum Viable Product and apply it to your organization’s business process?
Processes can be bloated, overused, overstay their welcome. So why not instill a philosophy of a Minimum Viable Process—finding the smallest possible solutions to support the issues right in front of you? Adapt through early versions of a practice rather than building one long plan and staying loyal to a fixed process that you know will break?
Who fears the bureaucracy of over-process the most? High-growth organizations. Particularly in the tech space, where an Agile methodology is popular, but perhaps not always implemented in a committed way. An MVP mindset can help.
Sprout is no stranger to growing pains. As Director of Program Management, I was faced with the task of internally restructuring the collaboration between two departments—Marketing and Creative—all in the wake of doubling in size as a company.
A few key aspects brought us to where we are now: creating and aligning squads, emphasizing communication, developing self-healing workflows and refining our process week-over-week.
A more democratized model
In the traditional application of Minimum Viable Product, you’re iterating to produce more. But as a project management technique, you’re iterating to produce less—less heavy-lifting, less confusion, fewer layers.
The process gets smaller, but you’re giving that power back to the team in other places, like fostering more ownership to the people involved on the work being done across your organization.
What you end up with is the smallest, quickest, yet most functional version of your collaborative process. Something that can be tested easily, over and over, until it works.
You can think of MV Process like a Wikipedia page—the answer is there, but the answer will evolve over time.
This philosophy was born from the Lean Startup movement. It’s underscored by the premise that businesses should develop products and processes iteratively and in small steps in order to reduce risks and save organizations from overspending and overbuilding. It was first proposed by Eric Ries who used his experiences in the startup world to develop a lean way to build-up rapidly growing companies.
To kick things off in our own restructuring, we started with squad alignment. Instead of working behind closed doors, perfecting a utopian workflow, we needed to get our newly formed squads together. We established a cadence of quick, in-person, daily stand-ups that provide a forum for the team to raise and resolve issues on a daily basis.
It was okay to admit that things were broken. Looking at the sprints that our Marketing and Creative teams had been collaborating in was like approaching a new project. There were new roles, new teams, new initiatives, and yet the same old process. We had to admit that it no longer made sense—if change is constant, why, logically, would we operate on a fixed process?
As with any new process, people had questions. Instead of focusing on the tactics of fixing a sprint, the bigger issue was granting people understanding so we could move forward. Everyone’s questions needed to be responded to efficiently and thoughtfully.
We created a document to track issues that the teams felt they couldn’t solve. Project managers then raised those issues up to leadership, ensuring there’s management alignment so individual contributors don’t have to duke things out amongst themselves.
Management stepped up. Now that we had a forum to hear issues daily we were also accountable for addressing the difficult issues that were previously buried without a clear owner. This forced a sort of alignment that ultimately built trust with the teams as they began to see the walls of old silos breaking down. The team as a whole was able to see that decisions were being made quickly, which started some of the healing prompted by the restructuring.
What we’re working toward is a team that’s stronger in communication and not afraid of problems. Emphasizing constructive, democratized communication encourages bigger bets down the road. You’re building a unit that will take risks because they have the confidence to solve as they go. Each time getting a better sense of what people react to and delivering value faster.
This is self-healing. As a squad gets “wounded” or dealt with something unexpected, everything is now in place for them to solve their own issues and escalate larger items with the confidence that there will be a quick resolution.
We can never avoid challenges. If your organization’s aim is to avoid challenges you’ll never grow. You’re better off to set a team up to tackle issues head on. And one person should never be devising how all challenges should be responded too. Establish a process that democratizes the team and gives each individual contributor a voice.
Death by intake forms
Not death to intake forms, but death by intake forms.
You probably think of intake forms as streamlined, consolidated and informative requirements for any process to go smoothly. That’s understandable. But if you truly dissect it, every team has their own special process with intake specifics and pushing paper around isn’t a good starting place for any functioning team.
The point of developing a squad model was to encourage healthy cross-team collaboration amongst Marketing and Creative—get all the people involved on a project in a room to work together, eliminating forms and essentially establishing rules of the road as you go.
Instead of one-sided processes, or worse, a person not connected to the impacts at all designing a process—we put the two core team members involved on a project face-to-face and asked, “What would work best to meet both of your needs?”
What we’re finding is that this method of problem solving more easily and efficiently lands on a reasonable process. And there’s a lot more buy-in to follow because you know you’re helping a real person, not just following formalities or arbitrary questions on a form.
In refining our rules of the road week-over-week and documenting every step of the way, we’re literally learning and growing. Meetings we’re realizing we no longer need are being cancelled and this is all thanks to the level of in-person communication we’re enacting.
Always serving people
Now that I’ve gone on for this long, I’ll let you in on a secret: None of this is truly about process at all. It’s about people.
It’s too easy to try and make a process that solves every possible problem. Defining and documenting a plan that solves for every edge case is too complex, too dry and will quickly become outdated as your company continues to grow.
You can come up with the absolute perfect systematic solve, but if it lacks the nuances that make it a people process, no one will follow it.
Organizations need to understand that waxing philosophically about agile approaches without practicing it is just fluff. Process is a reflection of your company culture. How you operate is what the people inside your office walls will walk away with everyday. Make it a point to foster and leverage constant feedback, re-read any processes you land on and put yourself in the mind of brand new team members: Can they navigate what you’ve created without your help?
At the end of the day, it’s not about focusing on how much you’ve solved, it’s about how approachable and supportive the process you’ve built is to the people working through it.
And that’s the opposite of bureaucracy.