Weeknotes #151

Focus and freedom

Team focus for this week has been about figuring out how to take away work they shouldn’t be doing so they have the space to do the work they should. They struggle with focus, feeling that they are responsible for everything that happens with their product and I need to help them become leaders who guide the business. The two areas of work I’m going to tackle first are support queries from customers and delivery management. These are things that are somewhat within our team’s control so they are quicker wins for freeing up time for the PM’s.

I had a good chat with one of the team about shifting roles to be more of a Delivery Manager. She said yes, as long as I could tell her what to do and when to do it. I replied that we could certainly agree on what she should be trying to achieve but that I would never tell her exactly what to do as I think we should be shaping roles to fit people, not the other way round. I want her to be able to use her strengths to achieve things rather than feeling like she’ll always be struggling against ways of working that don’t recognise her as an individual. Communicating can be done in lots of ways. If your a people-person (whatever that means) you might do it by talking to people, and if your an accurate-detail-oriented person then you might do it by providing information in a spreadsheet. Neither is wrong and both can achieve the same thing.

Next week I’m putting together a training budget to get my team to conferences and on training courses. This is part our ambition to show the Product team as experts and leaders in the business rather than order-takers for features. I still want to see if I can arrange a visit to the HMRC Product Team, and I’ve also been thinking about how we might be able to get knowledge and insight from the BSI Sector Teams in order to help us understand the wider market of Standards. I also want us to arrange customer visits soon. I know it’s a scary concept for some of the PM’s, and they’ve hinted at this with comments like, “but my customers are internal people who request changes to the product”. No, those are your stakeholders, your customers are the people that use your product to achieve something they value, and you need to understand what they want and why.

Who is responsible for the solution?

I spent some time thinking about how and why work is sized. There seems to be a weird organisational thing where if a piece of work is sized as small or medium it is considered not complex enough to need a Business Analyst to work on it, but if it’s sized large or extra large then it’s regarded as complex enough to need the support of a BA. The really weird thing is that Product has to pay IT for using their BA’s, even though IT do the sizing and we don’t get to decide whether a BA is required. This led me to thinking that if we sliced all of our work small enough it would never need BA support, we’d save money and deliver more more quickly. But that led me to uncovering the gap in how products are built and maintained which I think explains why it’s so hard to get anything done right; there is no solution design.

Solution design is implied, I think, but it’s never explicit. For small and medium work the assumption is that the solution design has previously been done before the work request was submitted. And for large and extra large work the assumption is that it will be done during the business analysis process, although again, those assumptions are never made explicit and the work of designing the solution to achieve the outcomes for the customer and not adversely affect current business is never done.

We have work request documents, high level business requirements documents and user acceptance documents, all of which describe the end state (often in different ways) but we have nothing to describe what is going to be built. Without a shared understanding of what to build and how it is going to impact other business processes, it’s no wonder things get delayed, built wrong, and increase the burden on UAT to reveal all those misunderstandings. The question I’m left with is who is responsible for solution design? It fits into the Development phase of our product management process, which is in the solution (rather than the problem) space, but I’m concerned that the PM’s will be the only ones with enough cross-functional nous to do it effectively, but really they should be focused in the problem space.

Using the process to design the process

Had a really good workshop with two of the team to decide how we want to set up Aha to reflect and support the new practices we’re going to be using. It was interesting to see the understanding of the how we want to change our practices grow during that two hours but most importantly we made decisions. That seems like it’s often a difficult thing to do. That needs to change. Product Managers might not be responsible for making decisions but they should be responsible for the pace of decision making.

Figuring out how to match our new process to Aha

As for making the change, we’re getting clearer about what it’ll look like. We’re using the Discover, Define, Develop, Deliver process discover, define, develop and deliver our Discover, Define, Develop, Deliver process. Part of that is about how a piece of work moves through those steps in Aha from being an Idea in the Discovery phase, being promoted to a Feature for the Definition phase, the Feature being prioritised on the Backlog for the Development phase, and then added to a Release for the Deliver phase. The other part is showing the team the tools, techniques, outputs and metrics from using the process and using Aha. There are lots of tightly held assumptions that ‘this is how we work’, that we’re going to unravel and challenge the PM’s to shift their focus from the development and delivery of features to the discovery and definition of opportunities. They are going to need to think bigger, and I’m going to need to put the things in place that let them do that.

When do you do your homework?

We’ve been doing user acceptance testing on the latest round of work. It has been haphazard at best, precisely the opposite of what good testing should be. We test based on our understanding of what we were expecting the results to be because of our familiarity and knowledge. Not a good way to test. All of the PM’s left their testing until the last day. This is behaviour that tells me that a) they don’t prioritise testing over other work, and b) they don’t really want to be testing. It’s like leaving your homework till Sunday night.

It’s another area of work I think we should take away from the PM’s but its going to be a bigger shift than removing support queries and delivery management, so it’s going to take a lot longer. And it’s not just a case of telling the QA team that they are now solely responsible for testing as the quality isn’t there yet. So, part of the shift needs to be building up the QA team to be able to test with more rigor and contextual understanding, and the even bigger part is nailing the solution design so that testing can be against the impact of the work not just does it technically do as expected.

Tweet of the week

My favourite tweet of the week was from Ben Holliday, Chief Design Officer at FutureGov. I’m a big believer in hustle and creative problem solving over blindly following procedures. I know the PM’s in my team do work this way sometimes, but it’s definitely a skill I want them to improve upon. I’d rather they were figuring things out by talking to people, scrawling on postit notes and trying new things than sitting on their own typing things into a spreadsheet.

Hustle