To keep your codebase clean, it helps to have a separation of concerns. But how do we do this for Heroku applications?
As tech people - we quickly flock to digital tools to manage our workflow and processes. Although an Agile digital task tracker is a great start - at Kogan.com our Physical wall has had huge impact in communicating work in process and priority to our stakeholders - find out why and how you can transform your stakeholder communication.
There is nothing that creates visibility, collaboration and flexibility of process in a team like a physical wall.
It allows you to show what is currently being worked on and whois owning it, where the bottlenecks are in your process, how much and what is in the backlog and the list goes on.
It provides an awesome mechanism to trigger and facilitate conversations around and provides a visual que that often speaks a thousand words.
But as much I advocated for physical walls to manage a team they are not without their limitations.
They lack the detail and the reporting aspect that you really need an online tool to fulfill and that's why...
Like many agile based teams we regularly run retrospectives to gauge as a team how we are going and think of what and how to improve.
We have one every two weeks, they are time boxed to one hour and are held standing up (like we do for nearly all of our team meetings).
We have the typical ‘happy’ column, a ‘sad’ column and a ‘puzzling’ column. Everyone brainstorms on post-its, we group it together and vote on what we would like to discuss.
The team is prompted by being next to our wall and running through some of the achievements/big events in the past two weeks.
I ask probing questions such as:
- What has slowed down your progress?
- What has enabled you?
- From when you pick up a story to when you deploy it to production, what obstacles do you have?
- What areas have been inefficient and where is there unnecessary work or rework?
There is one key part that distinguishes a productive retrospective from a time waster - the actions and improvements that are an output of the retro.
One thing that is tempting is to discuss the particular details of an issue that has just occurred - which can often turn into a bit of a whinge and sometimes even a blame game (especially if the people involved are not present at the retro). Then a tactical action is thought of to address the latest symptom and the team moves on to the next highest voted item.
It is far more valuable for the team to discuss the patterns and root cause of the issue.
To do this, the team should discuss what process was followed and give other examples of that process in play. This is to remove the emotion and raise it up to a more high level discussion about repeatable systemic issues.
Once we understand the root cause we explore what is within our control to improve. That way, when we begin to think of actions to improve the situation we are thinking of changes/tweaks to our process rather than a quick fix or bandaid.
Then, once we have an action to improve our process, we run through a few hypothetical situations to ensure we have a shared understanding of what our new improvement looks like. We’ll often look at a few tasks in our backlog to give us some examples and we run through how things will play out with our new improvement.
The next retrospective the first thing we discuss are our actions from the last retro:
- Has the action been implemented? if not, why not?
- Is the issue still occurring? if yes, why?
- Did the action improve the issue? if not, why not?
By beginning our retrospective with the previously agreed actions, it reinforces to the team the purpose of our retrospectives, which is, to share examples of our teams anchors and engines, to discuss their root cause and to action improvements to our process.