Three Keys to Successful Product Ownership

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all.

Manage Both the Big Vision and the Small Batches

Keeping a balance between the development of product qualities that will fulfill the business case and the tactical execution of low-level features is perhaps the most important skill possessed by a Product Owner. The difficulty in simultaneously doing both of these things well often leads to an actual split in the role, where a “Strategic” or “Chief” Product Owner focuses on the big picture, and the “Tactical” or “Proxy” Product Owner works with individual teams attending to the details of execution. Tools like story mapping, product trees and personas are commonly applied at the big picture level by Strategic POs, while sketches, wireframes, process flows and various collaborative modeling techniques are generally employed by Tactical POs to help teams better understand and execute the details.

Strategic product ownership is focused on garnering feedback and testing the project's assumptions at the vision and business case level, while tactical product ownership should align the whole team against small batches of work within sprints to ensure the best execution possible at the detailed level.

Test the Project’s Assumptions

Business cases are often presented as foregone conclusions: Build the features, and they will come. However, there is no shortage of failed and unloved products to prove that this is nonsense. Projects are built upon more or less educated guesses of what the market and stakeholders need and desire, and it is the Product Owner’s job to test and refine these assumptions, thereby guiding change through objective data.

Techniques such as customer development in the "Lean Startup" approach focus on stating your assumptions in such a way that they can be tested, and then using feedback from these tests to adjust the project’s focus. The simple process of coming up with metrics that represent the product’s desired qualities and impact areas also can be of tremendous help when attempting to balance diverse needs across disharmonious stakeholders, as it forces a focus on overall project needs rather than individual features. In essence, the why must precede the how.

Use the Whole Team

When Scrum was first formulated, a joke cast the “team” as committed “pigs” while the Product Owner (along with general stakeholders) was dubbed a merely involved “chicken.” This is an unfortunate place to draw the line, because these two roles work best as a tight-knit partnership. Scrum teams already play an active role in design and feature elaboration, and the best products come from fully engaged teams, not ones that simply wait for their orders or ones design in a vacuum.

Collaborative modeling techniques, where designs are created and refined by small groups rather than individuals, are common in such environments. Finding the right balance between giving the team a “final, approved” design to develop vs. involving them deeply in the design process itself isn’t automatic or consistent across teams, but it is the only way to maximize both the efficiencies so often touted in Agile methods with product innovation, effectiveness and quality.

I hope you've found this post useful. If you have any other questions about how to be an effective Scrum Product Owner, share them in the comments and I'll do my best to answer all of them in future posts.

What will it take to transform management? Look to the Polio Eradication Model.

In a few days, I'll be leaving behind the balmy weather in Chennai and heading to #Stoos in Switzerland. Our Stoos Gathering attendees will be deliberating on the issue of accelerating the transformation of management. We'll likely be asking questions like, "How can we accelerate the transformation of management away from creaky, dysfunctional models of the past and towards modern, dynamic in the present?"

Or "How can we catalyze widespread change in management to better meet the challenges of our turbulent times?"

Some days ago, I blogged about some of the models under consideration, and indicated that all of the approaches are essentially humanistic and systemic. So, whether we consider slightly older models like Jim Highsmith's Agile Project Management model or the Declaration of Inter-dependence; or more recent ones like Jurgen Appelo's Management 3.0 and Steve Denning's Radical Management, I believe the required transformation from current management state to future state is less about the mechanics, and more about the fundamentals.

How can we transform from older industrial-style management with its mechanistic command-and-control to newer "light-touch" humanistic management with decentralized or distributed control? In the agile world, we have certainly seen many companies initiate and sustain agile management and agile development transformations. The Forrester Group reports more and more organizations have initiated agile transformations world-wide. In my last blog post, I referred to this as creating a playground of productivity. In response, @stevedenning points out that the bigger question is, "How can we sustain the transformation?" I've spent the last few days in preparation for #Stoos: reviewing available models, reviewing the comments surrounding the Stoos gathering and perhaps most important, doing some personal reflection and retrospection on that very question.

While mulling the question, and perhaps enabled by my current surroundings, I recalled a very successful worldwide movement: the Polio Global Eradication Initiative. I first learned about this initiative when, on a flight to India some months ago, I sat next to a gentleman from Boston who was leading a U.S based team of volunteers from Rotary International. The goal of the initiative is to completely eradicate this often fatal and always debilitating disease from the earth.

