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