Skip to Content
Personal Insights

Signs that you’re doing well in your Agile project. Product Owner says “no”.

Any journey is made of small steps and as Agile Coaches, we need to value and celebrate all the small changes that are leading to the large scale Agile Transformation.

As spring is coming and our hopes for the best are blooming inexplicably sometimes – like the trees in our backyard – I’ve decided to focus myself on creating a list of good signs showing that the agile coaching endeavor is on the right path.

I am a Business Process Consultant with specialization in SAP Activate and Agile methodologies, supporting implementation projects for SAP S/4HANA and SAP Commerce solutions. I have delivered hundreds of hours of trainings on Agile and workshops to SAP customers followed by even more days of coaching on the job, as SCRUM Master or as both Agile Coach and SCRUM Master in the previously mentioned implementation projects.

I’m coaching for agility adoption teams in medium, large and very large size implementation projects in which many of the members are only meeting for the project duration, are coming from several companies and very often, from different countries and cultures. Some of these companies are having already the Agile mindset and are already implementing Agile practices and some are very new to it. I’m working with management, business and technical consultants and the most satisfying moments in my work are when the people I’m coaching to agility are living their “Aha!” moment that pushes them one step further towards agility.

That sudden revelation one has is my indication that we’re doing well in our transformation!

Applying the “build to budget” concept in the Agile implementation project can be quite a complex demand for somebody new with the Product Owner role. In the projects I was part of, the Product Owner role is usually taken by a Business Process Owner, a Business Process Expert or by an IT Lead who is knowledgeable, has enough courage and gets the delegation to decide on the behalf of his company.

If a new User Story appears as needful for the solution or the complexity of an already identified User Story is higher than preliminarily estimated, in a “build to budget” approach means that something needs to be taken out from the backlog to make room, to accommodate and to adapt to the news.

In this case the Product Owner needs to say “no” to a User Story and to the people in his organization who have raised it.

At SAP, in an implementation project, we’re putting the Customer in the driver’s seat, giving him the decision on what is best and valuable for his organization.

We’re doing this by giving the Product Owner role to customer’s representatives that we need to coach and support to make educated, timely and effective decisions within the time lapse that very often is less than a Sprint(2-4 weeks).

The Product Owner role is usually new to its beholder and it is coming with a lot of pressure. Very often it takes time until a Product Owner is reaching decisions in total self-confidence and comes to say “no”.

There’s an important number of perspectives that the newly appointed Product Owner needs to consider before finding his own way of looking at his backlog so that he can decides what is staying and what is going out from the release!

On top  of that, he will live the after-project life to run the business with the solution that he has decided for him and his colleagues and  he’ll be reminded on a daily basis about the decisions taken.

The Product Owner is representing a community of users – his stakeholders – and that’s making his job even more complex when he needs to say “no” to a User Story.

To support the Product Owner in his decision making process the Agile Coach must understand the customer’s decision making culture and the Agile maturity level of the company.

The Agile Coach is helping the Product Owner, in his personal and company specific context to find the lever that brings to his company a new solution and enhanced agility.

Although he’s not directly appointed to do that, the Agile Coach in SAP implementation project delivered with Agile is actually supporting the bigger, overall Agile Transformation in the customer’s company by teaching and supporting the Product Owner to embrace the agile behaviors when coaching him.

Here below I’m summarizing the most frequent aspects that the Product Owner needs to factor in his backlog management decisions along with the means and actions from the Agile Coach.

The Agile Coach must help the Product Owner on finding his own approach to say ‘no’ to his own organization.

The first time the Product Owner says in full confidence “no” to a requirement is typically after an “Aha!” moment and that needs to be remembered and celebrated!

I’m inviting you to use this blog to leave your thoughts and opinion on this matter and to share your experiences from situations when your Product Owners had to say “no”.

Was it a celebration moment?

 

I’m also taking the opportunity to promote here the newly created  SAP Activate blogging community and the SAP Activate Q&A community

 

 

/
3 Comments
You must be Logged on to comment or reply to a post.
  • Carmen Constantinescu thank you for taking time to share your experience with the community. This is great blog post. As you write, saying "no" is harder than saying "yes" and it shows maturity and vision. It gives the PO ability to steer the direction of the implementation by deciding what to emphasize. Often it is easier to say "no" if there is a strong support from sponsor and trust in the judgment of the PO by the steering team.

    Thanks again for the post and I look forward to more in the future.

  • Hi Carmen

    Thanks for your Blog post.. great content and experience you share with us . I'm also involved in a bigger project with agile approach. Since many external partners are involved with different (or no) Knowledge about Agile Approach, it is quite a challenge to bring the whole Project on a level to understand the Agile working mode and convince the whole project members to get an acceptance.

    Otherwise, in a implementation project whole S/4 Hana, we have lot of dependencies in between the applications and functions. Without Integration Knowledge of Solution Architect, it will not work in such a integrated application landscape.  To make a decision on and say no, the impact need to take into account.

    In my case , we started with a waterfall methodology ( Explore) and switched to agile for the build phase. Many partners did not understood the integration model of HANA ( It is not like a apps development)

    So I created a general integration layer, valid for all the streams. The integration layer represents the overall architecture, (not technically)  how to bild up a Hana system with all the Applications.

    1. Install systems
    2. Activate Application you need
    3. Do general configuration you need ( based on Business processes)
    4. Setup organisational units
    5. Configure master data
    6. Configure business processes ( only standard without RICEFW)
    7. Develop RICEFW
    8. Combine Processes to E2E Processes and make a final integration test.

    Based on this "Layer" model, we adopt this to our Wave and Sprint planning.