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?

FSGD-Words

Frequent, Small, Good and Decoupled – but that soda can looks waaaay too pleased with himself, if you ask me

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

Frequent, Small, Good and Decoupled – but that soda can looks waaaay too pleased with himself, if you ask me

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.

Laying the track as we go: New product development and the Agile Release Train

The ‘Agile Release Train’ has been popularised as part of the Scaled Agile Framework – a set of guidelines aimed to bring agile software development to the enterprise and programme delivery. In the framework, the train metaphor is used to describe a series of iterative releases set to a strict schedule that multiple teams must abide by in order to synchronise and ship their work.

Laying the track as you go

Laying the track as you go

We use the “train” metaphor to communicate a few key concepts.

  • The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
  • It delivers its cargo to customers (Release) or is used for internal evaluation and proof of incremental system robustness and quality (PSI/Release).
  • If an Agile Team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.

From http://scaledagileframework.com/agile-release-train/

I’m fortunate enough to work at Redgate – a software house based in Cambridge, UK. At the moment we don’t have a need for the Scaled Agile Framework and all it’s rigourous, and potentially overbearing, process and procedure. I predominantly work with a small software development team (5 to 10 people) focused on a single product, with relatively little need to share work across multiple teams (certainly when compared to a large enterprise-y development programme). This could well change in the future, as we’ll be pushing to synchronise efforts across teams much more regularly. But at the moment, scaling agile is not something on our todo list.

Release Wednesdays

In the last few years, the teams I’ve lead have decided they like to to release their products every week. Every Wednesday, to be precise. Why? Well, I’m a bit torn on how to answer that. The project manager part of me says it’s because we believe in releasing frequently to give our users valuable enhancements as quickly as possible and to get timely feedback on the direction we are taking the product. The developer part of me says its because we get a kick out of putting the stuff we’ve created into the hands of people who’ll enjoy using it as soon and as often as we can.

In any case, by releasing every Wednesday we’ve proved that releasing frequently is best practice, as we extoll the virtues of keeping the delta between releases small and the risk associated with an individual release low. We’ve also found that practice makes (almost) perfect and that the more often we release the easier and less distressing it has become.

We choo-choose the Release Train

Although, I’d used the term ‘Release Train’ with the team for most of the time Release Wednesdays has been a thing, it’s only in the last few months that I have explicitly used the concept to help the team plan, visualise and track their work. I don’t think it’s an exaggeration to say that doing this has been transformational.

The SQL Lighthouse Beta Release Train

The SQL Lighthouse Beta Release Train

The catalyst for a more formal adoption of a Release Train was a realisation that my current project, SQL Lighthouse, had a significant deadline looming that we had no clear plan for how to meet. To be more specific – the team, as a group, realised that for SQL Lighthouse to be a success this year, it was paramount that we had a public beta of the tool ready for a Redgate’s annual London conference.

Once the target was agreed, the team set about deciding what needed to be delivered in order for this to be achieved. We decided on a single, valuable use case we would support with the Beta release and broke the required functionality down into the smallest possible chunks (we used User Stories for this). We then looked to our weekly release cadence to help us decide if this was, in fact, an impossible task.

We wrote up the dates of the 6 weekly releases that would happen before the deadline and placed cards detailing each chunk of functionality under those dates. We were then able to quickly arrange, prioritise, and re-arrange the chunks into a reasonable plan. The entire team gathered around the wall discussing, pontificating and worrying about the plan for the upcoming work – it was the most engaging planning activity I’ve experienced.

Although we’d managed to get each chunk of work down to a small, reasonably independent unit, it was clear that they wouldn’t all take a week or less to complete. We didn’t spend too much time worrying about an exact (or even relative) size, as a group we took a guess at when it could be shipped and moved on. So, if the team believed it would probably take two weeks to complete a particular chunk, it was quickly assigned to the subsequent release. A key point here is that the team realised they were making a informal guess and trusted ‘management’ not to hold them to their hunches.

In the end, we fashioned a release plan made up of 6 weekly, iterative releases. Vital functionality was front-loaded into the early releases and nice-to-haves had settled at the end. As each release was scheduled for a Wednesday, and any functionality that was not ready for that day would have to wait for the following Wednesday – we had an Agile Release Train (see below, cut-out train and carriage wheels were an optional but metaphor anchoring extra).

The SQL Lighthouse Beta Release Train

“Plans are useless, but planning is indispensable”, Dwight D. Eisenhower

Of course, as soon as we’d drawn up the plan it was out of date. If Agile has taught us nothing else, it’s taught us to expect change. So, during the next six weeks we kept the Release Train up-to-date and relevant. It reflected functionality we had shipped, the proposed contents of the next release and any realisations that we just couldn’t get something done for when we’d hoped we would.

Importantly, the whole team took part in analysing the knock-on effects when a piece of functionality (or cargo, to keep with the analogy) missed a release we had earmarked it for. This prompted releases (carriages) to be re-arranged, functionality (cargo) to be juggled and scope-creep (baggage) to be jettisoned. We were all engaged in the process of project planning.

As I detailed in a previous post, the plan and the planning worked – the team met their goal of releasing by the important trade show and in the process transformed the product from a proof-of-concept alpha into a genuinely useful tool. As a direct result of that success, the Release Train was here to stay; we’ve applied the metaphor to every step we’ve taken with SQL Lighthouse since.

The next Release Train: Get 250 users onto the Beta

More than just a release plan

As I reflect on how we do software development on the SQL Lighthouse team now, it’s interesting to note the side-benefits that the Release Train has brought; including small user stories, #NoEstimates, collaborative planning and implicit scope management. This has turned into a long post, so I’ll cover those in my next one – 5 benefits of the Agile Release Train for a single team.