How LeanKit helps it’s teams make effective decisions

This week I attended an excellent talk by Jon Terry, the CEO of LeanKit, at a Software East event hosted at Redgate Towers. If you’re not familiar with them, LeanKit is a workflow visualization SaaS company based in Franklin, Tennessee. Jon talked about the approach LeanKit took to help their teams stay lean and make good decisions as they grew from a small start-up to a medium-sized enterprise.

Here’s part of the abstract for the talk:

Does this FizzGood? Improve velocity, predictability & agility by asking a simple question

LeanKit’s founding team had a strong Lean-Agile background from previous careers. So, in the early days of the company, we just instinctively did things in a Lean way with as few formal processes as any startup. But, like any growing company, we eventually did have to start clearly defining how we do things. And like anyone, we were tempted to become more bureaucratic – with lots of scheduling, coordination, meetings and estimates.

Instead, we developed our FSGD (Frequent Small Good Decoupled) approach. This LeanKit way of working has provided our teams with a simple yardstick for making effective decisions without a lot of cross team scheduling and coordination. It has simplified abstract Agile concepts into something everyone easily understands and cheerfully applies on a daily basis.

From: http://www.meetup.com/software-east/events/227959891/

So, FSGB (pronounced Fizz Good!) is simply a mnemonic everyone at LeanKit now uses to help them make decisions that align with the company direction and it’s lean principles. The concept was defined by the four co-founders of the organisation (not by an extended committee) and rolled out to all areas of the organisation (Development, Marketing, Sales, etc). It now forms part of their induction process for new hires and is referred to frequently throughout daily life at the company.

Giving teams and individuals autonomy to take decisions and providing the right-level of guidance so they can do so in a deliberate manner, consistent with the aims of a business is something I’m really keen to explore. So, here’s what I took away from Jon’s talk…

What does FSGB stand for, then?

Frequent

• What? Deliver stuff frequently and at a deliberate pace – not annually, quarterly or sporadically.
• Why? Basically, because it’s better! LeanKit is a SaaS business and Jon added “I have to resell to all my existing customers every single month”, so delivering new stuff frequently is paramount. It also reinforces all the agile goodness of continuous integration, continuous delivery, customer feedback, stress-free/low-risk releases, etc.
• Anything else? Jon added that if you are in a high margin, fast-moving business, investing in speed of delivery will pay for itself very quickly; “it’s basically free”. If your team ask for money to get their cycle time down, you give it to them.

Small

• What? Break work down into its smallest valuable components. Each small piece should be able to be delivered independently.
• Why? Delivering work in small sections brings a load of benefits; reduced work in progress, increased opportunity for customer feedback, reduced risk for each individual release, etc. In fact, it’s this small batch size that really helps enables a lean workflow approach.
• Anything else? By breaking everything down into small, valuable pieces teams may find that they are finished with a feature earlier than they expected. For instance, a development team wants to develop awesome feature, X. They spend time thinking about whether it can be broken-up into smaller units and realise that it comprises four distinct pieces of functionality. So, they put the four sub-features into a queue and begin work on the first piece – x1. They complete x1, ship it and start work on x2. This process continues until they have shipped sub-features x1, x2 and x3. However, before starting x4 they realise that feedback from their customers is telling them that they do not need it. In fact, x4 would make the user experience worse. As a result, the team decide they are done with feature X and move on to feature Y (which users are really desperate for!). The time required to do x4 has been saved and customers are happier, awesome.

Good

• What? Things need to be good to be done, so we don’t ship garbage. At LeanKit, the definition of “good” includes something being tested, logged, documented and reviewed (known as TLDR – they love an acroynm).
• Why? Well, shipping small stuff frequently should not be at the expense of quality. A Saas business needs to resell to their customers every month, remember? So, we can’t afford to deliver them garbage. On the other hand, “good” does not mean gold-plated. Gold plating is very unlikely to be more valuable that the next thing on your work queue.
• Anything else? Jon is an advocate of Henrik Kniberg’s more nuanced version of the Minimum Viable Product idea. Henrik talks about the concept of a Minimum Testable Product, a Minimum Usable Product and a Minimum Lovable Product. He feels teams should go through each of these phases when building a product and not jump straight to a gold-plated, finished version. If you take this approach, good things happen (see image below or Henrik’s excellent post for more about this). This idea works all the way down to a feature level – teams should ask themselves what the minimum that would be good enough to test an idea, and make that first. They should certainly not hold onto something until (they think) it’s perfect.

Decoupled

• What? Work should be independently valuable but it should also be isolated from all other work, so as not to spread risk to other areas.
• Why? So that one piece of work does not put other pieces of work at risk. Jon added that if one small feature in a frequent release is garbage (and not “good”) it will only affect a small number of people and will not damage other things. This backs-up the drive for small, frequent releases.
• Anything else? Keeping to this “do no harm” manta means that LeanKit can trust individuals and teams to act independently because they must ensure that their work will not damage another team or their work. This reduces the amount of cross-team co-ordination required and therefore reduces the number of coordinator-type roles in a business.

Can this be applied elsewhere?

Jon was keen to emphasise that the components that make up FSGD are not rocket science and were certainly not dreamt-up by LeanKit. However, there is a real strength in calling these principles out so explicitly in a business (growing, or otherwise), and asking the people to work there to use these idea to help them make effective decisions.

Distilling this philosophy down to a four letter mnemonic – FSGD – may seem imprecise or simplistic but it has ensured that the notion is small and clear enough for people to keep in the forefront of their minds. It sure beats capturing it in a hefty tome that no-one will ever read.

In my opinion, emphasising that things should be “frequent”, “small”, “good” and “decoupled” would be a valid thing to do at most software companies. I’m not sure the “Does this Fizz Good?” call to action or the cute soda can mascot that accompanies the concept is going to land in a (typically cynical) UK software company environment. However, being principled about how you are going to work in order to reduce bureaucracy and help individuals and teams make sound, consistent decisions certainly should.

If you want to discover more of the backstory to FSGD, there’s a related article on the LeanKit blog by Daniel Norton (LeanKit’s CTO) – Does This Fizz Good? A Thinking Tool for Faster Value Delivery.