The Hello World project is a well known time honored tradition in programming and I thought of attempting something similar but specifically focused on product management, let’s call it “hello world for product managers!”
Over a series of posts in coming weeks, I’m planning to share learnings around following topics, some of them are first hand experiences while other topics that I really enjoyed learning from others:
Product innovation using Business Model Canvas
Decision Making, Negotiations
Collaboration in product teams
Product life cycle
Build – Measure – Learn : Without spending a fortune
This week I’ve been focusing on “inspecting” the agile practices for a team. The product owner of this team has recently relocated to a new office setting up our very first “Distributed Agile” team. Without equipping the team with the right tools/processes before making this change, clearly we set ourselves for driving backwards and losing all the agile momentum built up so far.
As part of my assessment, the very first and probably the easiest forum to get a team heartbeat, I started attending daily scrums. Coming from ThoughtWorks where almost all our projects operate in distributed agile fashion, I was hoping to get a similar picture for every scrum ceremony but quite frankly it was a major disappointment. Standup or daily scrum was done everyday without the product owner being there, scrum master was relatively new to the organization so it was hard for him to push people to be punctual with the timing. Quality of the updates from the team was far from ideal with anyone/everyone just sharing what they worked on yesterday and what they’re planning to work on today. There was no mention of “blockers” by anyone in the team. Not a single person tied the update with any story/epic. This made me dive into their scrum board to understand how so called “user stories” are written.
There goes another chapter of disappointment. There were no user stories on the scrum board, rather the board was occupied with so many of the “engineering tasks” which didn’t clearly define the business objectives the team was trying to solve. The team had even made it worse by writing the tasks themselves during sprint planning meeting (as the product owner was in US, supposedly more focused on customer facing initiatives). As they’re now writing engineering tasks instead of user stories, obviously estimation is going to be a challenge. To make estimations easier team actually started using number of days as the measure followed on fibonacci series, meaning 1 day effort eqauls 1 point and 3 days effort will be 3 points story and so on. This made things worse as the team started deviating from the “complexity of the task” towards “how long will it take to fix” mindset. Obviously my next step is to attend the sprint planning meeting. The findings continued and pretty much resonated with most of the above.
What was interesting and goes back to the purpose of writing this post was something more interesting than these “executional mistakes”. While interacting with the scrum master and a senior member of the team, I discovered how it all happened and nobody felt the difference within the team. The senior member of the team mentioned, we are doing all the key ceremonies but just not calling them explicitly the scrum ceremonies. He felt that it’s all about just using the “Agile language” which the team isn’t using, making my assessment so bad. That’s when I had to start acting as a “coach” and not just as an “agile trainer”. After soothing their temper with few mins of random chitchat, I started asking them “pointed” questions like “How do you know that the team is on track for hitting the business objective”, “Tell me what problem we’re trying to solve in this project”, “How do you judge the team morale/energy levels”, “What are some of the things we should start/stop doing to make things better” and so on. As expected, they couldn’t answer most of these questions clearly with supporting data points. That’s when I started re-iterating the “purpose” of the 5 key sprint ceremonies. It was quite evident that at the end of our discussion they were totally bought into following all the key ceremonies going forward. The senior member also mentioned that now he clearly understands why I always say it’s not about following the agile language but rather understanding why we want to be agile helps us get better at it.
I conducted the “Prune the product tree” workshop with a group of Product Managers at one of our client. The prezi was quite light weight, mostly used as conversation placeholder and to have a format to the whole workshop.
PS – Embedding the prezi into wordpress – #win, struggled with it for quite some time.
Recently I happened to try out a new prioritisation technique at one of the clients and the group found it really helpful. I am going to call it – “DFD prioritisation”.
Most of the product management teams in agile environment are used to hearing MVP, MOSCOW prioritisation techniques but often find it difficult to categorise different epics/stories in “Must, Should, Could or Would have” categories.
In an attempt to ease this I suggested using “DFD prioritisation” where DFD stands for –
Delighters – Features which will delight the customers.
Frills – Features which customers will like but can live without for the first release.
Disgustors – Features which customers will absolutely hate.
I used it in conjunction with the popular “Prune the product tree” exercise by Innovation Games. Instead of placing features on leaves and branches, we used the DFD level of priorities on the product tree. Teams found it quite easy to classify the features into one of the DFD categories! Done!
Next time, I’m going to use big posters with DFD sections on the product tree!
“Figure out the why’s early on” – Now a days most of the leaders are trying to get their teams “agile” although very few clearly have an objective behind being “agile”. So that’s exactly what we figured out in early days of the transformation, help the management clearly articulate the benefits they hope to acquire after being agile.
“Keep calm, plan baby steps” – You’re not just trying to introduce new processes, tools but also changing the way people are used to getting certain things done. Plan baby steps of introducing change, keep your teams motivated and don’t forget to highlight the “small wins”.
“Win trust from the people than from management” – If you win trust from people on the ground, it’s often easier to propagate the change more than giving them hours of gyan in trainings and meeting rooms.
Stay tuned for the next set of ingredients for the perfect transformation secret sauce!