The role of the product owner in iterative software development is an important one. This person is responsible for envisioning the product to be built, and breaking that vision down into bite-size pieces that can be built in a single iteration.
Within commercial B2B ISVs (“product companies”), this role is really a partner of product management. The product manager is responsible for understanding the market, and using that to determine what problems will be most profitable for the product company to solve, and for whom; and leading the development of a solution to those problems.
Important question: Are you agile all the way out to the customer’s needs, or only within the product development core? What do you mean by “agile”?
Henrik Kniberg has posted a fantastic overview of the product owner role titled “Agile Product Ownership in a Nutshell.” For an overview of product ownership and a comparison of it to product management, please see my response in which I ask the question, “Where’s the Product Management?”
The product owner role is a difficult one to do well, even when fully staffed. First, the product owner needs to establish a product or portfolio vision, which is usually vague and generic up-front but (as more is learned) is emergent. That vision may be captured in a prototype that can be shown to prospects for validation.
Once the vision is established, it often makes sense to create a feature map, which is decomposed to a user story map as a way of knowing how much is done, and how much remains.
If starting a brand new product, the team often executes sprint zero to implement some of the basic architectural components needed to build features. In the early sprints, because capacity is not yet known, velocity will vary widely.
Picking Up Speed
Once development has started, you’ll turn some knobs to get the train to move faster.
Individual features are expressed as user stories. User stories stem from epics, and must be properly detailed in a backlog grooming effort before being built by the team. Writing effective user stories is not easy.
In backlog grooming, acceptance criteria are defined, a technical implementation approach is identified, and the team estimates the story size. Backlog grooming should be done regularly to ensure upcoming items are ready.
Many teams empower a cross-functional product owner team consisting of product management, an engineering lead and an interaction designer to do a lot of this prep work. The team can go faster if the detailed analysis, user interface design and interaction design are complete prior to starting development.
The daily standup is a status meeting where teams report progress to each other. This is the first place where inefficiencies are exposed to the trained eye.
Agile Backlog Management
Teams approach the backlog–the collection of stories not yet built–in a few different ways.
The most common agile methodology is Scrum. Scrum is a timeboxed, predictive approach where the team identifies the work to be completed and reviews at the end, and success is defined as completing the work promised.
Other teams go to the opposite end of the spectrum and try kanban. Kanban is a rolling backlog, where the team completes a story and then starts the next one in line. There is no timeboxing, and projections are made using measures of throughput (average time per item).
In between, there’s the process of scrumban. In scrumban, the periodic visibility of the sprint review is retained, but the team does not make a promise of which stories will be completed.
The product owner has to lead the engineering team, and if sharing the role of product manager, that person leads the company at large as well. One of the key ways to motivate is rally the teams around a vision of the future. That vision is often a prototype, or to be more complete, a product canvas that conveys multiple aspects of the product to be built, the market and users it serves, and other aspects.
Product managers lead as well. They speak to the market at conventions and trade shows. They conduct webinars to help establish thought leadership. More on this under the Product Management topic.
Should the Product Owner also be Product Manager?
This is such an important question, it deserves its own section! In summary, within commercial software companies, a single individual fulfilling both roles provides the best chance for success when developing a brand new product. For a product in market, when internal departments and paying clients demand more time, the role should be split to a market facing product manager and a development-focused product owner.
To answer this question, a product team should consider some of the options available for product owner training so a full understanding of the scope of responsibilities in product management is considered.
Agile works best when paired with a number of modern engineering practices derived from the world of Extreme Programming (XP). In continuous deployment, code changes are often deployed to production multiple times per day, rather than waiting for a scheduled release.
Automated testing helps ensure the team doesn’t adversely impact existing capabilities when introducing new ones. Some teams automate tests of the specifications in a process known as behavior-driven development (BDD). In this world, the new capabilities are defined, developed and built into the test suite all at once, so that they can be assumed to continue working as new capabilities are built.
Inspect and Adapt
In the spirit of continuous improvement, the team seeks regular feedback in the form of the iteration or sprint review. This meeting supports stakeholder management, as stakeholders get to see what was built in the iteration and provide input on what should come next.
Depending on team culture, you may need to solicit stakeholder opinion separately, as a form of engineering management. Stakeholders may want to see burnup/burndown charts, which may or may not be reviewed during the sprint review meeting.
The team evaluates the sprint output during the sprint retrospective.
There are many things that can eat up time and slow a team down.
When you find there’s effort required to investigate possible approaches, the team will engage in a spike. The spike is a way of acknowledging that a fully formed feature will not emerge from that investment, but knowledge will.
Another time suck is end user support. Ideally, you want the team building new capabilities and fixing documented defects, not hand-holding users or investigating possible bugs. Having a support team empowered to perform these tasks frees up engineers for what you pay them (well) for. You may need to assign a team to help with diagnosis — but once diagnosis is complete, the job of prioritizing the remediation effort should fall to the product owner.
In an emergency, a team may need to be pulled off the current sprint goal to work on an urgent problem. In these cases, the sprint is aborted, and the team goes into panic mode. No customer features should be expected while the team is in a Panic.
Lots of coordination is required. The product owner is responsible for stakeholder management, and serves as a buffer between the stakeholders and the development team. This is a difficult part of the job, and requires thick skin!
In a multi-team environment, the product team must coordinate the efforts of multiple teams. The product owners need to coordinate at a backlog level which features are needed in which order, and the engineering teams must coordinate between each other when technical dependencies exist.
Some teams empower a scrum master to eliminate roadblocks, where others empower the teams to do this themselves. In more complex projects, a release manager helps to coordinate the dependencies and functionality intended for a single release to ensure everything is completed in time. The larger the devleopment organization, the more difficult this job is!
TL;DR: Be nice to your product owner! 😉
Image source: Flickr