Paving the path of Scrum Adoption: (2) Product People

Publish date:

8 years of playing the game of Scrum. Often injected with eXtreme Programming. A cobblestone path to reflect on. A previous reflection was on the absolute need for upstream adoption to drive and anchor Scrum and Agile in organizations. Next is about thinking beyond the walls of the IT department, on the expectation that real […]

8 years of playing the game of Scrum. Often injected with eXtreme Programming. A cobblestone path to reflect on.

A previous reflection was on the absolute need for upstream adoption to drive and anchor Scrum and Agile in organizations. Next is about thinking beyond the walls of the IT department, on the expectation that real business people should drive development.

For IT people, the empirical Scrum framework with its frequent ‘Inspect & Adapt’ cycles has become a proven solution. Challenging every status quo has improved continuous learning in overcoming technological uncertainty (see the Stacey matrix applied on software development). And in many organizations the understanding is restored that software development is a creative and complex activity. But the focus is still a lot on ‘HOW’ software is built.

It is time to elaborate on those achieved results and take Scrum adoption to the next level.


The Power of the Possible Product

The development of software products can only be truly optimal if we also better deal with ‘WHAT’ software needs to be built, knowing that in turbulent enterprise, business and market circumstances ‘close to agreement’ (see the Stacey matrix applied on software development) is no longer achievable. Improved and active collaboration with business owners is the natural next step in further optimizing software product development. Only the people accountable for the business value of software can help overcome the unavoidable distance of agreement on features and requirements. And more than ever do these Product People need the flexibility to capitalize on unforeseen opportunities for building the best possible product. Any time.

Introducing empirical techniques to product management should lead to the rise of Agile Product Managers. At least it is a first step in promoting effective multi-disciplined collaboration across organizational walls which is essential in growing complex adaptive organizations. It leverages Business Agility for larger and lasting benefits by anchoring Agile thinking into people’s mindset. Because in a globalizing world of internal and external unpredictability, adopting a mindset of empiricism and adaptiveness is beneficial to entire organizations. Any place.

And all that it requires is the implementation of… Scrum

The Scrum framework allows giving up on trying to predict the unpredictable, as it deals with answers, solutions and competing ideas that emerge while building. Rendering the question whether they were thought of upfront irrelevant. Requirements are no longer expected to be ‘close to agreement’. Scrum helps accepting -and embracing- the complexity and uncertainty of the business aspects of software development, the fact that the final agreement on the ‘What’ of the software gets resolved when releasing it. Making frequent functional releases as the best way to progress. And incorporate real user feedback as emerging requirements.

The Scrum framework incorporates active business collaboration via the role of the Product Owner

Being a Product Owner however is only part of an Agile Product Manager’s job.  An Agile Product Manager thinks and acts as a mini-CEO in taking responsibility and commitment over the complete Product Life Cycle. Beyond development and launch of a product, it includes envisioning, strategizing, conceiving, developing, introducing, launching, communication and marketing. Activities that consume considerable time, but are of an absolute importance. It includes understanding users and product usage, aligning priorities and expactations of stakeholders, users and customers. And looking for a compromise. Because, in the end, as Product Owner they are the single wringable neck. They are the only instance telling the Development Team what to do (next) and deciding what needs to be included in a Release.

Although taking up the role of a Product Owner is only one part of the story, even within that part much care is to be given to going beyond a purely formal implementation. Agile Product Ownership and the utilization of Scrum is not about renaming or slightly redoing old techniques. Product People are not being asked to hand over a list of User Stories as a replacement of Use Case documents. This would still lay on product managers the expectation to be and act as formalist requirements providers. Nor does it suffice for analysts to act as proxies or representatives for the real business people because they lack empowerment, stakeholder backing, budget responsibility and real user accountability.

Product People will directly and intensely collaborate with Development Teams upon the vision, business objectives and functional needs of a Product. From that conversation all work that can be reasonably thought of emerges and is listed in a Product Backlog. The Product Backlog is transparent in its availability but also in its understandable language. The Product Owner manages and prioritizes the Product Backlog. For the Development Team, the Product Backlog is transparent in terms of understanding it to turn it into working software.

Product Backlog items are gradually refined, right up to the day that they are implemented. No potentially unused inventories of requirements, hard-coded plans, designs, etc. are produced. No more than the next, highest priority work is detailed appropriately. A forecast of highest priority work is delivered upon progressive learning and released quickly. Partially done work will not pile up as there is the unbreakable link of technical tasks to Product Backlog items. And Product Backlog items have been selected because they are valuable from business or user perspective. No unwanted or undone features go into production.

A source for continuous flow of Value is created

Following shows Scrum Sprints as the core of an overall Business Agile system that can be achieved when Product People step into the empirical process (from “Agile Software Engineering with Visual Studio”, Guckenheimer and Loje, 2011). In a continuous flow improving, learning and various sources of valuable feedback are integrated. A self-balancing continuum.

Implementing the Agile Product Owner has the absolute potential to pave a cobblestone path into a Pathway to Agility. So that organizations can discover, experiment and deliver opportunities in the fastest possible way. End to end.

Given our strong belief in this evolution, Capgemini is setting up a partnership with Ken Schwaber and They are moving in the same directions with the Professional Scrum Product Owner classes. Quick note to add that I am qualified from to give this training. While, at the same time, at Capgemini we have created our “Scrum for Product People” training (download flyer).

Related Posts


Agile and architecture – lessons from the trenches

Ben Kooistra
Date icon April 28, 2020

Scaling agile teams is a necessity to stay agile and keeping up business value. The agile...


Architecting the ecosystem: Five challenges for 2020 and beyond

Date icon April 8, 2020

Being agile, both in business and technology, is rapidly becoming the standard.


Industrial and agile: How to be both?

Arnaud Balssa
Date icon February 27, 2020

Distributed Agile allows companies to benefit not only from Agile methods, but also from the...