Rotary International is one of the four spearheading partners in the initiative, and it is heart-warming to see volunteers from all over the world fund their own way, and team with local organizations and volunteers to help vaccinate children in the remaining hotspots.

The key partners: the World Health Organization (WHO), Rotary International, the US Center for Disease Control and Prevention (CDC), and the United Nations Children's Fund (UNICEF) have mobilized thousands of volunteers, and managed and coordinated and managed their efforts in alignment with clear strategy with four pillars:

1. Routine immunization
2. Supplementary immunization
3. Surveillance
4. Targeted "mop-up" campaigns

The results are impressive. Per UNICEF, over the past 20 years, there has been a 99% reduction in polio cases.

I think we have a lot to learn from this model that brings public and private organizations; and governments and individuals together to work towards a common goal.

My thoughts on using the polio eradication initiative as a model for a global movement to transform management coming up in the next blog post.

Large-Scale Management Transformation: How Can We Create a "Playground of Productivity?"

Something that has come up in discussions around the Stoos Gathering is the pivotal question, how does one create and sustain large-scale management transformation? The #Stoos participants have been engaging in lively discussions, and I thought it would be good to mull the topic as well.

So, I began looking back at some of the most successful transformations I've witnessed, two key factors emerged: a true business need and a willingness to experiment. From our archives, I found this post with my answers to 5Qs on Agile. Don't miss Bud Phillips' amazingly prescient conversation with our own Bob Payne on sparking and sustaining management change. I really like Bud's rhetorical question, how can we create a "playground of productivity?"

More on this coming up.

Merry Christmas everyone!

Want to Transform Management? Help Me Prepare for the #Stoos Gathering

On January 6-7, 2012, I will be in Stoos, Switzerland as part of a gathering of management enthusiasts. Organized by the core team of Jurgen Appelo, Steve Denning, Peter Stevens and Franz Roosli, we have a lofty goal: we are seeking to accelerate the transformation of management. As Steve Denning and Jurgen Appelo posit, the pace of change in the world of management has been – glacial. So now, there is much interest in catalyzing that process to accelerate change in this area.

In preparation for the gathering, Jurgen has prepared a short list of models, and others are adding their thoughts. Before we can begin looking forward, I want look back in Agile tradition to make sure we are taking the past into due consideration, and that we can build on and synthesize different models.

In my own book, Managing Agile Projects, I shared my three guiding management principles for agile teams and projects:

1. Foster alignment and cooperation
2. Encourage emergence and self-organization
3. Institute learning and adaptation

Most everyone familiar with agile methods is likely able to trace things back to the seminal Manifesto for Agile Software Development. However, lesser known, but perhaps a "nearer neighbor" to the world of management is the Declaration of Inter-Dependence. In 2005, several of us within the agile movement were convened by visionary leader Jim Highsmith and hosted by David Anderson in Redmond, WA and emerged from that gathering with these six management guidelines that constitute the DOI:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership
• We expect uncertainty and manage for it through iterations, anticipation and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent MacDonald, Polyanna Pixton, Preston Smith and Robert Wysocki

Alistair Cockburn's later commentary and explanation capture the thoughts of that group best, in my opinion. The DOI has certainly been my touch stone as I've applied Lean Thinking along with agile values and practices since then. I've found it especially useful when applying agile methods at the enterprise level, because of its lean-infused thinking and language. For example, phrases like flow of value, situation-specific strategies, and environment to make a difference help ensure that we simultaneously take both a humanistic and systemic approach to management.

That humanistic and systemic approach underlies the approaches postulated by both W. Edwards Deming and Peter Drucker, upon which we have built the foundations of modern agile management. Tellingly, at the core of Lean Thinking are these two fundamental principles: respect for people (humanistic) and continuous improvement (systemic).

Even if these principles are not yet manifested in a widespread fashion globally, there are certainly brilliant pockets of adoption world-wide. In North America and Europe, I've witnessed the power of agile methods to drive tremendous results, including some monumental agile adoptions. I'm now on vacation in India, and one model that has caught my interest here is the one practiced by Vineet Nayar at HCL Technologies, "Employees First, Customer Second." Definitely sounds like a humanistic and systemic model, doesn't it?

