Our Way of Working and our Agile Board
In short
- We focus on creating value and having a joyful work culture, and we believe, that the rest will follow
- We are very pragmatic; we continuously reflect and change our process to the current need
- We have many columns, but we don’t have many process steps. And all the columns are controlled, understood, and owned by the team
- “Done” is mislabeled since the fun part of the features journey in fact starts here
- We always end our morning meeting with “is it unclear for anyone what to do today?” — and since everyone feels it’s okay not to know, people are not afraid to say, “I have no idea what to do today”
- If we have a challenging day ahead of us, before we leave the meeting, we try to summarize with “what is the goal for today” to ensure we are fully aligned
If you just want to pick something from this post, it could be the evaluate column/step (see below). In my experience, “evaluate” has profoundly changed how the team thinks about the desired outcome, and to own more of the “what” and “why” of the work.
About this post
In this post, I will try to share how we (Product at Urb-it) work with our board and the process behind it. Our board is a vital part of our way of working, and it — together with our process — is a result of years of continuous improvements (to match our needs).
I don’t think we are unique in our learnings or ways of working, but sharing this might give some inspiration and ideas for others to try. Also, this is a snapshot of how we are working today, things change, and this overview will not be 100% accurate next week.
It’s worth saying that this process is tailored to us based on our needs and challenges. This way of working might not be for you or your context. If you have a classic “Todo” — “Doing” — “Done” and are happy with that, please continue with it 😊
Philosophy
Having a process in tough times
Our process has been with us during good times and hard times. We have solved complex cluster crashes, burning capabilities changes, and significant data center outages with this process — so we know that it works both when pressured and when not. This is important since many processes work during good times, but not when times get tough. The truth is that it's only when a process is being pressured, it shows it's true colors.
As a startup, times are sometimes harsh. And in those moments, when the earth is shaking under your feet, it's good to have our process to lean against — a process that can carry you through the dark passages.
A myriad of columns — but not a myriad of process steps
Our board is a bit different compared to traditional scrum or Kanban boards. At first glance, it might look a bit chaotic and messy, with many columns. And yes, it has a lot of columns, but this is not the same as process steps. We know it takes a couple of days to get used to, but in the end, we think it's worth it.
By design, our board is very fluent and dynamic; parts of the board and its columns change from one week to another. We had this on our physical board before covid, and we have continued to have it on our digital board.
The deeper reason this "myriad of columns" works is because the columns are controlled, understood, and owned by the team. There will never be anything on the board that the team has not been part of evolving and bringing to life.
Goals with our board and process
Before we go into details about the layout of the board and its traits, let's look at what we are trying to solve. Since our board is a visualization and a supporting tool for our process and ways of working:
- The board is optimized for the team, not for people outside the team (we have other channels/forums/tools for that)
- The board aims to support team members in their day-to-day work, to visualize what is going on and who is caring for different work
- To give an overview of what might come next (since we are a startup, things might change rapidly)
- To help remember what has been released (to boost good feelings)
- To warn if we are working on too many things at the same time (soft WIP limits)
- To push for completing things, rather than starting things (stop starting, start finishing — See "Walking the board")
- To enforce a learning culture where we evaluate our work
- To make it possible for anyone to steer and control the processes parts (see "Spiritual Leader")
- Support working on challenges/problems, not on predefined solutions
- The process should be titled towards being a bit too light rather than too big. We all have worked in heavy and slow processes, with many handovers and gating mechanisms — we don't want to do this.
- Last but not least, the board reflects our reality and our current process. This means that it's not a "wish" state, nor are we trying to adapt our reality to the board — the board continuously adapts to the reality
Democratizing work visualization
In any process, it should be easy to visualize work. We work to lower the bar and remove gatekeeping mechanisms preventing people from visualizing work on our board. It should be easy for anyone to add things (in our case, cards on our Trello board).
In any process, it should be easy to visualize work.
A friend of mine highlighted this recently. On his current assignment, people didn't add things to the board, since the process of adding was too cumbersome. They needed to pick the right card type (epic, feature, item, task, chore, etc.), find and link to the correct parent/epic, fill in particular fields, and so forth. Easy is the key.
On our board, we just add things. Then we iterate on the card as we iterate on our work. They get better titles, (if applicate) a ribbon, KPIs, labels, merged with other cards, split into new cards, etc.
What should be on the board?
In general, we are allergic to OBW — Off Board Work. When you are working on something, put it on the board. We default to have it on the board — but as stated at the beginning of this post, we are pragmatic.
Working with the board
Walking the board
Every morning we "walk" (go over) the midsection of the board from right to left, from where the value is closest to hit the customers, to where work has the farthest way to reach the customers. This is important because the journey of work starts when it hits our customers; the fun part begins when we are "done".
Our starting point for morning discussions is based on the work on the board, not by going from person to person. For us, this is important, the shift from starting with the person vs. starting with the work, so let me try to clarify it a bit (how we see it):
The starting point in traditional standups / morning meetings is the team members. In those meetings, you usually go around in the team letting the members answer three different questions: 1) what I did yesterday, 2) what I will do today, and 3) if I have any obstacles/blockers. The problem with this approach, as we see it, is that it, after a while ends up with the same mantra 1) yesterday I worked, 2) today I will continue to work, and 3) I have no blockers. Also, since we are following the path of the members, and not the path of the work, it becomes process jumpy — we are jumping around in the process, instead of following the process. So that's why we do it the other way (and of course, we are not alone on this).
Where does work happen on the board?
Basically, we can work in all columns/steps, so that you can see an avatar on items regardless of phase in our process ("Backlog" avatar = someone is prepping things, "Stage" avatar = someone is testing things, "Evaluate" avatar = someone is evaluating things, etc). So ongoing is not the only place where work happens.
Our columns
Section 1
- Upcoming
- Spiritual Leader
- Current Focus
- Backlog or Prio 1 | Prio 2 | Prio 3
Section 2 — "midsection"
- Ongoing
- Stage
- Ready to Deploy / External Waiting
- Evaluate
- TBD (this is the actual name of the column) ⬅️ We start every morning in this column
Section 3
- Done {month name}
- Tech Talk Topics
- The Wall — Where Good Ideas Go to Die
- Done {pre-month name}
We will describe them in reverse order — since that is closer to how we see our work on the board.
Section 3
Done {previous month name]
This column is the previous month's "Done" column that we move to the end of the board. So for this month, it will be "Done September". We keep this month's "Done" together with last month's "Done" on the same board. When a new month starts, we will move the pre-pre-month column to another board called "Archived" (to save space and to make Trello less slow). This means that we always have two months of "Done" on the board simultaneously.
The Wall — Where Good Ideas Go to Die
In our discussions and planning, many of the ideas/wishes/fixes/features will not make it into a backlog. They are, in many cases good ideas, and we would love to do them, but we all know that as finite human beings, we need to cut hard to make the value of time. In many cases, even with all my things, it's hard to "kill your darlings". So this phrasing helps us a bit in the process of throwing things.
We keep a WIP of 100 on this column. It might sound like a lot, but we quickly fill it up. When we reach 100, one or two from the team will take 10 minutes to see if there is anything worth picking up, before we archive the entire list and create a new one. We are not scared of throwing things, since if it's important, it will surely come up again.
One more thing: We use the three-strike rules for minor / less critical issues and problems. This is a way not to spend time on things until they happen multiple times. This means that we do nothing the first time we see a specific issue/problem. The second time the same thing happens, we do nothing. But then the third time it happens, we act on it. But of course, our good judgment overrules this rule when needed— if we know something is important, it will be prioritized directly without any third striking.
Tech Talk Topics
Since we don't want to create knowledge islands within the team, we greatly value knowledge sharing. We have a Tech Talk with the team when we want to share something with the team and feel that Slack/Mail will not cut it. It's like a meeting or a demo, where you present something in front of the team (remote or on-site). We are very relaxed regarding the format of our talks: some members show code, some slides, and some do a quick lighting talk. The goal is sharing, not nailing a perfect format.
Example from this month:
- "How to avoid large object heap allocations"
- "Optimize Drone CI setup"
- "GTM/GA overview in Product X"
- "Kubernetes pod spread strategy"
When we have a couple of things in this column, we book a session for people to join.
Recently, due to a joke from a team member, we are now moving to call them TikTalks. It's utterly confusing for others, when our team speaks about having TikTalks in the kitchen.
Done {month name}
This column will contain all things we complete this month. It's a good way for us to:
- Remind us of all the amazing things we have delivered this month
- Get closure from the Evaluate column (see "Evaluate" column)
- "Cheat list" for upcoming retros
- And to prime our brain with dopamine — it's like checking a box; it feels good
Section 2 — midsection
TBD (this is the column name)
In our process, we have a particular column called TBD (To Be Discussed). In this column, we add things during the day we want to discuss or highlight with the entire team during the next morning's meeting. We use Slack (the product) a lot (maybe too much, but this is another post), and sometimes we use mail — so most discussions and decisions will happen there. But in some cases, we feel it would be best if we synced it with the entire team at the same time (face-2-face or remote video call). By having this connected to the standup, we don't have to interrupt focus time later during the day. Also, it's a great chance for everyone to speak their mind, even for topics that could be seen as "small" in other contexts.
Examples:
- Some decisions you want feedback on
- Something we found that we should investigate/handle
- Something that has popped up in discussions with customers or integrators
- Bugs, capabilities, features, etc
- Team and company updates
Sample from the board:
- "We need to update the phone number in Product X and Y — do we really have it here?"
- "X-mas planning — time to plan for our peak period"
- "Can we remove this Product X?"
- "What are our coding conventions for X"
Our morning meetings start every morning in the TBD column by taking a short discussion on each item (it's usually 2–6 items/topics every morning). The goal is to move the item away from the TBD column before moving to the next one. This means that the item will be moved to:
- The Wall
- One of the Backlogs
- Ongoing
- or directly achieved
Sometimes it's an extensive discussion, and we leave it in TBD with the label "Discuss after standup" (see “labels” below). The column is always cleared before the end of the day.
Evaluate
This is a crucial step in our process. Before anything goes to the "Done" column, we must ensure we hit the desired outcome or value. We try to be data-driven when we can, and when metrics are available, we use them to guide us in our evaluations. Since we are a startup/scaleup, sometimes we don't have data since the area is new, so we need to use soft metrics for the evaluation (we try to do lean startup when we can, but A/B is not straightforward in public high volume API's).
In some cases, we as the team are the target for the work, and then we can evaluate it quickly based on our metrics or feelings. (Yes, feelings, we use them in cases where data is not present. It's not perfect, we know this).
When a specific work has been evaluated, it goes to Done if we have reached the desired outcome; otherwise back to Ongoing/top of the backlog.
Some samples for the board:
- Capability X in product Y
- Service X memory usage, remove unnecessary memory allocations
- Stop services Y used on the old API
- Postcode mapping validation in Product Z
Ready to Deploy / External Waiting
We work most of the time on single-piece flow, and we ship to production multiple times a day. We try to work together on things, not to have too many things ongoing simultaneously. This leads to us releasing roughly 4–6 times a day to production. But on Friday after lunch, we usually don't go to production unless it's critical. This is just a precautional step — we rarely break things in production thanks to our testing grid and validation procedures — but to play it safe, we do it like this (you don't want to skip your Saturday picnic with the family to debug production). In those cases, things might be waiting in this column for a while, until we can release them again (e.g., on Monday morning).
We also work with external partners and systems that release in a different cadence than ours. So sometimes we need to wait a couple of days to make sure our depending party is ready or has provided the change we are depending on (when we can't or it's very costly to feature flag changes).
Stage
Like others, we have a test environment that is similar to production. In this environment, we ensure that everything works as expected and keep our performance metrics (we have highly demanding clients for our public API). Since we have containerized everything (Kubernetes), we rarely get any "it works on my machine" issues. We usually move things from Ongoing to Evaluate, since we move quickly from Stage to Production. But we have cases where things need to hang in Stage for a while, e.g. Friday afternoon. We don't have any testers, so everyone tests their things or helps test others' work. We rely on automated integration tests and unit tests for key behaviors.
Ongoing
This is the classical kitchen sink for "ongoing" work. When we move things from the backlog or one of the prio columns, they end up here while working on them. When having burning or expedited items, they will directly hit the ongoing column with a couple of avatars on it (and labels).
In the "ongoing" we sometimes have things that are "paused". This could be that we are waiting for some external event to take place, or we are waiting for an external party to respond, or the person working is away. "Is away?" are you not mobbing or pair programming on all things? Our toolbox has many different tools and methods that will be applied based on context. This means that we sometimes do pair programming, or mob programming (rare), or fly solo — regardless, since we work on a few things at the same time, it's usually easy for someone else to pick up a "paused" item (more on this approach in another post).
Section 1
Backlog or Prio 1 | Prio 2 | Prio 3
We have a fluent structure of the backlog(s) where we let the work and current focus determine how the structure will look like. This means that sometimes we as a team have one backlog, where all the work is originating. Sometimes, we create temporary sub-groups in the team, and we will create backlogs based on those focus areas (or challenges as we call them, more on this in another post). This means that we change from one backlog to multiple prio columns (inspired by Priority filter by Corey Ladas http://www.marcusoft.net/2013/08/repost-some-tools-for-improved-focus-improve-teamwork-and-faster-delivery.html).
The prio columns work like this: We have one area that is the most important to work on, but usually for us, no more than 2–3 people can work effectively on the same area at the same time (regardless of flying solo or pair-programming). This means that the rest, when not supporting members working in Prio 1, will take something in Prio 2. Sometimes we see that no more than 2–3 people can join in on Prio 2 work and still be effective, so they will work on Prio 3. When Prio 1 sub-group is done, usually 3–5 days, we will close the Prio 1 backlog, and Prio 2 will be Prio 1 and so forth. The Prio 1 sub-group is then split, and members join the new Prio 1 or Prio 2 sub-groups, if there are any. Sometimes when Prio 1 is done, we only have one backlog left, "the backlog". Then, a couple of days later, we might have Prio 1 and Prio 2 again. One benefit of digital boards is that it is effortless to change within the defined board capabilities.
This way of dynamically moving between one "backlog" to several "Prio backlogs" serves us very well. For us, this is a way of staying focused on what's most important, and at the same time, having a structure where it is clear how to support each other. Also, with this approach, we find ourselves in the classic "waiting game" where thing X can't be worked on since thing Y has to be done first.
The key thing for this to work, is that we prepare all work as a team, so everyone knows what we have in the backlog or the backlogs.
Spiritual Leader
This column has nothing to do with any religion; it's just a play of words from an internal joke many years ago. To ensure that everyone knows our process and thus can lead our work, we rotate the morning leader/facilitator daily. Our "spiritual leader" each morning is responsible for taking the team through the morning meeting and making sure we follow the process we have agreed to. It might sound like a trivial/odd/wasteful thing to do, to rotate who is controlling the morning meeting, but it really makes the team more autonomous and committed to our way of working.
Also, this also leads us away from complex processes where you need to have a specific person dedicate their work to facilitate the board, and manage the process.
When the process is thin and natural for the people in it, anyone can lead and improve it.
And since everyone knows the process and our board, we don't need to have a person moving other's cards, nor play the role of Inspector Jacques Clouseau and constantly checking: "is this card in the right column?
The spiritual leader also ends the meeting with a last guarding question: "does everyone know what to do today" or even better, "is it unclear for anyone what to do today". We should never leave the meeting if someone is unclear about today's plan.
Also, if we have a challenging day ahead of us, before we leave the meeting, we try to summarize with "what is the goal for today" to make sure we are fully aligned.
Current Focus
We work with something we call "challenges". It's similar to what you would call epics in a classic user store setup (I will share more about this in a post later). We usually have 1–2 challenges ongoing at the same time, and in this column, we highlight our current focus, to make it easier to align and stay on what is most important. The mechanics of this is simple: when we focus on a new challenge, we create or move the challenge card to this column.
Example from the board:
- "Sunset of old platform"
- "Product X — Manage Partners"
- "Product x — Data Insights 2.0"
It should be clear to the team "why" we have these challenges ahead of us.
Upcoming
In our "upcoming" column you can see the things (challenges) that we think will be next, or probably be next. It's not a backlog of 100 items, but a handful of things we think will be next for the upcoming 2–8 weeks. We have a cadence of planning every second week, but we don't do sprints. We have a specific cadence since it's easier for the one planning the work and organizing meetings, but we also mixed this with pull-based planning when needed — we are flexible (more on this in another post).
… and that was the last column :)
Some bonus things
Card to remember essential events
In our TBD column, we have a special card that helps us look at new data points and dashboards weekly. We all look at dashboards all the time, but it's good to refresh every week on some that you might have forgotten about or some new ones you have not yet seen.
This card also has control mechanisms for our process: to make sure we don't forget about booking Retrospectives and Tech Talks.
Pushing Trello — To support our visualization needs
We use Trello for our digital board (we are ~kind of happy with it, more about this in another post). We could use some other software for our board (since we are not relying on any Trello-specific capabilities), but we were using Trello for other planning activities before covid, so when we went fully remote during covid, it was simple to pick Trello for our board.
We are using some home-cooked tricks to make it easier to work with the board on Trello and to group things that belong together (without adding Trello special plugins):
- We use Trello labels for our global initiatives (I can't share them in exact wording, but think of them as your company targets/sub-goals). This means that everyone in the team needs to understand our global initiatives and how the current thing they are working on, relates to one of them.
- We also use Trello labels for a lot of other process-related states
- We use custom-made image covers as "ribbons" to group cards that belong to a specific challenge (we have a script for this). This makes it very easy to see on a high level how things are related and what we are currently working on — without needing to add complex Trello addons or tooling.
- We use custom fields when we rely upon capabilities provided by an external partner (like our capabilities x will be enabled when our partner releases version y). Side note: when we started using Trello, custom fields were free, now I think you have to pay for it
- Big cover image on a card means challenge (see "Current Focus")
- We use a plugin for visualizing when we hit our WIP limits (Work in Process). We see our limits as guiding, not blocking.
Final thoughts
I hope you enjoyed the deep dive into our process and our board. We know we are far from perfect and have a long way to go, but by sharing this with you, I hope we both have an opportunity to learn and improve.
Thanks for reading.
