PM Software and Minimum Viable Process

I'm in the early days co-founding a new company and I've been very focused on early process, culture, and how things get built. While exciting at first over the years, I am now allergic to processes such as Agile and software that serves them. I love the concept of agile (case intentional) but Agile at scale almost always ends up as Waterfall. I'm sure it's been done well with certain teams and at certain companies. In fact, I've heard from people I know and respect that it has. My personal experience and a multitude of stories I've read make me believe that this is the edge case, however.

The multitude of software and roles that have developed over time to reinforce processes like Agile are mind-numbing, and have evolved to the point where software you use to manage your product development process begins to shape your product development process. The medium becomes the message.

I will illustrate a few good examples of how this manifests within teams.

The Inevitable Backlog

When your only tool is a story writing app, every product looks like a backlog. Many product team members and their stakeholders love to see a full backlog broken out across sprints. A full backlog means there is “stuff to work on” and “specs to be be built”. It means that there is not a free man hour to be wasted and everything is planned.

The reality is, however, that most backlogs are filled with old stories that no longer valid as written, or half-written, are unwieldy to manage and are negative to getting actual work done. The time spent to keep it "groomed" it is not immaterial with lots of people in meetings during the week when they could be building, talking to customers, or communicating within the organization.

On top of that it enforces at the very least a mini Waterfall within an org. The design team needs to get ahead, then backend needs to get ahead, and any poor estimation rattles throughout the team. Soon you are operating and planning more minute details months ahead of time. There is nothing wrong with this if this matches your culture, but it's not really what Agile is supposed to be.

My biggest beef is it seems to foster a sense of complacency with teams through a lack of focus. An engineer looking down a huge backlog says “Lol, that’s never going to happen.” The imprecision involved with longer term planning undermines the whole process, as it should. It's existence almost becomes inevitability as well. Teams spend so much time grooming it and looking down at it that it almost has to be built, and other ways not explored or discussed.

The Missing Acceptance Criteria

Acceptance criteria are a big piece of user stories for many teams. They are the requirements that must be filled in order for a story to be complete. The latest software has all sorts of checklists and subtasks and other bells and whistles to make them easier and shinier to write. In theory they should help teams build software that is less buggy, but in reality I've found it to be the opposite. It's where bugs are born.

A good chunk of acceptance criteria is either blatantly obvious or very difficult to identify at the time it's written. When a product is being built, however, it all becomes fairly obvious.  A good PM should be able to identify and write up good acceptance criteria, just like a good engineer should be able to write good code without bugs. And this is generally the case.

The problem is that nobody is perfect. Checklists are rarely exhaustive but, like backlogs, they carry a particular weight and importance in them, to the point where they become a crutch to teams  talking about how something is supposed to work. Software that enables you to publish a checklist of acceptance criteria can therefore be dangerous and where bugs are born.

The Split Stories

This is when you have multiple engineers on the same team who work on different parts of the stack and begin splitting up the stories into different components or tasks (e.g. "Sort list by relevancy (front end)" "Sort list by relevancy (backend)" "Sort list by relevance (design)"). This is usually the result of team members turning the Board into a to-do list game ("I closed out my stories"). It's also a clear sign that things aren't necessarily going as Agile as you had planned.

The Way Forward - Minimum Viable Process

When I co-founded this current company, I had a vision of building a ticket-less company - a company that never needed a bunch of user stories and JIRA boards (except for bug tracking).

We currently have some longer term goals that are clearly defined and discussed along with a very clear understanding of globally what we're trying to build and why. We operate on weekly "sprints" where we discuss what we want to accomplish and deliver as a team over the next week, then go do it. Then at the end of the week we demo it and talk about what worked or didn't work.

One month in, it's working really well. We're building at a faster pace than we first intended. There are a few areas where we've been too minimum and I've already developed some lightweight documents and communications to fill in. We've iterated on the meeting schedule once as well. There have been moments where I've been deliberately vague and continue to be in order to foster a culture of ownership, autonomy, and creativity. This has been difficult for me, if you know me.

Any Minimum Viable Process needs to have good communication. Teams and organization need to have good, focused, constructive communication. Leadership needs to communicate clearly the what and why and it can't be a million different things. Everyone you talk to in an org should know what success looks like in the next 30/60/90 and longer term, and should tell you the same thing. Within teams it needs to be understood what needs to built to get there. Whatever iterative cycles you work under should have clear shared understand of what needs to be delivered at the outset and throughout. Effective communication solves 90% of the need of process.

Teams also need to have autonomy to solve problems. As a manager your job is to identify the right problems to solve and customer outcomes to realize. Your team is there to design and build solutions. The more you can get into that mindset the better. For me, I've been being very deliberate about removing myself from the "solutions" process. I don't want to be in the weeds on the solution side. Not that I don't think I have good input and insight, but its just not a good process.

I don't profess to have a clear 5 step solution for the proper way forward and to be honest it's whatever works for your team and your org. I do think teams should think a great deal about how the software systems they use to build products affect how and what they ship and adapt a Minimum Viable Process - the least amount of process your team needs to build great software quickly and efficiently.

I saw this tweet yesterday that referenced a tweet storm that sums up much of this post.

Ironically it references a tweet storm from the co-founder of Linear, an anti-story PM tool. I've heard good things and perhaps will check it out, but I'm not in any rush to mess with what is working.