Finally, over the past year, since I was introduced to the concept by Jeff Sutherland, I've been captivated by the notion of wise leadership, as proposed by Takeuchi and Nonaka. Takeuchi and Nonaka recommend the quality of phronesis as the quintessential quality of wise leaders, and pinpoint these six abilities of a wise leader:

1. Wise leaders can judge goodness
2. Wise leaders can grasp the essence
3. Wise leaders create shared contexts
4. Wise leaders communicate the essence
5. Wise leaders exercise political power
6. Wise leaders foster practical wisdom in others

Earlier this month, as 2011 drew to a close, I was privileged to attend a remarkable event in Milan, Italy hosted by the PMI's Northern Italy Chapter (PMI NIC). Organized by Tiziano Villa and Walter Ginevri from PMI NIC and bringing in Victor Carter-Bey and others from the PMI Global, Tiziano later remarked that we were able to create a "ba," or place where relationships are forged and interactions occur as participants try to create new meaning.

As we usher in the New Year, I am now looking forward with eager anticipation to the trip to Stoos, and I'm hoping we can create a similar "ba" that helps accelerate the pace of management warming.

To reiterate the #Stoos gathering organizers' call to help transform management, please help us by sharing your thoughts in less than 100 words, either via the comments box below or by email at sanjiv DOT augustine AT LitheSpeed DOT com.

Thank you, and Happy New Year!

Collaboration in Agile Development: Should Agile Teams Work in a Bubble?

When a developer posed a question to his Twitter followers a couple of weeks ago about collaboration between agile teams and the business side of the organization, a coworker passed the question my way. Despite the fact that I wasn't able to respond on Twitter right then (ah, travel), the question came at a great time. I had just finished an agile assessment for a client, and left with a fresh perspective on the topic of collaboration and agile team management in general.

The specific question was, "Is it healthy for Scrum teams to work in a bubble protected from the business around them? Should collaboration go beyond the team?"

There are two common threads that I see time and time again: What is the goal, and how is that goal communicated? Until these two threads are tied together, true collaboration won't happen. I don't see this as being unique to the world of Scrum. To help illustrate my point, I'll try to use terms from outside of the Scrum community.

Strategic Mission (Goals)

Executive leadership, in order to truly lead, must communicate the strategic vision of the organization. A strategic vision translates into a strategic mission or long-term goals. A strategic mission should be understood by the entire organization. If a team member doesn't know the mission, how will she be able to help the organization reach its goals? From there, the leadership needs to empower the people tasked to do the work to figure out how they will accomplish the goals.

Tactical Mission (Goals)

This is where you keep lines of communication open but insert a protective buffer. If you're leveraging Scrum, the Product Owner serves as the first buffer. The Product Owner (agile product manager) understands the strategic mission of the organization and translates it into a tactical mission. You could also refer to this person as an organizational liaison: someone who doesn't need to know all of the answers, but does need to be readily available to answer questions from the team and reach out to the appropriate subject matter expert(s) when necessary. The second buffer is the ScrumMaster (if leveraging Scrum) or could be referred to as a process manager. This person understands organizational process on a team level and is there to ensure the team consistently follows that process. Process managers such as ScrumMasters also work to keep those who do not aid in tactical execution from derailing the team from getting work done.

Collaborative Team

Okay, so now it's time for me to answer the first direct question about collaboration: "Is it healthy for Scrum teams to work in a bubble protected from the business around them?" Though I do believe the team should be protected from the people trying to change their tactical priorities, an agile team should never operate in a vacuum. If people from within the organization do try to change team short-term priorities, the process manager (ScrumMaster) should be right there to impress upon them the need to respect the agreed upon processes.

Collaborative Organization

The second question was, "Should collaboration go beyond the team?" My short answer is "yes," with the understanding that collaboration is different than communication, which needs to flow up and down the organization. Collaboration by definition points to working together, whereas communication can be limited to unidirectional imparting or transmitting. Effective agile product development and project management requires bi-directional communications (the flow of information back and forth).

Once the appropriate information is presented to the appropriate people, real collaboration can take place. The entire organization, which includes all cost and profit centers, needs to collaborate to discover the best solutions and work toward common goals.

Be the Minority: Increase Engagement and Have Fun Doing It

