After my last blog I received a lovely email from a reader (hi Mark!). He told me he would be really interested to know more about how we manage our product backlog and customer expectations, especially in an environment with multi-disciplined teams, multiple customers and competing priorities. Mark also mentioned he wanted to know how we successfully manage customer expectations RE delivery time, quality and cost.
All interesting questions and quite difficult to answer!
The Codeweavers way of working
At Codeweavers we have a very unique set up. At our core, we are driven by our SaaS platform with multiple ‘out of the box’ products such as our finance calculators, proposal forms and our Showroom POS system. We’re always trying to improve these products and innovate with new ones, but we also do a lot of bespoke work for our larger customers (high-end manufacturers and finance lenders), much like an ‘agency’.
We have a standard ‘Kanban’ approach to working across the company; this involves breaking work down into as small deliverables and we call these MMFs – Minimum Marketable Features. The goal is for teams is to be able to pull these MMFs from the company backlog and deliver work iteratively, efficiently and with high quality. This has always worked extremely well for Codeweavers, especially using physical boards when in the start-up stage. However, our teams and workload are rapidly increasing, so we’re learning some big lessons about scaling up and digitising our Kanbans and Backlog (duplication much?!). Codeweavers Delivery Manager, Head of Product and Directors normally work together to decide on the priorities and they feed work into the multi-disciplined teams on a monthly basis (sometimes more often). Work is only fed into a team’s backlog if we have already received a purchase order.
All of this makes my position as a ‘Product Owner’ an interesting one! Although I have a couple of products I ‘own’ such as our Part Exchange and Stock Locator tools, I am also constantly juggling the pre-investigation and delivery of small pieces of bespoke work, and some larger projects which may be entirely bespoke or platform improvement work. So my role is not really a clear-cut Product Owner; in fact, that title generally only applies to 10-15% of my role. The rest would be mainly project/delivery management, some business analysis and a touch of account management.
Not every product owner at Codeweavers will be in the same position as me. Some are entirely dedicated to large scale projects, and some are concentrating on purely improving our current product set. For me and Team Titan (the multidisciplinary team I’m assigned to), it’s a mixed bag completely, and we’re always experimenting and working together to find ways to keep quality at its highest and still get work out of the door as efficiently as possible.
Codeweavers currently has a large company backlog that feeds into about 6 teams in total and each team has 1 or more Product Owners driving work. Some specialise in areas such as calculations and proposal integrations; some work only on products, some on large projects; and Team Titan works on a mixture. I am the only Product Owner in Team Titan (currently) and we have 3 front end developers, 6 backend developers and a Quality Analyst (QA). Developers mostly work in pairs, and our QA will work across the team; where they are needed most is usually decided at a team stand up.
Right now, we have a constant stream of work from one of our large manufacturer clients, we’re working on a new payment search/stock locator product, and we have many varied, smaller pieces of work for customers and internal stakeholders. Typically Product Owners will only be looking at their team backlog for the next 4-6 weeks with the help of the Delivery Manager, and the account managers will be looking at future work with our Head of Product.
Managing this backlog, prioritising work and setting customer expectations is a struggle, especially when our own business priorities and customer expectations clash!
In our team, we were also finding that we can sometimes take work out of the backlog, only to find it’s not really ‘ready to start’ and would in fact require days, and sometimes weeks, of pre-investigation or ‘discovery’ and conversations internally and with the customer. This can cause a lot of back and forth, and a lot of lost development time.
This was a bit of a unique issue for Team Titan as we’re the only team not on one large project or product. We were getting all sorts of work that hadn’t even touched us until it landed in the backlog. We knew we had to start working a little differently to the standard Kanban approach at Codeweavers, so we started doing some trial and error with fitting in investigation work around actual development work, and this is how we now do things:
This is primarily still done using physical boards.
I have a digital backlog in JIRA (a popular tool for Agile teams) which is pulled from the company backlog, but we’re not at a stage where we can visualise investigations here, so we keep them in the backlog stream until ready to start.
I’ll update the physical and digital board on a (mostly) daily basis, and I also encourage the rest of the team to make updates when they know a piece of work has moved on so there is always a clear picture of what the team is working on.
We have a daily operations stand-up which consists of Product Owners, Account Managers, Head of Product, Delivery Manager, a Director, Developers and Head of QA. It is here we keep in touch on a daily basis about current work, company priorities, blockers and any bigger support issues. We then have a Team Titan stand up straight after so I can communicate any changes or news to the team and they can let me know about any blockers (or achievements!). Team Titan have a second stand up after lunch too, as circumstances can change quickly, a 10-minute catch up can make all the difference to our delivery!
If the team finds we’re not delivering much, or that we have too much work to do in investigation and not enough in ‘ready to start’ then we will run ad hoc planning sessions, or spend some time blasting through investigations before starting any new development. The stand-ups help us to identify when these sessions are needed. We avoid unnecessary meetings as much as possible, but we do have a weekly team retro that we all find an extremely useful exercise in reflection and team building. We’ll also retro certain projects if they went particularly well (or not so well…).
When it comes to speaking to customers and managing their expectations I have different approaches. For one large manufacturer, I have a daily stand up call (yet another!) with them and we talk through support tickets, current and future development and any other business. I find honesty is the best policy! If I’m going to have a problem delivering something when I said we would, the earlier I tell them, the better. We all discover problems we could not possibly have seen until we come to develop or test what we’ve done, and sometimes the fix takes a lot longer than we’d like, but it’s better for all of us if we have quality over speed. Luckily, they understand this, and we have a really good working relationship.
I am also quite firm in never promising a date for delivery! Once an item of work is in my backlog, I’m usually taking over customer conversations from an account manager, and I will work with that person to communicate honestly and fairly to each customer about what they can expect. By the time it’s in my backlog for the team, this usually means they’ve been told they can have their work done that month. Due to the nature of our way of working an estimated delivery will be a lot looser such as ‘the last week of March’, but we will always aim to get things done sooner. I prefer to give worst case scenarios (within reason, I’m not a doomsayer!) and then surprise people with a quicker delivery than they’d hoped for!
For larger projects, I will always ensure I give the customer an overview of how the team works and how we can deliver best with the customers involvement (especially with regards to testing on time!) and I may have a weekly, bi-weekly, or even daily stand-up with the customer until we have successfully delivered.
I hope this goes some way to answering Mark’s question about backlogs, customer expectations and competing priorities at Codeweavers. It’s important to note that this is really just a case study of one team in our company, and it may not help you at all. Agile delivery has to be tailored to each organisation, and even at a team level, in their own unique way because there definitely isn’t a one size fits all! Hopefully, this blog gives some ideas though.
My key points for successful backlog management and setting customers’ expectations are;