One of the key facets of effective software delivery is continuous improvement to team practices.
The reason I believe physical team walls are so effective in continuous team improvement is that they both reflect good team practices, and drive good team practices. That is, our wall both displays how we’re working, and improves how we work.
If your team is improving how you’re doing things then chances are your wall will look different to how it looked six months ago.
We’ve since made some improvements to the wall that has continued to improve our effectiveness as a team.
We work in quarterly planning cycles, fortnightly sprints towards our goals, and frequent software releases (once or twice a day typically).
The nice thing about our quarterly planning cycles is that we can neatly fit six sprints within a quarter (12 weeks).
Since the wall represents what we’re doing, and we have this quarterly focus, we thought it would be a good idea to represent the full quarter on our wall. This means our wall currently looks something like:
If you zoomed into a single sprint it looks like:
Some of the important aspects of the design include:
We put colour coded epics across the top of our board that roughly show when we plan to start each epic. These may not always start at the beginning of a sprint as each epic doesn’t always fit within a sprint and we don’t wait for a new sprint to start a new epic.
Task card colours match the epic to which they belong, except for white cards which are tasks unrelated to an epic – for example tech debt, or a production fix.
Each task card is exactly three columns wide – this is because we try to keep our cycle time, that is the time it takes to pick up a task and merge/release it, to about 3 work days, and each column is one work day. If we find a task is taking much longer than 3 work days it’s a good indication it hasn’t been broken down enough, if it’s much quicker than that we may be creating unnecessary overhead. The benefit of this is more consistent planning, and also effort tracking as we can see at a glance roughly how much effort an epic was by seeing the coloured tickets.
Tasks have a FE/BE label, a JIRA reference, a person who is working on it and one or two stickers representing status.
We continued our status dots – blue for in progress, a smaller yellow sticker to indicate in review, blue and yellow makes a green sticker which is complete. We also use red for blocked tasks, and have added a new sticker which is a purple/pink colour which a black star which indicates this is a tech debt related task.
We move the pink ribbon along each day so it shows us visually where we are at in the sprint/quarter.
We have rows for both team leave, and milestones such as when we enabled a new feature, and also public holidays and team events.
We continue to have our sprint goals and action items displayed clearly at the top of the wall so we can refer back to these during our daily stand up meeting during the sprint to check in on how we’re going.
One extra thing we’ve recently started doing which isn’t represented in the diagram above is when a sprint is complete we shift the cards to the bottom of the wall (in the same columns) so we have a clear future focus, whilst still having a historical view.
We’ve found continually improving our wall represents how our practices have improved and will continue to make improvements as we go. I have no idea how it will look in six months time.
How have you adapted a typical agile wall for your team? How different does it look today than six months ago?
After three and a half years of working by myself at home, it feels truly great to be working in a co-located cross-functional team again. My squad consists of four developers and myself, and I had forgotten how much I love being a paradev. I wear many hats every day in my job, which I love, and one of these hats is managing our iterations of work: our fortnightly sprints.
We follow lightweight agile software development practices but in the spirit of this our squad is empowered to experiment and adjust our techniques to delivery good quality software quickly.
We aim to work on items of work in small chunks and have these features being used by our customers as quickly as possible by releasing software at least daily to production.
Typically we’ve been using a simple physical agile story wall which is good when you’re working on small and fairly independent chunks of functionality, but we’ve found not all work fits into this style of working.
We recently had an initiative that involved lots of small tasks, but there were a lot inter-dependencies between the tasks – as we need to do data creation, migration, back end services migration and new front end development. Our standard agile story wall which looked like this was very bad at showing us what was dependent on what:
As a team we decided to experiment with using our agile story wall to map the dependencies we have between work and also to show when we’re able to release the various pieces of functionality. The two week sprints were less relevant as we release as soon as we can. We still have some pieces of independent work (eg. bug fixes and tech debt) which we kept tracking using the standard Kanban style columns under our main board:
This gave us instant benefits: the dependencies were not only very clear but elastic. We used a whiteboard marker to draw lines between tasks which meant as we discovered new or unnecessary dependencies we could quickly remove or re-arrange these lines. But we also quickly realized that in mapping our dependencies out this way we lost one key attribute of our information radiator: we couldn’t see the status of our pieces of work at quick glance which the standard status based wall gave us. Since we’re using a physical wall we can quickly adapt so we added some sticky dots to indicate status of individual cards: blue for in progress, a smaller yellow dot is in-review, and green for done since blue + yellow = green (I’m happy to take the credit for that). We also added red for blocked when we discovered we had our first blocked piece of work, and a legend in case the colours weren’t immediately obvious:
Once our 4 week initiative was over we found the dependency wall was so useful we’ve decided to continue using it for the main focus of each sprint, and continue using the standard status based columns for less critical things. We’ll continue to refine and iterate.
Having an old-fashioned physical agile story wall is powerful is a lot of ways, and one of the most powerful things about it is how easy it is to modify and adapt your wall to whatever suits you best at the time: we couldn’t have achieved what we did if we were using a digital board like JIRA or Trello.
Standard agile story walls are good for showing status of work, but are very weak at showing interdepencies between stories and tasks – the major software solutions suffer from this.
A software team being agile isn’t about just doing sprint planning, standups, a story wall and retrospectives from a textbook. It’s about delivering software rapidly in the best possible way for your team and your context – and continually experimenting and adjusting your ways of working is crucial to this.