Product Owner vs Product Manager


Based on a recent post on yahoo forums, seems like there may still be confusion out there as to what the differences are between these two roles. Questions like, is there overlap? can the Product Manager take on the responsibilities of the Product Owner? what are the specific requirements for either role? pop up all the time.

There was a really good discussion on the Scrum Development Yahoo group on this topic and some really good points were made. So I’ll try to distill this for you here and of course put my own twist on this.

I think that the founders of Scrum purposely chose a different title for a reason. They could have easily just kept the title the same. But I think there was good reason for this. And that is that the PO has a specific set of duties in the Scrum role.

How do their roles differ?

First and foremost is that the PO drives the priorities for the development team. This is done via the Product Backlog as a vehicle for communicating priorities. Essentially, a company has a certain available capacity to turn requirements into working functioning code. How that capacity is used up is completely in the hands of the PO.

In order for the PO to do this, the PO needs to understand the bigger picture. Whether or not the PO distills this information from other roles or whether he has to get this information himself depends on the company.

Based on his/her understanding of the bigger picture, there are some additional specific duties that the PO must perform (not necessarily defined anywhere):

1. Articulate the product vision to the team
2. Define the goals at the beginning of every sprint
3. Tell the story behind each user story so that the development team understands what is required. So the PO must understand the end user requirements.
4. Define or help define the user story acceptance criteria so the team knows when they are DONE
5. Be able to prioritize the stories and be able to negotiate/collaborate on priorities with the team. Negotiate priorities occurs when after taking the top priorities off the backlog; there may be some remaining capacity that the next highest priority story won’t fit in to. So in those cases, a lower priority feature could be picked.
6. Must be available at all inspect and adapt points to answer questions and help guide the team empirically

Product Managers on the other hand must be able to do a whole bunch of other things, including but not limited to:

1. Defining the marketing strategies and outbound marketing communications
2. Pricing strategies
3. Understanding the positioning of the product in the market place
4. Competitive analysis

A couple quotes from the forum worth repeating here

“Scrum does not prescribe further responsibility beyond optimizing development to ensure business success” (Anonymous)

“The Product Owner role, on the other hand, is really about representing the business side and working with engineering to optimize the software (or technology) delivery part of the entire product solution.” (Greg)

The best ..

“The product owner role is a genuinely new role and disruptive for most organisations, as it does not easily map onto existing roles and structures” (Roman)

In summary, depending on your situation, the PM and PO roles will be performed by the same person, a group of people or separate people – frankly I don’t care. As long as there is a person dedicated to doing the PO duties and responsibilities as defined in the 6 bullets above, then all is good from a scrum perspective.

Switching stories mid sprint


I blogged about this some time ago and then posted the blog on various agile forums to judge peoples responses.

Most of the responses were well reasoned, however, one of the responses I received shocked me somewhat and so I feel that it’s worth blogging about this particular situation once more.

The response I received was “You’re not serious you’re going to ignore the PO” and “You can’t be a slave to the process”

In all fairness, there are many situations under which the need to switch stories arise. And the specifics were not really provided. For example:

How long are the sprints?
How far into the current sprint are you?
Are there stories that have yet to start that is of similar size that you can switch it out with?
Is this a critical issue that needs to be fixed ASAP as customers are complaining and may negatively impact revenues?

Those are some of the questions that need to be asked when making that decision.

In response to being a slave to the process…

Well you’re either a slave to the process or the team is a slave to any chicken in the company who shouts the loudest. Lets go back to basics and why the Sprint is there in the first place. It’s designed to provide stability for the team to get stuff done. Hopefully you’re doing short sprints so it’s not a lot of time before the team pops it’s head up again and asks for more direction.

If the team listens to whatever the next flavor of the month is, then we’re back to square one where there’s just chaos and nothing gets done. Seriously, smart people figured out why we need to do it this way. There is strong evidence to support that this makes a difference, a really positive difference. So lets not willy nilly and go changing plans whenever someone in the organization feels like there’s something more important to do.

