Tag Archives: consulting

“Hello world” for Product Management

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:

  1. Product innovation using Business Model Canvas
  2. Decision Making, Negotiations
  3. Pricing
  4. Collaboration in product teams
  5. Product life cycle
  6. Build – Measure – Learn : Without spending a fortune

Stay tuned!


It’s not just about the language!

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.

“Transformation secret sauce – Part 1”

“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!