Keeping Agile SaaS Management Productive

By Katie Burns

Mar 12 2019

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.


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 the next three weeks to the higher level business strategy and desired outcomes for the quarter or year. It’s absolutely critical that this leader’s head is in the game and that he or she takes this opportunity — every three weeks — to reinforce the higher-level goals and objectives to the team. Also, if you have a nine-person team, you’re investing 13.5 person-hours in sprint planning, so it needs to count.

Leadership in sprint planning is where and how the agile train stays on the strategic tracks. 

Agile SaaS Management Backlog

The backlog contained ideas and initiatives to be considered as work-to-be-done in a future sprint. Everyone from the team (and outside the team) contributed backlog cards in Trello and stack-ranked them accordingly. We would then debate their merits in sprint planning and include innovative work as a percentage of all work. That varied with the load of required work, but we generally made room for at least something in every sprint. It’s important for the leader to praise and include innovative ideas in sprints.

Appreciating, considering and including innovative backlog ideas keeps everyone ideating, engaged, and enthused.

Agile SaaS Management Standups

Each day the entire team met — literally standing up — for 15 minutes. Don’t let anyone sit who isn’t 9-months pregnant or in a wheelchair. Each person gave one sentence on what they accomplished since the last standup; what they were going to accomplish before the next standup; and if they had any impediments. Forget new ideas, forget whining, and forget long interactions. Anything surfaced for collaboration should be tabled for after the standup, so everyone else’s time isn’t wasted. With rigor these meetings are amazing. Allowed to wander off course, they are a waste of resources. And it’s a lot of time. If you have nine people meeting for 15 minutes every day, you’re investing 11.25 person-hours every week and more than a person-week each month. That’s non-trivial and needs to be worth it.

Well-run standups mean that no individual or task can be more than 24-hours off track.

Agile SaaS Management Overhead

I hope this is where you realize what I mean by just enough. The painfully basic and lovingly simple ‘agile’ process I just described still consumes about 48 person-hours per sprint. That’s assuming nine-people attending daily stand-ups and sprint planning. That’s 16 person-hours a week or over 100 person-days per year. And that’s cheap. More rigorous versions cost more, which is fine, unless you have diminishing returns from the additional time investment.

The Benefits of Just Enough

Without any structure, growing SaaS companies can run fast and wild. But they’ll ultimately accrue deep management debt that hurts the very things they optimize for. By applying a lite agile methodology, order can be brought to the chaos without stifling creativity or momentum. From marketing, to sales, to customer success, to operations, lite agile can be just enough process to support a culture of continuous improvement.

Content by Beacon9 SaaS Business Advisory

Related Posts

6 Ways to Create a Culture of Customer Success

Sep 10 2019

As the leader of the customer-facing parts of a SaaS organization, I was quick to take accountability and responsibility for “customer success”, which of course really meant customer retention. It took me many years to realize how flawed my thinking was and to come to understand that Customer Success is bigger than any single department. […]

Read More…

The Entrepreneur’s Dilemma – Selling When Things are Going Well

Aug 01 2023

A common refrain we hear from owners of MSPs is that they’re hesitant to consider bringing on a partner or selling their business when things are going well.  We completely understand, as life is easier when you are growing, customers are happy, and margins are strong.  However, we’ve also seen the opposite, when a Managed […]

Read More…

Private Equity is Emailing & Calling My MSP Non-Stop – What Do I Do?

May 03 2023

Unless you are operating your MSP in stealth mode with little to no web presence, odds are that you receive inquiries from private equity groups (PEGs) on a near-daily basis. While this is flattering and can be exciting, it is important to first understand a few basics of how PEGs work, and second, appreciate the […]

Read More…