Moreover, in this situation, I think it’s important the team asks some serious questions as to why suddenly there’s a story that’s so super urgent that it calls for a change in plan. Lets say you’re doing 2 weeks sprints and lets say you’re midway. This means in reality that 5 days ago, nothing was more important (top priority items get selected to go into the sprint). Why all of sudden is their a need to change direction so soon after. Additionally can’t it wait another 5 days?

Now I am sure there are times where such a situation arises and that’s fine. I would never be so hard-line to suggest that the team doesn’t collaborate over this and decide what are the best options. And in such a case, it’s important that the team does this.

But lets be very careful how we deal with this. Because once you do this once, it’s a slippery slope after that.

So what would I do. As already mentioned above, I would sit down with the team. Have the PO explain the dilemma. Thereafter, it’s up to the team to decide if there is an easy swap out that doesn’t impact the Sprint goals and productivity. Ultimately if it is possible, I am sure most teams would do it any ways. Level heads should prevail.

State of Agile


Seems like there’s lots going on in the agile world right now. Lots of talk about Lean and it’s impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.

So how do we make sense of this all?

My opinion is that there is value in each of the methodologies (for the purposes of this blog I’ll refer to them all as methodologies even though some of you might not think of them as such). It’s real important to read about them all so that you are armed with enough knowledge to know what’s out there. I see this as a toolset from which you can choose for your specific situation.

In order to illustrate ….

Scrum is a methodology and process that provides the mechanisms for teams to learn and adapt. Scrum however doesn’t say much about the meaning of DONE and how to accomplish that. That’s where XP comes in. XP has great practices around engineering discipline. It teaches us all about craftsmanship and producing quality work. I personally cannot see anyone practicing Scrum without at least some elements of the XP toolset. Be it pair programming, TDD, ruthless refactoring, emergent architectures etc.

Lean on the other hand is way more philosophical, but they have great teachings. For example, recognizing that work-in-progress is a liability is huge. If you start to think like this, you’re going to minimize work-in-progress and as a result you will improve overall cycle time. With Lean, people come first. What effect does this have on your organization? Well happy teams make happy customers, better quality software, improved work culture.

And Kanban? Well Kanban helps teams with flow (i.e. cycle time, throughput etc) and almost eliminates the need for traditional sprints which I won’t get into here (subject for another discussion). So many teams are using kanban boards for controlling the workflow of tasks or stories, or both.

Scrum has also been said to have problems with scalability and cross site development shops. Well Stride in it’s infancy (not even sure you can call it an accepted methodology yet) has adapted Scrum to provide capabilities for better handling these sort of situations.

So what do you do?

Well in my opinion Scrum provides the best overall process or mechanism to manage agile project. It’s a good base to start with and I would definitely start with Scrum. But you can’t go it alone with Scrum. You have to pick and pack from other methodologies till you get what works for you.

I think Agile is evolving and most likely wont stop. And why should it. I want us to get better at it. And there’s so many smart people thinking about how to make software development better. I can’t wait to see what it will be like in 5 years from now.

Poka Yoke, error handling for your process

Software engineering is still a very human endeavor. Its a complex process that requires our ability to create non-standard solutions for non-standard problems. But with this ability to creatively solve problems comes a tendency to introduce defects, one of the seven wastes lean production and lean programming try to eliminate. Jack Milunsky describes several ways to reduce the amount of defects in his article. I want to look at another idea from lean manufacturing for reducing the number of defects called Poka Yoke in Japanese and have a look at how we can apply this idea to software engineering.

Poka yoke is a Japanese term that means something like fail-safing or as I like to call it fool-proofing. The idea is that instead of just telling people how to do things you design your process, your tools or your product in such a way that it becomes harder to make mistakes and easier to do things the right way.
USB cables are a good example from manufacturing. It’s impossible to accidentally connect two USB printers together because of the way the plugs are designed. You can only connect a USB device to a USB host. Another well know example are microwave ovens that turn off the moment you open the door.

