This is the story of our product development process at Streamtime. Told from my perspective, an ex-technical support manager who dove into the product team a year into the life of the ‘new’ Streamtime product.
I packed up my desk, cleared my draws and started the long walk down the hallway. Past the toilet, and into the back section of our office to where the developers were bunkered. I was leaving behind my natural light filled, Sydney harbour view desk surrounded by the team much less accustomed to wearing headphones, to sit in the dragons den.
‘Product Driver’ was my new title (can you tell we don’t do job titles?) – in short, helping organise our development team’s work. Welcome to the world of agile methodology, scrum framework, backlogs, sprints, velocity, burn downs, grooming, estimating, user stories, bugs, tasks, Jira, Sprintly…
As a company, it wasn’t the easiest of times. We had released a new product – replacing our previous (Saas) product which we were no longer selling. Traction for a brand new offering that was initially light in functionality and had also taken a dramatically different approach was extremely difficult.
Fast forward a year and a bit, total user numbers are up and increasing, as is annualised revenue. Our product has grown and we are catching the eye of different industries as well as some existing clients eager to take a progressive leap. We are currently in sprint 50 (two weeks each) with every effort made to balance product vision with feature requests and making the difficult calls on requests that don’t fit our ethos.
The entire company has worked extremely hard to get those numbers tracking in the right direction – truly a team effort. As a product team we have improved in many areas, but I’ve come to realise it’s an ongoing process of adapting to the unique challenges each individual sprint throws up rather than a strict set of rules that can be followed repeatedly (agile manifesto value – ‘Responding to change over following a plan’).
In this and future posts, I want to highlight some learnings – both from a personal and company/team perspective. This particular post will scratch the surface of a few problems faced in from my first day.
So, back to my long walk to the ‘bullpen’.
It took less than an hour to realise the speed at which this team operated was another level – problems were discovered, discussed and solved in less time than it would take to read some support questions. Not only did things move quickly, but the detail in each discussion was so crucial that not concentrating for a split second could mean a key point was missed. Missing detail would then be left out of the task, leading to something being built incorrectly and unable to be released.
The pace took me by surprise and made me consciously rethink my initial swagger walking down that hallway. Nagging questions filled my head. Was I the right person for the job? Was I up for the challenge? Could I step up and get the job done? Is this the kind of work that I wanted to be doing?
Realising I had a lot to learn, I decided to focus. I shut my mouth, listened, watched and began to get a clearer picture of the key challenges the team were facing. Once they became clear, I started to research.
Challenge 1 – Decision Making
The product owner (& founder of the company) Aaron is based in NZ, developers (3), designer and myself are all based in Sydney. The physical location, in this case, was slowing down decision making. Questions come up constantly during the development stage and it was not perfectly clear who those questions should be directed towards. Long discussions were happening in the Sydney office before Aaron was involved – then the background and discussion to date would have to be had all over again with Aaron.
What we did
We focused on standups which helped in many ways – not only decision making. We started recording our standups and posting them in slack for Aaron to know what area’s the team were working on that day. Making sure everyone is aware of what is being worked on seems obvious, but with so much going on it’s easy to miss. The benefits are often indirect – thoughts someone had had previously on an area but not communicated are surfaced, it gives everyone the starting point for decision making discussions and also makes everyone more attuned to anything they see/hear that might be relevant.
We didn’t stop the discussions happening in the Sydney office, but we did shorten them. The goal was to quickly understand the issue, come up with a couple of best solutions and get Aaron on a video call quickly for a final decision to be made. Continuing the conversation via chat is an easy trap to fall into – but there is a point where everyone has to be on a call to ensure there is no misunderstanding & a solution can be found. On the rare occasion we can’t do it right away, we schedule a meeting, park the current task and work on alternative tasks.
Challenge 2 – Sprints
We had a sprint process and the team were getting releases done but it felt inefficient. With no way of measuring the current sprint against previous, we were unable to identify highly successful sprints so we could try to replicate them.
What we did
This was not a unique/new problem in the software world, so I did my research. I bought and read ‘Succeeding with Agile’ by Mike Cohn. It became my bible and guided the ‘tweaks’ we implemented.
- We moved to Jira, so we could be more specific in estimating our tasks.
- Improved the detail in the Jira cards we were creating. Tried to follow user story formats and added conditions of satisfaction.
- Mike Cohn talks of the importance of constantly discussing requirements – which we do a lot of – designs are printed and put up on the wall for discussion. Documentation is created to record the important decisions made in those discussions.
- We reduced the number of tasks we added into a sprint. We only include 70% of our full two week story point capacity to account for the inevitable emergent requirements, bugs or scope creep.
- To groom/prioritise the existing backlog items we used a ‘high impact low effort matrix’. Prioritising ‘easy wins’ in amongst the bigger ticket features.
Challenge 3 – Communication
Improving communication within the product team and between the product team and organisation was a priority. Both require continued, significant effort to maintain but are vital for so many reasons. Within the team, communicating what you are working on, blockers/issues and discussing various options for solutions all help efficiency.
Communicating to the rest of the organisation what the product team are working on currently or plan to soon, allows the team to set customer expectations. Giving the team knowledge of future focus area’s allows them to identify & share internally any relevant conversations had with clients and of course making sure our team have an understanding of soon to be released functionality is key.
What we did
Within the product team, the main thing was to ensure that we meet as often as we can:
- Daily standups – as above, designed to keep everyone on the same page with current WIP, recently completed and blockers.
- Tech reviews of final designs earmarked for next release – meeting to discuss anything that is unclear, catch bits that may not have been considered, decide on the best technical solution etc.
- Retrospectives to discuss what was successful and not so successful in each sprint – at the end of each sprint. Help us identify what things we need to do more of or avoid in our sprint process.
- Planning meetings – product owner and I meet to identify backlog items ready to be included in the next sprint.
Within the organisation – with so many moving parts to a sprint, this is not an easy task.
- An internal slack channel was created – ‘release notes’ to summarise what was included in each release.
- Depending on the release, explainer videos/knowledge base articles are created and shared internally before release.
- Before a release, the version is made available internally to our entire team. Each team member has the opportunity to use the new functionality and test the changes.
- A broader public ‘roadmap’ is available here. A private version exists sourced from customer conversations, product decisions and industry challenges. This provides our clients and team with information on our future priorities.
Many of the tweaks we implemented were not overly complex. The difficulty is having the discipline to continue following as many as possible, every single day, every single sprint. It’s no coincidence though that the sprints where we are disciplined run far smoother.
