Tag Archives: teamwork
When it comes to implementing Agile, managers who are used to a “Command and Control” environment are going to be very uncomfortable. Now, let’s be honest, Command and Control managers are not all bad. They typically feel a high degree of accountability and that is a great thing. They feel like their neck is on the line so they want actions to be done as they command so that they can deliver. But what they fail to benefit from is the wisdom of the team.
The Power of the Team
Think about your team or colleagues. Who has long tenure and has ‘been there, done that’? Who is a relative new hire who may have relevant experiences from a previous employer? Who has worked in several different departments? Who has worked in several different roles? Each of these unique traits means that an employee might bring a unique perspective that the manager would benefit from, if they were willing to listen. Albert Einstein has famously said “we cannot solve our problems with the same thinking that we used when we created them.” Our employees have great ideas and many welcome the opportunity to creatively solve the problems of the business.
Members of management – manager, director, VP, whatever – should present the team with the problem or opportunity and let them ‘self organize’ to determine how they will solve the problem with teamwork.
I went to a meeting last week and we were discussing how to measure a Product Owner. The concept is completely understandable, but there was something about the meeting that didn’t sit well with me so I am devoting this blog to trying articulate my concerns and things that I think need to be considered.
The premise is sound – how do you know if the Product Owner is leading you down the right path? What if you build the wrong thing? And how can you assess their mis-direction before precious time and resources are spent?
That is a 100% valid question and one that we should certainly spend time and thought to resolve. The idea that there are ratio-driven metrics to measure the PO’s performance, though, seems counter-productive.
First, I think Product Owners have a very difficult job and I think very few people are naturally great Product Owners, if you go by the broad definition. Product Owners are supposed to understand the market place, stay on top of the competition, interview current and prospective clients, and break down all of that data into meaningful features that will be delivered in order to drive the most business value. They are also supposed to be experts at writing user stories, adding acceptance criteria, understanding at least some level of the technical details associated with the application, and they need to be decisive, informed and immediately available for the Scrum Team. That is a tall order. In fact, I recommend splitting the Product Owner’s responsibilities between the Product Owner and a Product Manager, as I referenced in a previous blog.