Poka yoke in software engineering takes a bit more creativity. Software is incredibly flexible so it’s often harder to define right and wrong ways to fit parts together. First lets look at a couple of ways we already do poka yoke without knowing it to get some inspiration. Later we can look at how we can fit more of it in our process.
We have a lot of practices that make it more difficult to check in faulty code. Unit testing and regression testing together with a continuous integration system makes defects very visible very fast. A similar but older technique is coding by contract. Defining pre-, and post-conditions for every function in your code making it fail fast whenever it is called in the wrong context or with the wrong parameters.
Another concept in API design that is gaining popularity is ‘convention over configuration’. Instead of letting consumers of your API configure every aspect before they can start to use it you give them a set of sensible defaults that ‘just work’

Of course it’s easy to go overboard with fool-proofing your process. We know that for every fool-proof system the universe just invents a bigger fool. The trick is to just fool proof the parts of your process that repeatedly cause defects. The best way to do this is to bring it up as part of your retrospective. Try to find the weak spots in your system and make them more robust by setting sensible defaults or adding tests. Sometimes even improving names in your code can improve things.

The 7 Software Development Wastes – Lean series Part 7 – Defects


When one looks at all the wastes, defects has to be the most obvious one. The cost and repercussions of finding defects varies depending on where in the cycle they’re found. Defects found early on in the development life-cycle are way less costly to resolve than defects found later on in the cycle; the most expensive being when applications are already in-production.

Additionally, depending on when the defects are found, defects can and do trigger other wastes like task switching, relearning etc.

Defects can be very costly for an organization. So the trick with defects is that you need to 1) Prevent them from happening in the first place and 2) Find and fix them as early in the development life-cycle as possible.

So what can you do to prevent them from happening in the first place?

  1. Keep your stories small, and unambiguous.
  2. Ensure that each story has well defined acceptance test criteria (assisted by input from the customer).
  3. Ensure that your code is well tested. Adopting good Test Driven Development habits will pay back in spades.
  4. Pair programming and code reviews are excellent ways in which to prevent bugs from being created in the first place.
  5. The more you automate the better. So automated functional testing is a good way to automate the functional test plan and get results fast and to ensure that new code changes aren’t breaking other parts of the code.
  6. Ensure staging environments mimic production as closely as possible.
  7. Make sure that as you find new defects, you add unit tests to your test suite to keep your unit testing current.
  8. Finally, document your code well.

An interesting quote from Mary and Tom Poppendieck’s book called Implementing Lean Software Development,

“If software routinely enters final verification with defects, then it is being produced by a defective process”

…. which needs to be fixed. So…

Step 1. Prevent the bugs from happening in the first place by “mistake proofing” your code
Step 2. Do whatever you can to find the bugs early on in the process while the code is fresh in the developers minds – i.e. ensure you have good functional test plans and test tools.
Step 3. Ensure a proper staging (or test environment) that mimics production environment as closely as possible
Step 4. Get the software into the hands of customers as quickly as possible, so good Agile practices help here.
Step 5. If you find defects, ensure they never happen again by keeping your unit tests current.

Photos from AgileEE 2009 in Kev, Ukraine

Few days ago I was honored to speak about Agile Planning on Agile Eastern Europe conference that happened in Kiev on 18th and 19th of September. I promised many people to share the conference photos, so here is a slideshow. I also added some pictures of the Kiev and its people to help you feel the atmosphere and showcase my great photo talent If you prefer looking at photos one by one, you can find them in this flickr collection.

I hope you’ll like the pictures.

The dirty secret of pair programming

Pair programming is one of the more controversial extreme programming practices. Having two people work on the same piece of code at the same time looks very unpractical and inefficient to someone not familiar with this practice. Pair programming proponents like me are usually quick to point out the benefits like improved quality, less rework, better communication and better knowledge sharing within teams but I think the biggest reason pair programming works is usually kept quiet.

