Invitation over infliction
This week we’ve been looking at mapping our existing applications into specified products and services, to have an initial idea around where we may want to go next from a product side in incrementally moving to new ways of working. Unfortunately as part of that some had misunderstood, and taken it as a need to also map people into new roles, based on what they do now, without much/any conversation with those impacted individuals.
After again being inspired by watching Jonathan Smart latest talk on Better Value Sooner Safer Happier, I had to explain around the need to invite rather than inflict change.
RIP Grumpy Cat
Trying to drag and drop humans into new roles just like how we move files on our devices is the classic example of inflicted, capital A/D, capital T, agile/digital transformation. This kind of approach lacks empathy, and is more than likely to result in limited success in adopting new ways of working. Inviting people to the change, be it through asking for their feedback, sowing the seed for maybe where we want to go but showing our own fallibility in admitting of not being sure ourselves is more likely to lead to success in the long run, as people feel a sense of involvement and ownership in the journey. The message seemed to land in the conversations we had, with us agreeing to slow down to focus on the product/service side, and taking a slower, incremental approach on the people side.
Product Management
Increasingly we’re having more and more discussions around Product Management and the importance that role is going to play in achieving positive outcomes for new ways of working. One of the first things that comes up is the difference between a Product Owner and Product Manager.
As I’ve mentioned before, Melissa Perri’s view of a Product Owner being a role on a Scrum team Vs. a Product Manager being a career is what we’re explaining to people. In addition to that, she gives a great overview here. Scrum has lots of stuff on the process/rules of Scrum and what a PO should do, but leaves a lot of stuff unanswered around knowing if you’re actually building the right thing or not. It’s precisely why we’re focusing on Product Manager as a role, as we want them to be able to prioritise work in particular from an outcome oriented perspective. I recall my days at Royal Mail when I worked with a Product Manager called Anne, who was one the best PM’s I worked with. She showed me what Product Management really was all about, not just prioritising work but also pouring over customer data and obsessing over outcomes rather than individual features. This lead to developing some of the most used products on the platform, as well as creating new revenue streams for the organisation. This mindset is what makes a great Product Manager.
FlowViz
This week I finally managed to get FlowViz into the Azure DevOps Marketplace through a collaboration with Agile Extensions.
Whilst the listing only redirects people to my GitHub page, it’s nice to have something out there and see if it’s going to help people in the teams they work with. I purposely made it free due to me wishing I had something like this early on in my Agile journey-hopefully it will help others avoiding making the same mistakes I made/measure things a bit more useful!
Next Week
Next week we have our team sprint review and retro — a good time for us to reflect on how our adoption of new ways of working are going and a check in on our OKRs to see how we’re performing so far this quarter, changing direction if we need to.