Agile 2015 Conference Presentation - Product Owner Teams: LeadingAgile Program Management

I've shared my talk from Agile 2015, Product Owner Teams, Leading Agile Program Management.

Product Owner Team: Supporting the Portfolio Team

I'm talking about the Product Owner Team at Agile2015. Here I’m going to focus on the relationship with the Portfolio Team. A Portfolio Team looks after the portfolio of Epics and are a key stakeholder group of the Product Owner Team. In "Product Owner Team - Why?", I identified a key objective for the Product Owner Team: “Provide timely information to the Portfolio Management for investment decisions”. Visibility is important to support an enterprise agile program. I’ll briefly describe the key decisions and the information the Product Owner Team provides. 

Strategic Alignment. The Portfolio Team ensures work is strategically aligned to Investment Themes, Strategic Objectives, or whatever the organization uses to express their strategy goals. The Product Owner Team, working closely with the Portfolio Team, describes Epics in an Epic Brief that includes a Value Statement of the problem or opportunity, Features and Benefits, and high level constraints. With this information, the Portfolio Team validates alignment to strategy and prioritizes the Epic backlog. 

Demand Planning. The Portfolio Team ensures a valuable and viable roadmap is maintained. The Product Owner team is staffed to collaboratively elaborate the features and architecture and address the key constraints for the Epic. From this work, they present the Epic on the Epic Roadmap and Epic Risk Report and update the Epic Brief with an Opportunity Statement. The Portfolio Team now has visibility to explore roadmap options and ensures significant risks are addressed.  

Detailed Planning. The Portfolio Team must be assured of sufficient planning to deliver Features. The Product Owner Team has provided a clear Feature Backlog and Roadmap and supports Story Writing and Story Mapping by the Delivery Teams. Now the Product Owner Team  facilitates Release Planning resulting in a number of simply stated Release Plans covering Business (Scope and launch), Technical (Test Approach, Technical approach, Environments & coordination), and Logistics (dependencies, operations, security, etc).  The Portfolio Team ensures responsible planning and explores detailed options. 

Execution. The Portfolio Team requires validation of measurable progress. The Product Owner Team coordinates across Delivery Teams and support teams and is the escalation point for issues to facilitate the delivery of features. The Portfolio Team has visibility to the demo of integrated features to support decisions to continue, change or stop investing in the Epic. 

With a few brief reports and frequent communication, the Product Owner Team ensures the Portfolio Team has visibility and timely information they require to make good business decisions.  

Agile2015 Talk: Product Owner Team - Why?

Agile 2015 is just a couple of weeks away. I will be presenting my talk on Product Owner Teams: Leading Agile Program Management and want to share some thoughts ahead of time on the problem we are solving with the PO Team. 

I summarize the Goals in a couple of bullet points:

• Provide Agile Teams with the support, guidance and coaching they need to get the job done
• Improve and accelerate your product delivery by improving your Agile Transformation

I focus the talk on four key Objectives:

• Provide clarity through a well defined feature backlog
• Hold Agile Teams accountable for making and meeting commitments
• Demonstrate measurable progress by facilitating the demonstration of integrated features
• Provide timely information to Portfolio Management for investment decisions 

Here’s some more detail from the abstract for the talk:

"Building a clear and effective product backlog to deliver on strategic initiatives in an enterprise attempting agile can be difficult. Now add the competing needs of other work with various stakeholders across the organization. And that’s not the hardest part. The real challenge is prioritizing and coordinating considering risks, technical viability and planning dependencies.  

 

The Product Owner Team wrestles with these organizational challenges to provide Agile Teams with the support they need to get the job done.  This team ensures the work is strategically aligned and prioritized with Portfolio Management. Only then can the team establish, maintain and coordinate a clear feature backlog for Agile Teams in a complex environment. 

 

