Keeping Agile SaaS Management Productive

By Justin Talerico

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.

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 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

Better SaaS Customer Onboarding Doesn’t Start With Process

Feb 05 2019

Whether you have a product-led SaaS or a high-touch SaaS, better onboarding doesn’t start with process it starts with vision.   Don’t get me wrong, every SaaS needs to deliver a great customer onboarding experience. And that will require a process to ensure it’s executed well. But if you want to improve how you onboard your SaaS users don’t […]

Read More…

Poor Low-Level SaaS Execution Comes from High-Level Symptoms

Feb 26 2019

The last couple of weeks have illustrated how challenging it can be for fast-moving companies to fulfill the right SaaS execution priorities. We have a couple of growth-stage clients struggling with it as well as a couple of earlier stage ones. Pretty much everyone says all the right things about prioritization for the business and opportunity costs. But when it […]

Read More…

How to Turn SaaS Revenue Wreckognition into Recognition

Sep 11 2018

SaaS revenue recognition is critical to understanding, managing and valuing the business. Rev rec must be timely, accurate, consistent and auditable to be a reliable management tool. Strategically, deferred revenue has sizable implications on how cash in the business is managed and invested. This is a CEO’s look at revenue recognition, not a CPA’s look […]

Read More…