“Seventy-one percent of American workers are ‘not engaged’ or ‘actively disengaged’ in their work,” according to a recent Gallup poll. This is certainly a dismal message for those interested in an Agile revolution, since the heart of agility is based around intelligent adaptation, and those who don’t care are unlikely to expend energy adapting.

Methods like Scrum and Kanban focus on creating environments where team members can get into flow, but they by no means assure that workers will be imbued with the drive necessary to be truly outstanding. Much of the coaching work we’ve done over the years at LitheSpeed has shown that simply getting people interested in improving can be quite the challenge.

While there are no pat solutions for this complex issue, we’ve been working hard to discern effective approaches. From fun exercises that engage the mind in learning to facilitation tricks that make work seem a bit more like play to team building exercises that leverage emotional connections, the “engagement tools” in coaches’ toolboxes are often even more useful than the process and technical expertise that are so often focal points.

One somewhat unusual tack that we’ve lately adopted is approaching things from the tooling angle; while this might seem strange as a solution to something so arcane as engagement, it turns out that many people turn to pursuits like games for this very reason. The fields of game design, psychology and marketing offer myriad insights into ways to excite people, and it is to these that we’ve turned in the development of Sensei, our first tool. In a nutshell, it focuses on continuous improvement, sidestepping the usual focus on backlogs and burndowns and attacking the problem of focusing, tracking and visualizing individual, team and organizational improvement activities.

Velocity, the most commonly touted metric used to measure agility, is unfortunately a poor indicator for engagement and team satisfaction, product quality, customer satisfaction, and even process quality. What Sensei does is gather observations about these elements, and show where they’re improving.

Our initial incarnation, focused on running retrospectives for local and remote teams, should be out within a month or so, and you can then see what the fuss is about. Until then, sign up to be notified of our first release, and let us know what you’d like to see in a continuous improvement tool, or ways you’ve found to drive engagement in your own teams.

Thanks for Agile DC: A Mountaintop Experience

After Agile DC 2011 ended, we quickly turned our attention to the Agile Development Practices East conference in Orlando, where we launched a skeleton of our new product, Sensei.

But before the moment passes into history, I'd like to share a few reflections with our community. For me, Agile DC turned out to be what is termed in some religious circles as a mountaintop experience. I'd put some very special effort into the keynote talk, and it all seemed to come together effortlessly in the end. It was definitely Csikszentmihalyi's flow at work. (For those who weren't there, you can learn more by downloading my presentation here.) But the real strength of the experience lay in being able to connect with so many from the agile community here and leave with a deep sense of appreciation and gratitude.

In that compressed period of time, so many folks were part of the experience, that the names are almost too many to list:

• The organizers and volunteers, lead by George Dinwiddie, Manoj Vadakkan, Jolly Rajan and our very own Bob Payne;
• The generous sponsors, including our partners VersionOne and LeanKit Kanban;
• The amazing speakers including Ken Schwaber, Jon Terry, Siraj Sirajuddin, David Bland, Sudhir Frederick and Montra Ellis, Paul Boos, Ahmed Sidky, Jay Flowers, Peter Saddington and our own David Bulkin and Derek Huether;
• The fantastic Twitter conversation on #agiledc, with my new friends @Sprezzatura, @donmullens, @livlab and @daverooneyca;
• Our old friend and colleague Roland Cuellar who happened to be at the conference; and
• Our faithful LitheSpeed team, including Karen Falk, Colin Agnew, CJ Huether and Lindsay Hicks who got a thousand things together to set up our table and man it for the duration of the conference.

The special sense of auspiciousness was captured by a lady who won both an iPad 2 and a book in the raffle. She said, and though I paraphrase from a leaky memory, it truly captured the moment for me, "It's diwali, and today is certainly my lucky day."

In parting, all of us here at LitheSpeed would like to leave you with a big thank you for Agile DC, and share some gifts of our own with you. You can download all the presentations below here.

1. Derek Huether's, When PMI Introduced the Elephant in the Room
2. David Bulkin's, Agile Teams - From Good to Great
3. Sanjiv Augustine's, The Promise of Agile Methods

If you're interested in hearing more about our new PMI Agile Certified Professional (ACP) class, check it out here. Also, if you're interested in learning more about our new continuous improvement tool, Sensei, check it out here: http://www.senseitool.com.

Happy weekend to everyone!