The Big Gamble By 37signals
My take on new tool by creators of Basecamp and HEY
Jason Fried, CEO of 37signals, creators of Basecamp and HEY, recently published two demos of their new product, Fizzy, as their take on the idea, issue, and bug tracker thing. The collection view (similar to a board in Kanban) contains two columns, “Considering” and “Doing.” The cards in both columns have a title, creator and assignee, and info on when the card was created and last updated. The cards in the “Doing” column have a stage selector (“Investigating,” “In Progress,” “On Hold”). The sequence of stages is defined by one of the selected workflows, which can be set in the collection settings. Depending on the selected stage, the card and its contents change color scheme, making it easier to identify. Completed cards go to the footer of the collection view, where they all sit together, each greyed out with a big stamp reflecting the reason for completion.
For starters, I have a lot of respect for both Jason Fried and 37signals CTO David Heinemeier Hansson and their work. In the age of soulless agilistic monsters like Jira, ClickUp, Asana, and dozens of their faceless clones, Jason and David managed to create their original way of doing things called Shape Up, which in many ways feels better suited to modern mobile and web development than Agile, Scrum, SAFe, and the rest of their kin.
That being said, building software that is vividly opinionated both narrows your potential market share and shapes your audience to be more receptive to experiments. Fizzy is a brave experiment, and its outcome could be far more far-reaching than people think. The main reason is that Fizzy is the first attempt by a major company to try to break away from Kanban. At the moment, every single project/product management tool is built around the Kanban board. Indeed, you could have all sorts of flavors of lists, Gantt charts, timeline views, but the main tool that 100% of developers use on a daily basis is a Kanban board. It is the Kanban board with its cards and columns that shapes our perception of work, our communication flows, decomposition, understanding of work completion, and workplace psychology in general.
If the Fizzy experiment fails, it could make other players think that Kanban is an undefeated king and nothing can replace it, thus stalling progress in product management tooling. As an author of the iterative-functional method, which radically breaks away from Kanban, I have a personal interest in Fizzy being successful, as it might boost the legitimacy of non-Kanban approaches in public perception.
The Agile Manifesto was written in 2001. The first book that introduced Toyota Production System (i.e. Kanban) principles into software development was published in 2002. Kanban boards (named at the time Agile boards) were incorporated into Jira around 2012. Getting rid of Kanban won’t be an overnight process and likely will take many years, but the first steps are the most important.
This is the reason we, as a software development community, must reflect on Fizzy’s strengths and weaknesses before it goes public. I will start with the most obvious things, but will not overlook technicalities.
In his demo, Jason made a fair point that long backlogs are bad; they collect dust and outdated information, that’s why they call it “badlogs” internally. The solution integrated into Fizzy’s core is forcing every card to close if it’s not updated in a certain number of days. The forced trimming, though, does not address the true reason people want to have a backlog, which breaks down into two sub-reasons.
The first one is that product people need a place to prepare the specifications. They understand that the spec will eventually be broken down into tickets, and they don’t want to create a document first and then break it down, doing double work, unless they must. In the corporate world, the situation when a feature gets stalled in a pipeline for a multitude of external reasons is the norm. It does not depend on the people who will write up and move those Fizzy cards. The feature might well get unstuck two months later, and they don’t want to lose the cards because a lot of work has been put into it. That means every 30 days they will have to bump up the cards with a meaningless comment, rendering the core Fizzy feature not even worthless, but anxiety-inducing with the countdowns. And once you have a core feature that irritates you, how would that make you feel about the whole product?
The second reason people think they need a backlog is the small things about existing features, defects, and tasks, which form technical debt. The team could have no capacity to deal with this quickly for a number of reasons, but those reasons do not discard the fact that those bugs and tasks are valid, and fixing them will improve the quality and resilience of the product. In that case, forced card removal is done under the assumption that if the defects are indeed important, they will get re-created and prioritized. The argument has its merit and candour, but it does two destructive things: 1) it discards the effort people made to log the defect, steps to reproduce, and potentially important time-sensitive context; and 2) it symbolically sweeps those breadcrumbs under the rug, creating an anxious psychological environment where people know that bugs, however small, are not getting addressed. Both things will again incentivise people to bump up defects every 30 days to keep them afloat, forming the long list Fizzy was designed to get rid of.
It might be too big of an ask to break away from Kanban when it is the only thing your audience ever knew using your main product, Basecamp, or your competitors’. In that sense, Fizzy bends Kanban without breaking it, which might feel like a safer evolutionary approach, but it ends up fighting its inherent Kanban entropy with new entropy.
In addition to columns and drag-and-drop, Fizzy inherits tags and comments. You would be right if you said every single tool has got them, but when we try to break away from Kanban, it’s worth at least stepping away and having a good think about what true purpose they serve and why they exist in the first place.
The reason tags were introduced is similar to why people need search functionality. The backlog, the Kanban board itself, and the afterlog – the void completed tickets end up within — are three disorganised heaps of information by design. To retrieve something from these heaps, we have to use a long needle of a search line. Tags are predefined needles designed to make your search easier. In the end, though, it’s an additional source of entropy. If you look up the list of tags in the Fizzy demo, the list of tags is already long — but we wanted to eliminate long lists? You’d be right to say it’s a technicality, but it nevertheless affects the psychology of the workflow.
The third horseman of Kanban entropy after the board itself and the tags is comments. In a ticket, they serve two main goals: 1) a detailed status update and 2) figuring out unknowns or blockers. It is not necessary to have this information presented in a list of texts which you have to read, otherwise you might miss important context. It’s how tickets have always worked, though, and no one questioned the status quo. Comments represent raw process in the form of white noise, and people working with tickets need the result of that process, the details of status and decisions made on discussions, not the whole discussions. Acknowledging that will allow rethinking the card screen layout in a way that saves people’s time.
Modern life and the modern workplace are overstimulated by information. It challenges us to set up constraints in our workflows rigorous enough to allow people to focus on the most important things. In that sense, Fizzy takes a big step ahead and several small steps backwards. Another example is having two sets of notification stacks instead of an industry-level one. Notifications are a third, inverted way of getting the important information from the disorganised heap of data.
The last bit of Fizzy design, which takes its roots from Kanban cards, is taking around 25 percent of card space in list view. That is information about who created the ticket and when, who is assigned to it, and when it was last updated. I do believe that everything but assignee information is white noise and relevant only to forced closure functionality. Why do you care who and when created a bug, feature, task? It needs to be fixed, that’s it. If a card was updated six or three days ago, how does it affect what you need to deliver in the future? It takes up space and makes you scroll longer — nothing else.
When you scroll all the way down to the bottom in Fizzy, you will see the “Recently closed” footer column, which is a nice way to acknowledge and fill the traditional void Kanban tickets have in their afterlife. It is still disorganised. The reason for closure, represented as a big stamp (i.e. a custom case of a tag), is not meaningful. In a development workflow, people have no reason to search for all completed cards vs. all duplicates. How is that not white noise?
Undoubtedly being a step forward for product management, Fizzy in its current form is sadly ridden by the hereditary illnesses it takes from Kanban. The big gamble 37signals are taking, though, is connected to their flagship product, Basecamp. When Jason Fried published the first demo, a lot of people asked how Fizzy and Basecamp will work together, because both are used for tracking bugs, tasks, et cetera. To all of them, Jason replied that Fizzy is for people who cannot use Basecamp for unknown reasons. People will keep asking that question because this answer is not satisfactory. Basecamp is a general-purpose project management tool. There is no thing it cannot do that Fizzy does. Fizzy now is doing Kanban differently, and that’s it. The problem is that having two overlapping products will either: 1) slow down Fizzy adoption for both new customers and current Basecamp users, or 2) start cannibalising Basecamp’s market share for unclear financial gain, as Jason mentioned Fizzy will be a cheap product.
That being said, even if 37signals wanted to use a methodology that completely breaks away from Kanban, that would have confused the customer base in a similar manner. You cannot preach two gods at the same time, Kanban and something else. You have to choose wisely. The path to progress is rough, and we all need to work together to bring the future of product management closer.