The Product Owner Team will improve and accelerate an organization’s agile transformation. This talk presents a proven framework for leading Agile Program Management including the roles, artifacts and activities for an effective Product Owner Team.  Additionally, this talk introduces an Agile Program Management starter kit so participants can get started quickly in their own organization."

The work of the PO Team is challenging. This talk will help you kick start your transformation.

Thinking Together for Release Planning

I have been noodling on the phrase “Thinking Together”. Thinking Together is one aspect of the mindset that Product Owners need to embrace. I have been using this phrase with new Product Owners to explain why many Agile practices work. But each time I start to explain this simple idea, it gets complicated because I get asked about process steps and roles and responsibilities.

Yesterday, I returned to a big company with a pretty complex product portfolio where we had done quite a bit of work including starting up multiple Scrum teams. I recalled our first release planning with this group several months ago. There was a lot of uncertainty and even some anxiety about this “lightweight” approach.

They were missing their requirements and specification documentation. They were hesitant to assess the value and size of the features, concerned they might leave something out. I prepared a Release Planning agenda for them to follow. I also prepared a list of roles and responsibilities. And I had some one page cheat sheets on the activities for release planning. They needed some process rules initially to learn how to think together.

When I ran into a Product Owner from this big company, the progress they had made was obvious. He was facilitating release planning and was excited to walk me through it.

My friend the Product Owner brought me into the conference room where they were wrapping up their release planning. There were some product managers, the product owner, some tech leads, QA and even a project manager. They were taking a break chatting and smiling. There were some architectural sketches on the white board. There were four flip chart sheets with sticky notes representing epics and features. The flip chart sheets represented the work completed for the past release, the plan agreed to for the next release, and planning for the following release. They had one more sheet with parking lot items.

The product owner showed me the result of their Thinking Together. They had discussed the epics written on blue stickies and wrote all the features they might need on purple stickies and put them under the epic. Then they thought together some more and rated each feature with business value, complexity and sizing. They added some acceptance criteria and clarified assumptions as they went. They did this for several epics. Then they started adding features to the flip chart sheet representing the next several releases.

Now, they realized they would not get everything done that the product managers wanted. So they moved some lower value features to the parking lot and rearranged the features on the flip chart sheets until they agreed on a plan. By Thinking Together in planning the next couple releases, they pretty quickly learned together and gained a shared understanding of the work they would do for the next six months.

They had learned to Think Together to get the end result: a solid release plan.

Beware of Common Sense

When working with organizations in Agile transformations, I help them to do what makes sense. I encourage them to challenge me when they think I am suggesting something that does not make sense.

Do what makes Lean-Agile Sense
Here is the rub. When I explain what makes sense, I talk in terms of "principle based" sense. Agile Sense provides a set of values and principles to guide our decisions and actions to achieve an Agile mindset. Lean Sense explains some of the process science of flow embodied in Agile methods. It is surprisingly easy to loose sight of this at key moments. Education and training on the Agile Manifesto and Lean Thinking is critical early on.The rest of the coaching engagement is a pragmatic application of Agile and Lean sense in decision making. This is a great way to help them learn and for me to make sure they understand.

Beware of Common Sense (and Be Aware of Culture)
Organizations and individuals will face challenges in an Agile transformation. They will struggle with decision making to solve these challenges. This struggle is good. But if they are not intentionally doing what makes Lean-Agile sense, they will inspect and adapt away from Agile. Teams tend to revert to solutions based on common sense in the organization. Common sense is the knowledge and experience most people have. It is based on what has "worked" in the past. It is remarkable how fast a group can slide back to what they did before based on common sense.

A Bias for Less
Common sense tells us we need more of the things on the right of the Manifesto. More documentation and following the plan. These are comfortable and safe. Agile sense encourages a bias for less on the right. Encourage a bias for less of the items on the right instead of more.

For example, as teams struggle understanding what to build, some managers want to solve the problem with more documentation. Agile Sense encourages progress towards working software. Start with getting getting better at collaboration to demonstrate software sooner.

