Technical Product Owner

June 2, 2009

So here’s the problem: Some teams have stories that are very “technical” in nature. By technical I mean that these stories are usually development oriented (in language, and in subject matter) and they are hard to relate to direct customer value. Often these stories are related to maintenance activities that have a strong perceived need to be done by various stakeholders, but are not explicitly requested by our external customers. Some examples include:

  1. Stories requested by operations
  2. Stories that have to do with infrastructure improvements
  3. Stories related to technical debt

In some cases product owners have a real problem working with these stories. They complain that the stories refer to technologies or acronyms that they don’t understand. They maintain that they are a customer advocate and don’t care what the details are – just fix it. They don’t know how to judge when these stories are done.

To address this problem we have created a sub-category of product owner that we call a “technical” product owner. If you are starting to feel a bit squeamish at this point, I don’t blame you one bit. So who is a technical product owner? In this case it is usually the development lead for the team – or perhaps a director of development.

The solution is a well intentioned one, but there are consequences. The problems with using a “technical product owner” that I see in practice:

  1. The technical PO has no connection with the rest of the Product Management/Business/Customer organization. This basically sets the team up to operate without having to deliver value that the rest of the organization recognizes. It seems to aggravate silos within an organization.
  2. The Product Management (PO) team gets to ignore important decisions regarding the maintenance and upkeep of business systems. When you buy the car, you need to be responsible for it’s upkeep. All too often I know PO’s who refuse to address technical debt when it is brought to them. Instead they prioritize new features higher – sooner or later it comes back to haunt them.
  3. Teams get out of the habit of working with user stories that customers can relate too. Or they take perfectly good user stories and break them down into “technical stories”. There are all sorts of reasons this happens to teams – but we don’t want to codify the practice by creating a special “technical PO”.
  4. It can reflect an organization’s unwillingness to organize projects that are aligned across the organization rather than within technical silos.

Personally, I think that we should be able to put all stories – regardless of where they originate into terms that anyone can understand. Failure to do that may lead you down a path that leads to the “Technical Product Owner”. Watch out.


Story Completion and Acceptance

June 5, 2008

In our last sprint retrospective we were not able to complete nearly 50% of the stories in our sprint. What was up with that? The last day before the end of the sprint, everything was still in progress (say 80%) but nothing was done. We talked about it in our retrospective. Why was this happening?

Lots of reasons:

  • The stories as they are broken down are typically taken on by only one person. Aside from any distractions, that person is focused on one and only one thing for that sprint – completing that story. Some people are UI focused, and generally, they get the UI stories. Other people have experience in certain components, and strangely enough, they pull those stories matching their expertise. So the specialization of individuals on the team plays an important role in how stories are completed by the team.
  • Furthermore, stories that are written in a way that cater to specialization further aggravate the problem. For example, stories really shouldn’t be broken down into UI, backend and DB layers. To do so is to create a story that can ONLY be accomplished by a specialist. Theoretically, our stories should require everyone’s involvement. So in essence, often times we are guilty of creating stories that can only be accomplished by a specialist. Each specialist on the team pulls a story that they have expertise in. Guess what inevitably happens? We end up with one story per team member per sprint.
  • Independently, each team member works as hard as they can to finish the story by the end of the sprint. As a whole, no stories are completed until the last day of the sprint.

Does this sound like what might be happening to your team? I assure you, it is not uncommon. Teams I work with do it all the time. Even the really experienced ones if they aren’t paying attention.

So how do we avoid this? Here are a few ideas:

1)      Try to write stories that reflect implementation of multiple skills (vertical slices through the system). Try not to break the stories down when you are in sprint planning.

2)      Agree as a team on how you are going to manage this. If your team feels that they are falling into the pattern I outline above, what are you going to do to change it? Focus on one or two stories each day? I know a team that did this very well. They would have what they called a “tactical” meeting each morning after the standup. In the tactical meeting they would work out exactly who was working on what. It forced a certain discipline on the team. Another idea is to only allow stories to be pulled by pairs of people. This will focus more resources on each story. Note, this is not pair programming – it’s working together. Another idea: If you have 8 stories only allow the team to pull two at  a time, and don’t pull the next two until the first two are done.

