I’m a huge proponent of agile management being applied to growing technology companies. But there are many ways to execute against those principles. And some agile SaaS management devolves into plain chaos. In fact, in those cases, calling it agile management is a misnomer — and the lack of leadership becomes glaringly apparent.

Over the last couple of months, we’ve seen more than a few companies growing at breakneck rates despite huge gaps. Or are they growing at breakneck rates because of those huge gaps? That’s the argument that seems to devolve a well-meaning agile approach into madness. Unfortunately, that madness often translates into damaging business outcomes including weakened metrics, elevated churn, and high employee turnover. SaaS valuations are driven by more than topline growth.

Agile with Guardrails

Let’s just get this out of the way first — a lot of agile, isn’t really agile. In fact, a lot of fast-moving companies seem to wrap themselves in the agile envelope when really they just have no processes, no planning, and weak leadership. That’s not agile, that’s chaos.

I’m a process guy but like to think of that layer as just enough. More than just enough gets in the way and less than just enough can’t be iterated and improved. Since we’re building cultures of continuous improvement, we need just enough process to make that methodical and predictable. For me, my version of agile was just enough and not too much for my spread-too-thin, worked-too-hard teams to apply every day. Because the flip side of the no-process coin is the over-processed version that sucks productivity, morale, and ultimately capital.

Lite Agile Management

I’ve successfully applied versions of this to many a team in a SaaS organization. It’s thin, flexible, painfully simple, and it works. It doesn’t impede creativity. It doesn’t slow things down. It’s not over engineered. And it keeps the administrative/meeting time to a minimum. That doesn’t mean you can’t or shouldn’t build it up to be more formalized if conditions warrant — especially in engineering. But here are my lite agile SaaS management guardrails.

Agile SaaS Management Sprints

Our lite agile SaaS management sprints consisted of three-week blocks of work to be done. We settled on three-week sprints after experimenting with 2-, 3- and 4-week lengths. In most cases, our teams preferred the three-week length. It was long enough that real work could be accomplished and short enough that scope could be controlled. You could experiment with 2-4 weeks and go with what works best. You can also change at any time, so no need to sweat it.

Sprint length is personal and based on the characteristics of the team and the work-to-be-done.

Agile SaaS Management Sprint Plannings/Retrospectives

This is where we got very loose with our agile methodology. On the last day of each sprint the team would meet for 90 minutes. In that 90 minutes, we would both cover the highs and lows of the current sprint (call that a retrospective if you must) — including unfinished work — and plan the coming sprint. We used Trello as our tool of choice and live-planned on the fly — dragging unfinished cards from the current list (not many); and recurring and backlog cards into new sprint. If it wasn’t included in sprint planning, it did not happen in the sprint. Only emergencies were worthy of interrupting the sprint mid-stream.

This 90 minutes every three weeks is the team leader’s chance to align the work-to-be-done in t...