Monthly Archives: September 2013
Moving to Agile or Scrum introduces a lot of change and that can lead to conflicts in an organization. There are a number of key factors to consider when managing those conflicts so that they are resolved quickly and collaboratively.
1. Level Set on the Goals
Here is a common scenario that we see in Agile. The development team is frustrated because the Product Owner doesn’t have all of the answers and the Product Owner is frustrated that the developers ask for everything before they will work on anything. Does this sound familiar? In this scenario, we need to get back to basics and remember our main goal. We want to deliver working software that adds business value as quickly as possible. Both the development teams and the Product Owner share this goal and we need to remember that. No product owner is knowingly going to withhold information about the marketplace or the product and no development team ever plans to write crummy code. We all want the same thing, we just have different roles in how to achieve that. So if you find yourself at a stalemate, think back to the original goal and realign on that. It can really help to get everyone back on the same page.
There are a handful of meetings that the Scrum Methodology includes as part of the cadence and this blog addresses each one and why they are important.
The first meeting is called Sprint Planning and this is a two-part meeting. The first part is where the Product Owner has the opportunity to clarify and answer questions regarding the highest priority items in the backlog. The Scrum team and Product Owner then set the Sprint Goal by deciding which stories will be included in this Sprint. This is sometimes referred to as the “What” part of the meeting when we determine what we are going to build. The second part of the meeting is for the Scrum team to discuss the individual tasks that will be required to execute the stories and any technical considerations or dependencies. This is referred to as the “How” part of the meeting when the Scrum team decides how they are going to accomplish the what. The team also usually picks the tasks that each individual is going to work on and estimates the amount of time that each task will take to complete.
There is a concept in Agile called Fist of Five. The notion is simple – when you come to a decision point and you need to make sure everyone is on board, you ‘vote’. Agile is all about transparency and Fist of Five is one method to reinforce it.
We do it like the game “Rock, Paper, Scissors” where everyone shows their vote at the same time. One – Two – Three – Shoot. In theory, this is supposed to keep people from being influenced by their neighbor, but honestly, we think it is just more fun.
The voting works as follows: A team member will propose a direction forward and the team will demonstrate their acceptance by holding up their hand with the number of fingers that corresponds with their level of support.
5 fingers = I am all in. I completely agree.
4 fingers = I buy into the option and I will support it.
3 fingers = I may have some reservations, but I can support the decision and move forward.
2 fingers = I have reservations and I cannot support this decision without further discussion and clarification.
1 finger = I cannot support this direction. I disagree.
Product Management is an unknown discipline to many people and it is so necessary that we must spread the word. There are visionaries and entrepreneurs out there who are coming up with wonderful ideas and then spending precious time and resources pursuing these ideas without considering some basic information first. This blog is designed to showcase a handful of questions that Product Management asks before you commit to building the “next big thing.”
1. What is the business problem you are trying to solve?
This question is usually answered by most idea people. They see a pain point and they want to address it. Awesome. As long as you can clearly articulate what you are trying to achieve, you are headed in the right directio
2. Who are we trying to solve it for?
Here is where things start to get a bit murky. Do you want to cross-sell this new product to existing customers? Or do you want to attract new customers? Do you see this product being purchased by the masses? Exactly what you build, the complexity of the product and the required feature set will all be shaped by knowing exactly who your target market is. And if you say “all consumers in the US,” you might need some refinement to your strategy.