3)      Specialization is always the bogeyman in my experience. Nobody wants to volunteer to be anything other than an expert. Time pressure plays a role here too. “We don’t have time to flail about learning new things.” Give it to the experts. You are going to have to fight this. Reward people for taking on new stories that are not in their realm of expertise. Don’t give in to time pressure – you will be able to make up later the time you lose now. Slow down to go faster. It’s counter intuitive, but it works. Take much more of a “learning” mindset.  This is a learning process, If we ignore these learning opportunities, we will hurt ourselves in the long run.

I’m sure there are many other good ideas you can try. That’s what we’re doing – assessing where we are at and trying something different. There is one note that I think is important to make: If you are successfully delivering 100% of your stories each sprint, then perhaps you don’t need to worry about whether you finish them one at a time or not. In that case, completing stories is probably not your biggest problem. If I had a team that successfully completed their stories every sprint, and they didn’t show any progress until the last day, I would leave it alone. That’s right. I wouldn’t worry about it. All that really matters is that we deliver high quality product every sprint. If a team can do that, I’m not going to try to micromanage how they do it. Keep in mind that it’s a balancing act, and that we are ultimately not trying to create pretty graphs, but rather to satisfy our customer’s needs.


What is “Swarming?”

December 3, 2007

The term is derived from the behavior of insects in nature. The classic example of this behavior is a beehive when it reaches a critical mass. The workers will grow a new queen, and then the hive will split and a swarm will form that will leave the hive and seek out a location for a new hive. Perhaps the most astonishing thing is the fact that there is no one individual controlling the actions of the hive. There is no controller, no authority, no coordinating influence. Sounds kind of Agile.

These characteristics of “swarming” in the insect world are very similar to the kind of behavior that we are trying to foster within Agile teams. We want the entire team to focus on one and only one story at a time.

We want to use simple rules. We want to allow the team to self organize.

However, swarming is a relatively new pattern to emerge in the software world, and there has been a lot of misunderstanding and resistance to the notion of swarming. The idea of having the entire team focused exclusively on the same story is very hard for some people to swallow. The key is to create the right environment to support swarming activity.

If you are going to practice the swarming you need to make sure the following conditions hold true for your team:

  1. There is a definition of done that enables the involvement of the entire team
  2. The scope of the story is non-trivial
  3. A Set based decision making model is used

Often the argument that I hear is that a given story simply doesn’t require the involvement of everyone on the team. However, the more I thought about it, the more I realized that this probably isn’t really true very often. If we look at the definition of done for a team, we fine that there are activities from virtually every team specialization that are required to get a story into “potentially shippable” form. There needs to be a definition of done that enables the involvement of the entire team. Think about it – what activities need to be done for each story? Can we leave out QA? Documentation? Analysis? Design?

Someone once argued that it doesn’t make any sense to build a car 1 tire at a time. I have to agree, but I must also maintain that the challenge must be equal to the resources of the team. We should scale the stories to the appropriate size. The scope of the story must be non-trivial. Instead of building one wheel at at time, perhaps we should change the story to implementing the braking system? Perhaps the team should be implementing the suspension? The drive train? The story has to be scoped large enough that it allows the participation of more than one team member.

We also have to realize that swarming opens up some opportunities that we might not have using more conventional team organizational patterns. A Set based decision making model can be used. If the entire team is focused on the same problem, then we can also have them explore multiple solutions to the problem. This can lead to enhanced learning by the team, and allows them to explore alternatives more fully before making a commitment to an implementation or technology.

So, if you want to explore your busy inner bee, you need to create the right environmental conditions to support the swarming behavior:

  1. There is a definition of done that enables the involvement of the entire team
  2. The scope of the story is non-trivial
  3. A Set based decision making model is used

Given these conditions, the swarming pattern represents an exciting opportunity for us to explore a new way of understanding how we collaborate within our teams.