People work harder when there is someone looking over their shoulder.

I’m going to be completely honest with you here. When I work alone I spend a considerable amount of time surfing the web, reading email, twittering (you can follow me at @mendelt) getting coffee and talking to coworkers. This means I’m spending less time working but it also means I’m constantly interrupting myself during the time I am doing work making me even less productive.

Now we don’t tell our managers this because it wouldn’t do anyone much good, the problem is a bit more complex than just people slacking off. What I’ve observed is most people have a hard time pacing themselves. We do really focused work for five minutes and then take a break. Unfortunately breaks have a habit of taking more time than they should and productivity goes out the window.

To solve this problem we need a way to maintain a sustainable pace. Pair programming is a way to do just this. Forcing yourself to explain what you do to your pair is a great way to maintain a sustainable pace and work a bit harder.

The Problem With Planning

Agile Software Development Made Easy!  The Problem With Planning.Hi, this is Kelly, from Agile Software Development Made Easy!

I think I’ve been pretty successful in my career. But if I was better at planning, I wouldn’t have achieved half the things I’ve achieved in my career! In fact, I wouldn’t even have started some of them…

In reality, there are some things you can plan, and some things you can’t. The trouble is, in most organisations we’ve come to expect a plan. And to meet it whatever happens. And that’s just not realistic.

Doing detailed planning pre-supposes you know where you want to go and aren’t going to be influenced too much by what happens in the meantime – or at least not without a substantial amount of re-planning. This, at least in my experience, has a tendency to give project managers tunnel vision at times.

Now don’t get me wrong – I’m not suggesting for one moment you embark on a project that doesn’t have a clear and robust vision. And I’m not suggesting for a moment you embark on a project where you have no idea how to achieve it and whether it’s a reasonable (although hopefully challenging) goal with the available resources. And forming that into an outline plan to provide some markers to aim for is certainly a good idea, but ideally it’s a high level roadmap rather than a detailed plan.

Coming from a traditional software development environment, I realise this sounds slightly mad. And I must admit it takes a certain amount of maturity and experience to recognise that you can’t really plan in detail up-front if you want to retain any flexibility, as the real requirements, risks, issues, priorities and opportunities all tend to emerge when you start to build and see the software in action.

Most organisations are not be ready to accept such a radical idea – the idea of acknowledging you don’t really know what you want – certainly not for sure – and you don’t really know what you’re going to get for your money, or when. So, as a minimum, a clear vision and outline plan are essential, but be careful to keep them to a high level.

Rather than a detailed plan, I prefer to see a strong vision, a strategy, goals, and a roadmap (high level outline plan). The tactics to achieve this, for example the precise features and all the tasks to deliver them, can vary along the way and are best not articulated up-front. This enables the team to discover the details when they are in a better position to do so, and allows them to change direction rapidly in response to changing circumstances.

This, when you think of it, is the very meaning of agile


Photo by tanakawho

The 7 Software Development Wastes – Lean series Part 6 – Delays


Interestingly, this weeks blog covers the 6th waste – Delays – as identified in Lean. How appropriate after the long delay since my last blog post on Task Switching. Herein lies an example of what Delays in software development can cause.  Delays introduce discontinuity and trigger additional wastes already covered like Relearning. It’s important in any process, including software, to have continuity. This reduces cycle time and minimizes other wastes like Relearning, Task Switching etc.

Focus on the end-to-end process, not individuals

It’s important to identify Delays early on and try to rectify them as soon as possible in order to maximize team productivity. It’s interesting… I have been reading many interesting threads on the Agile forums lately about measuring developer productivity, team productivity etc. Managers/executives have us focus our efforts and attention on individuals instead of looking at the end-to-end process to find the real issues that address productivity and enhance team effectiveness.

