Does This Fizz Good? A Thinking Tool for Faster Value Delivery

FSGD (pronounced "Fizz Good"): An acronym for Frequent, Small, Good, Decoupled that helps you achieve faster value delivery

FSGD (pronounced Fizz Good) is a thinking tool that LeanKit created to shape how we plan our work to get things done and provide value to our customers faster. FSGD is an acronym comprised of four equal parts: Frequent, Small, Good, and Decoupled. We think of it as simply a concise restatement of Lean principles, such as limiting work-in-process and reducing batch size, that have guided us for years.

In this blog post, I’ll tell the backstory of FSGD by sharing two not-at-all-FSGD experiences that propelled us to find a better way to plan our work.

Hurray! Let’s never do that again.

About a year ago, LeanKit found ourselves in what felt like a good spot. Our web and backend development teams had nearly completed work on a pretty beefy feature: revamping board connections. The marketing team was putting together the finishing touches on an awareness campaign, writing blog posts, and gathering screenshots. The customer success team was updating documentation. Getting all this working on our mobile apps wasn’t deemed a priority at the inception of the project, but enough of the backend bits were done that the mobile team could implement board connections at some point in the future.

We gathered all these teams together to discuss coordinating a release date. We felt we needed to deploy the backend and web code, release the marketing material, and update documentation all at the same time to present a consistent message and user experience. Over the course of the conversation, one team confessed that if they had an additional week or two, that would be super helpful.

Other teams piped up with similar sentiments. Then the mobile team agreed that, if all of a sudden there were a few more weeks to work with, they could hurry and get their bits done in time for the big, coordinated release. Thus, it was decided and agreed, and all those teams scurried off to work together to make sure that everything was perfect for the big launch day.

Launch day came after a heroic effort and many long hours. We deployed all the code, turned on the feature for our browser app, released the mobile app to the App Store, updated every bit of relevant documentation and help videos, released blog posts, tweeted, and facebook’d. Everything came together right at the last minute. All the code worked together. The blog posts and screenshots matched the product that magically changed right on users’ screens. It was glorious. We celebrated.

Behold the glory of a big, new feature!

Behold the glory of a big, new feature!

Once the dust settled our COO, Jon Terry, looked around the room and said, “Hooray! Let’s never do that again.” He may have earned a few sideways glances, but most of us agreed.

It was a lot of work to make a big, coordinated release. It took months, and in those months, not much else was released by the product team. So, there wasn’t much fodder for the marketing team to blog about, or for the documentation team to update, or for the sales team to show off. To our customers, it may have seemed like the company had gone somewhat dark or wasn’t working on the product any more. But to us, nothing could have been further from the truth. We were pulling all-nighters! That’s OK from time to time, but we knew we couldn’t keep everyone running at that pace on project after project.

While we’re at it…

Not long after that, our backend and browser teams were about to complete Single Sign-On (SSO). Our mobile team had been trucking along for quite some time, independently of the other teams, releasing small improvements to our Android app and were almost done with a big, new feature for iOS.

Here's the list of dependent projects, leading up to SSO. It looked like a good idea until we tried it.

Here’s the list of dependent projects, leading up to SSO. It looked like a good idea until we tried it.

The mobile team was asked to implement SSO in their apps, as well. When presented with this request, the team decided that the big new iOS feature couldn’t be released without SSO, and SSO couldn’t be completed without a series of other yet-to-be-started features. Since SSO is all about security, they thought, “Well, while we are at it, there are a few security concerns we should address.” Those got added to the mix as well.

Unfortunately, the “while we are at it” security issues took longer than expected. Then each of those yet-to-be-started features took longer than expected. So the team didn’t even begin working on SSO for quite some time. Meanwhile, that big new feature the mobile team put on hold just sat around unused by customers, and nothing was making it to the App Store. Sad times.

In the midst of all of this, it became apparent that the mobile team should have finished the big new feature and shipped it. Then they should have completed one of the new features or a security issue and shipped just that one thing, and so on. At least they would have had something done that they could show to customers. In fact, they could have shipped each individual part as it was completed. Instead, the team just kept building unfinished inventory of code … for weeks months. Nothing was going to be released until everything was done. They knew this, but they had set themselves on a path and couldn’t see a way out. It was painful.


Jon and I took advantage of an unusually quiet afternoon to ponder how to avoid the a future repeat of a big, coordinated release like board connections. And we pondered how we had made such a mess of mobile SSO. We thought of words that described where we were in those moments.

  • “We haven’t shipped anything in ages!”
  • “This is a big release.”
  • “We can’t release this until it is perfect.”
  • “This has to be coordinated with the other team.”