Common sense tells us big batches lead to efficiencies of scale. Lean sense explains big batches lead to expensive delayed feedback and wasted effort that out weigh these efficiencies. Without fast feedback, we do not learn as we discover the solution.

Be Vigilant

Stay engaged in retrospectives and decision making. Look for common sense solutions.

• A bias for more of the things on the right side of the Manifesto
• A bias for bigger batches
• A bias for delay in feedback

Change the conversation with Agile and Lean sense. Promote a bias for less, not more.

Discovery is Fun

Jeff Patton gave a talk at Agile 2012 on "The Product Owner's Role". A couple of statements really resonated with me. "Discovery is what the product owner team does." and "The product owner's job is to provide impact and outcome." A film of a project I led came to mind.

A successful small company wanted a system to track and report performance of their field personnel. The VP of Operations had some clear ideas on what he wanted to see. We agreed to a short term 3 month contract to deliver and implement a pilot solution. Spoiler alert. The final product was very different from what he initially envisioned.

First, we had to develop an easy to use system to collect time data. We made a short list of the basic data we needed. We mocked up and demoed the data collection screen to a field services manager. He immediately asked why he had to enter information from the schedule that the company published in a spreadsheet. Discovery? We can use this to publish the schedule too. The project sponsor thought that was a real bonus and we were only a month into the project.

Next we had to validate the data. We could use payroll data to validate the time entry. Discovery? Maybe we could use the time entry to populate the payroll system. Turns out there were legal issues and that idea failed. Jeff also said in his talk that while many ideas fail, we learn from them. Later, we were able to run some nice payroll analysis report that really helped HR.

With data that was pretty easy to collect and validate, we were ready to produce management reports. We mocked up a report with some basic metrics giving the VP daily insight into his field operations. He was still skeptical. After all they had been trying to do this for several years with little success. He made some calls to a few reliable teams with poor performance for that week. Sure enough, they acknowledged they had some problems but would be back on track the next week. He was surprised by some high performing teams that he thought of as weaker. Sure enough, the teams were doing a great job and glad to hear that the boss knew it. This was powerful information.

Discovery? Maybe we could summarize by region? Maybe we could do some deeper analysis? Maybe we could track quality, customer feedback, pay performance bonuses...

Jeff also said that just building is soul crushing. Discovery is fun and rewarding. I agree. It was fun to discover and deliver a high impact business solution. And rewarding to help the people in the business. It did not hurt that we extended our contract for another 6 months.

Appetite for Change

Change is hard and many people do not have an appetite for it. Transitioning to Agile involves a lot of change: new thinking, processes, practices and tools.

So managers and Agile coaches provide training. They introduce the Agile Manifesto and Principles. They talk about ideas like Flow, cadence and light weight documentation. They introduce new practices and language. They even share success stories of how it works in other places.

Then a few teams are organized and the coaches help implement the new processes, practices and tools. We are on a roll. All this is going to lead to a better way of delivering value.

But we need to remember Agile is about individuals and interactions. We have to deal with the human side of change. Training and coaching on practices is necessary and important. But we can get too caught up in practices and slight the people. When working in larger organizations like I do, this can be an even bigger problem.

While facilitating training and coaching, try three things to help people experience how process and tools support interactions. This focus on people helps foster an appetite for change.

First, explain some benefits of an Agile Transformation this way.

• Business wants predictable and improved throughput
• Customers want quick lead times for quality product
• Teams want a good working environment where they can contribute and succeed

Second, challenge people to stop doing things or at least defer doing things. A lot of what people have always done is unnecessary especially those organizations focused on comprehensive documentation, contract negotiation and following a plan. The trick is helping people discover what to stop doing and what they can do instead to contribute. 

Third, listen to what is not said and look into their eyes for comprehension to feel their fear and uncertainty. Resistance often stems from these emotions. With this understanding, we deal with resistance in a more productive way. Thanks to an old college professor for this bit of wisdom.

Foster an appetite for change in your Agile transformation.