It’s actually unbelievable to me that organizations get trapped like this. Always thinking that Developers are the bottleneck. If we learn from what Lean teaches us, simple value stream mapping can uncover the real gems that can increase productivity.

Reducing delays between sprints

It’s important to ensure that the value stream is tuned for maximum efficiency where there are little to no delays at any point in the process. For example, yesterday someone posted a question on one of the forums asking if it’s possible to not have delays between sprints. Well of course it is possible but it takes hard work to get this right. You have to ensure that the backlog is properly groomed. So you need an effective PO who understands the market, the client etc. You need well written stories. You need estimates from developers early so the PO can make decisions ahead of the planning meeting. It’s all about designing delays out of the system so that there are smooth hand-offs at all the transition points. And it’s worth mapping this end-to-end process and identifying delays at each of these points.

Common Delays

So what are some of the more common delays you can look for and what can you do to avoid them?

1. Project approvals – waiting for projects to get approved is the most cardinal of all sins as this usually has handfuls of developers sitting around twiddling their thumbs and is a blatant disrespect for peoples time. Coupled with this is the fact that waiting causes dissatisfied and disgruntled employees and only serves to ruin the culture in an organization

2. Waiting for a proper prioritized list of requirements – so that work can get started.

3. Waiting for resources to become available – generally impacts projects significantly. This one is not necessarily an easy one to solve as there are generally budgetary concerns. But this then begs the question – is the company taking on too much? You can’t be successful if you’re not focused and properly staffed.

4. Change approval processes – well you don’t want to hear my opinion on this. Suffice to say, these processes need to be eliminated entirely. And all Agile processes inherently solve these problems. Shortening Sprints helps big time.

5. Increases in work-in-progress – The more work-in-process, the more developers have to wait before they can deploy their code to production.

6. Delays getting client to sign-off on acceptance tests – We have a services business and we find that this is a huge problem for our organization. Not getting sign-off is just a liability for the company as you’re not getting paid until you get sign-off

Take the time to assess where delays are occurring and I can guarantee you that the effort spent doing this is hugely beneficial to your productivity, efficiency and overall bottom line.

If you’re not moving you’re not agile

Lately I’ve seen a couple of doom scenario’s scetched out for agile. It seems agile is dead or at least dying at the hand of the PMI. I don’t want to bash the authors of these articles. I respect them and agree with most of their arguments but not with their conclusions. Agile is changing, sure, but it’s not dying, we’re all about embracing change right?

At it’s core agile isn’t a process or a methodology, it’s a set of principles with a framework of practices to support them. One of the most important principles is about change, not just in our requirements but in our process, our organization and even in change itself. Agile is about improving your process, trying out new things checking them against our principles and core values and keeping what works.

Agile has never stopped evolving. We’ve been incorporating ideas from other fields into our set of practices like kanban and self organizing teams. And we’ve been trying out new ideas, we’re going from TDD to BDD, we’re branching out into agile software architecture with SOLID principles and emergent design. One thing that’s important to notice is that many of the new ideas in agile aren’t actually very new and come from other area’s.

With that in mind it’s not really strange to see agile practices being taken up in other environments too. Not every organization is willing or able to support the constant evolution required for real agile implementations so they do the next best thing and pick up our established ideas and practices. We’ve been supporting this ourselves for some time by supplying pre-packaged sets of practices in the form of Scrum, DSDM or Xp frameworks. And forces outside the agile community have been doing this too. Agile Rup has been around for some time and now the PMI is also picking up agile ideas.

It’s easy to bash these agile hybrids as not being true to ‘our’ principles and somehow inferior and dangerous to ‘our’ movement. But I think the real danger comes from somewhere else.

The real danger is stagnation. If we start rejecting ideas because of where they come from we start slowing down. Don’t bash the PMI because they use our practices out of context but learn from them just like they are learning from us. Take what we can use and grow. Don’t let agile become the bearded conservative old fart that we set out to replace.