All of that felt bad, so we set out to define what a release would look like if we did the exact opposite. The opposite of not shipping anything in ages is to ship things frequently. And if we are going to do that, it needs to be small things. That’s good, since we don’t really want to bundle up big things and say, “Tada! Here’s a big thing! … that … we took forever to build.” We all know it’s good to be ambitious and build quality, but the pursuit of perfection can be a trap. It doesn’t have to be perfect. It just has to be good enough to work well until we can improve it, which we will do soon. It seemed like coordinating just made loopy math, as if two one-hour tasks by two different teams added together to become one five-hour task. So let’s not do that.

Our discussion ended in an agreement to do things in such a way that I can build good things and you can build good things and we can take advantage of each others’ stuff without sitting around waiting on each other.

That all turned into:

  • “We haven’t shipped anything in ages!” ≠ Frequent
  • “This is a big release!” ≠ Small
  • “We can’t release this until it is perfect.” ≠ Good
  • “This has to be coordinated with the other team.” ≠ Decoupled

Since we’ve adopted FSGD as a way to plan and decompose our work, all of our product development teams have improved their velocity, predictability, and agility. (It’s also made a significant impact on our marketing, finance, and business operations teams, but that’s for another post.) As a quick example, here is a view of the releases the mobile team has made to the Google Play Store and to Apple’s App Store since adopting FSGD around Q3 2014.

LeanKit Mobile Production Releases

LeanKit Mobile Production Releases

You can see that the number of production releases nearly quadrupled. That’s awesome, but the whole story is even better. Those were the releases. They actually pushed out far more beta builds.

LeanKit Mobile Beta Releases

LeanKit Mobile Beta Releases

The mobile team is effectively pushing out several beta builds per day, providing constant opportunities for feedback, review, and reevaluation of priorities. They are little changes, little improvements. Each beta build fixes one bug or adds one new view.

App Store icon

Continuous Delivery + External Constraints = Fine With Us

Of course, Apple takes their own time in reviewing and approving app submissions. Instead of being stifled by this bottleneck that is beyond our control, we use it to our advantage.

At any given moment there is one version of our app that is “live” and ready for download by customers and another version waiting to be reviewed. As soon as that one is approved, it is promoted to the App Store, and the latest beta build that has passed our internal QA is promoted to waiting for review.

We are frequently building small incremental improvements to our apps in such a way that decouples us from external constraints.


We’ve had a look at what motivated LeanKit to adopt FSGD. Some hard-earned successes and some failures helped us better clarify a concise definition of how we would like to build things. We strive to manage our work so that we can frequently deliver small increments of value to our customers in ways that build upon previous successes. The approach is pretty simple. After starting FSGD in product development and seeing it expand successfully around the company, we think it could be helpful to lots of teams across all areas of an organization.

Learn how to get started with FSGD

Check out the webinar recording of “Does This Fizz Good?” and learn how you can get started using FSGD with your team.

Daniel Norton

Daniel Norton is co-founder and Chief Technology Officer at LeanKit, where he leads several development teams. His previous engagements include native mobile app development with a small software consultancy and technical leadership at a large healthcare provider. Daniel is a polyglot with a passion for mastering emerging technologies and mentoring their adoption within development organizations. Follow him on Twitter @daniel_norton.

4 thoughts on “Does This Fizz Good? A Thinking Tool for Faster Value Delivery

  1. Wow! This post was outstandingly well written. You have highlighted some of the bugaboos that can slip into even a well-disciplined Agile team. And your telling of the story was perfect, making it fun and memorable. I aspire to write like this. I’m looking to understand how it also applies to Personal Kanban. Great job.

  2. That’s very kind of you to say, Steve. I appreciate your comments. I think I could imagine a number of ways FSGD could apply to Personal Kanban. The first one to my mind comes from a boss much earlier in my carrier who encouraged us to reply to an email as quickly as possible. Imagine a scenario where a coworker in another department sends an email requesting a non-trivial amount of work. A not-so-FSGD path is to do the research and work before replying with an answer. Maybe that could take weeks. In that time the requester might think you disregarded their message. A more FSGD path might be to quickly reply saying, “Thanks for the email. It will take me some time to research that question for you, but I will get back to you with a status by the end of this week.” That quick, small message is not the final answer, but it is good for now. It lets the recipient know you are engaged. You can then reply a day or two later with, “… here’s the research I did. I think the next step is for me to do ‘X, Y, and Z’ to complete that for you. I will let you know when X is done.” Follow up with another message when X is done, and so on. That also gives the recipient an opportunity to chime in on the process with, “Thanks. X looked good, but I saw an issue in Y” or, “Thanks. X looks good, but can we do A and B before going back to Y?”

    So those are my first thoughts. 🙂 Thanks, again, Steve.

Leave a Reply