Minimum Viable Process - for software teams
“A major part of basic process is following a plan. The nature of agile development means the flow is flexible.”
Estimated Read Time: 8 minutes
MVP is typically used for “Minimum Viable Product”, however, we’re going to discuss how we use MVP instead. Simply put, installing some very basic processes can lead to a world of difference. We typically recommend layering on more process as teams & products mature but the objective here is to go from nothing to something or patching up existing subpar habits.
TL;DR, the overview of the MVProcess is…
- Leverage a project management tool
- Daily Standups
- Relate big picture context to each sprint
- Transparency / Reporting up and down
Leverage a project management tool
I can’t tell you how many teams we see using a Google Doc to keep track of tasks in software projects. Bluntly, this is bad and it’s going to lead to problems.
You can keep it simple to start by using Trello or Asana, both great tools. It’s not our goal here to go into depth comparing them. Most of the companies we work with use JIRA or Pivotal Tracker.
The key is to use one and use it religiously. All tasks should go through it. It forces basic process, enhances communication as you’re commenting back and forth on specific tasks, and helps with transparency. Anyone on the team can easily check the status of a task.
JIRA in action. Each task has an owner and tasks are organized into sprints
Daily Standups
This ensures you, the manager, are never more than 24 hours behind on being “in-the know.” Use this time to ask questions and drill into anything on your mind. You can always meet with a particular developer before or after to drill down on a particular subject. The idea is to get the team on one call, quickly, and go through a basic routine.
We find it helpful if the lead dev or scrum master shares a screen to walk through the project management tool.
Here is an ultra-simple template: go around in a circle and ask each team member…
- What have you done since yesterday?
- What is your goal between now and the next standup meeting?
- Do you have any blockers in the way of your objectives?
The goal is to walk away and have everyone aware of what is happening throughout the team.
Even if you only have 1 developer, have a daily standup. This part of the “Minimum Viable Process” is very important.
Relate big picture context to each sprint
“Why are we doing X in this sprint?” is a common question asked aloud or thought silently by the dev team. It’s highly frustrating to build in a vacuum without the larger picture. Developers have to make many micro decisions along the way, and the more informed they are the better. This is only part of the equation.
A major part of basic process is following a plan. The nature of agile development means the flow is flexible. However, business goals need to be met. We advise keeping a project plan in at least its basic form. You don’t need full on Gantt charts to start, a simple set of milestones is OK. As with the other key goals in this doc, our goal is to work up towards more defined process over time. To start, just getting something basic in place and relating each sprint against overall objectives will be helpful.
Milestone examples
- March 1st: user auth out for internal testing, dashboard X fully functioning with filters
- May 20th: data ETL scripts in place with full testing and first batch of data stored in system + QA having signed off.
Each of these milestones will have many tasks associated with them and potentially several sprints. What even basic milestones do is force the sprints to relate to milestones (typically business objectives). When in sprint planning, it’s easy to get distracted by a cool feature or one that
isn’t related to your goals. These are fine to tackle from time to time, but the key is to always be referencing back to the plan.
Relate big picture context to each sprint
If the software organization becomes isolated from the rest of the company, problems ensue, every time. The easiest way to mitigate this is to put together a quick update and send it out to the wider team. Put this update ‘on paper’ either in a simple PDF or a deck.
Initially, it may take you an hour to define a workable template and build out the update. Each subsequent time should be quick, it could be 5 minutes of work for a smaller team with fewer than 8 people.
Dev Shop Advisors is a boutique software outsourcing advisory firm. We help companies connect with a highly curated list of remote software teams around the world. We’re happy to be of assistance, and there is no cost to companies looking to hire.
Interested in growing your company?