Month: January 2021

Posted on by — 5 Comments

How I ended up becoming a (Professional) Scrum trainer

In October 2003 my life of Scrum started, albeit not with Scrum. My life of Scrum actually started with eXtreme Programming which we then wrapped in Scrum. In May 2004 I attended a CSM class (“Certified ScrumMaster”) by Ken Schwaber in Brussels (Belgium). At the time I had no idea but it seems it was the first CSM class in the wider region.

Fast forward >>

In December 2010 I traveled to Zurich (Switzerland) to attend a PSM class (“Professional Scrum Master”) by Ken Schwaber. Attending the class was part of my journey towards becoming a Professional Scrum Trainer (“PST”) for Scrum.org. Ken had founded this new organization a year earlier, in October 2009.

In April 2010, at an event of the Agile Consortium Belgium in Brussels, I asked Jeff Sutherland about this new organization founded by his former companion. Jeff started by sharing his story of Ken’s dismissal from his position at the ScrumAlliance. He continued by saying that he (as a business man) liked that there were now two organizations to promote Scrum. However, what I remember most was how Jeff emphasized that he expected the bars would be raised for anyone aspiring to work with Ken and through Scrum.org.

It intrigued me. I had been closely following up on the emergence and growth of Scrum.org as it coincided with a personal process of professional recovery. I painfully discovered that I had been blinded by management ambitions (and promises) in 2007-2008. I realized that it had only lead me astray. I realized that Scrum was my way and that I needed to not only get back on track but also up my game. Go full throttle. I started focusing on delivering work with Scrum again and without much thought or considerations I did the PSM level I and level II assessments. (Fyi. What was level II then is now level III.) Based on my experience and achievements, Ken allowed me to move forward on the path of becoming a PST. I experienced it as an expression of “Individuals and interactions over processes and tools”.

At the time of the PSM class in Zurich, I was also starting to get deeply involved in the Netherlands as the Scrum leader of a large consulting organization. I started engaging with large organizations, often in the financials sector.

In April 2011, Ken came to Brussels for an event I co-organized for the Agile Consortium Belgium. Preceding the evening event, we spent the afternoon chatting in a Brussels hotel. By the end of our conversation Ken invited me to join his pilot PSPO class (“Professional Scrum Product Owner”) in Amsterdam a week later. My manager said “no” (referring to the PSM class I had already attended in December). After Ken offering a few discounts and my manager still refusing permission to go, I decided to take a leave, pay for it myself and attend the class in my personal time. It simply was an opportunity too good to miss.

Shortly after attending, I acquired my license to teach PSM and PSPO classes. As an employee of the large consulting company, guess who got the benefits from me being able to facilitate Professional Scrum trainings in a booming environment like the Netherlands? Still, nobody ever bothered to reimburse my costs. And I never bothered to ask. A matter of pride or a lack of courage?

Although it is not something I had planned for, it looks like in 2011-2012 I ended up being in the eye of the Scrum storm that was sweeping the Netherlands. In March 2012, Ken and I agreed on initiating and driving forward the first edition of a new event, which we called Scrum Day Europe. It took a lot of energy but it happened on 11 July 2012.

Towards the end of 2012, I realized I was combining three jobs:

  1. I was a Scrum trainer facilitating at least one and (at times) up to two classes a week. Most of my classes were in Amsterdam. Having given up staying in hotels (for personal reasons) that meant leaving my home in Antwerp around 5.30am and arriving back at home around 7.30pm for four days a week.
  2. I was the global Scrum leader and local Agile value proposition leader at our company. I was describing, documenting, presenting and trying to sell our approach and offerings of Scrum and Agile transformations. I was internally coaching and collaborating with coaches and Scrum Masters. I was the point of contact for consultants across the world.
  3. I was the course steward maintaining the PSM and PSPO courseware for Scrum.org, working with Ken Schwaber and Alex Armstrong. It consisted mainly of proposing, testing and implementing new ideas, new representations and new exercises.

I take my work seriously. I always have. I still need to learn to say “no”. I have a bit of what I would call an Atlas syndrome. So, I took all these three jobs seriously. I was spending more than 24/7 of my time. I was literally not taking any time off (not even the weekends). It wasn’t too sustainable (I guess).

I remember a Wednesday in March 2013. It was the day before a 2-day event for Professional Scrum Trainers organized by Scrum.org in Amsterdam. Ken and I spent another afternoon of chatting together, catching up and aligning. Two days later, the Friday evening after the internal event, we looked each other in the eyes and realized that it might be better for the both of us to start partnering rather than continuing our dispersed collaboration. Among many other considerations it would allow me to focus on sustaining and promoting Scrum via the Professional Scrum offering and it would allow Ken to reduce his traveling and other exhausting activities. On Sunday evening we had it all settled and I quit the position of Principal Consultant I had recently acquired.

While preparing to transition to Scrum.org, I accidentally created the first edition of my book, “Scrum – A Pocket Guide”.

It wasn’t until a few years later that I remembered the words of Jeff Sutherland of April 2010 regarding Ken’s new initiative and raising the bar.

Scrum, much like life, isn’t about finding it. It’s about creating it yourself. One can however not overlook the importance of accidents, coincidence, chance and luck along the way.

Keep learning.
Keep improving.
Keep…Scrumming.

Warm regards
Gunther Verheyen
independent Scrum Caretaker for Ullizee-Inc

Posted on by — 2 Comments

Product Owner. Not the Agile name for project manager, requirements engineer or other outdated functions.

The Product Owner in Scrum is accountable for the value delivered. Besides the fact that value is a very different driver than volume is (think outcome versus output), that accountability can hardly be demonstrated without a clearly identified ‘product’. Product is the vehicle to deliver value. Neither can a Product Owner be accountable and effective without a mandate to make decisions. Product Owner accountability cannot be mapped on existing roles or functions, nor can it be effectively enacted through deliverables and meetings dating from the industrial paradigm.

Although ‘product’ determines the scope, span and depth of Scrum, it is one of the most ignored considerations when Scrum is introduced. Organizations often introduce Scrum by constructing teams within existing departments and silo structures. The ‘Product Backlogs’ that they work off may be fascinating collections of work, but they are rarely for a…product. But how can you then know what the Product Owner actually owns? What purpose serves Product Backlog if not the single source of work to optimize for the value that a product delivers? What is it that releasable Increments are being created of when not of a well-defined product?

Without a clearly identified ‘product’ optimizing for value is hardly possible and Scrum is hardly used effectively.

When teams work within the confines of a traditional line organization, the highest achievable definition of product is often a part of a system, a component, a module or ‘something’ to be shipped to ‘someone’. Teams deliver work to other teams that in turn combine it with their work or the parts of the system, components or modules they produce. And other teams again depend on the work to be received from them. As the different teams often operate under different line management, it ends up with nobody minding the synergies across them, with nobody minding the actual product and the value delivered to end-users, with nobody minding how poorly Scrum is organized and employed. One might wonder where the courageous Scrum Masters have gone but in the end the effective use of Scrum is impeded by mapping it to the old delivery structures to keep producing the same parts and modules for the same sub-products in a series of open-loop systems rather than thriving on closed-loop feedback control.

The challenge is to know your product or service so you can start organizing your Scrum to best serve the people consuming it and the organization funding its development, while increasing the sense of accomplishment for the people performing the work!

After knowing the product, the mandate and autonomy of the Product Owner is the next tactical challenge to tackle. Is your Product Owner the best placed person to make business decisions or is your Product Owner a proxy, a distant representative, a temp like a project manager or some other intermediary? Are the decisions by your Product Owner fully supported or does your Product Owner have to check in with managers, directors or the steering committee before making a decision? Any decision?

Regardless, the minimal purpose of the Product Owner role in the Scrum framework is to inject and uphold the business perspective in the product development work. The Product Owner connects the worlds of (1) product management and the business side of the organization (think market research, sales, finance, legal, marketing), (2) the user and consumer base and (3) the delivery or development parts of the organization.

Connecting those worlds includes engaging with them to assure that all product management aspects and the wider business perspective are integrated into the actual development. In the other direction it allows the Product Owner to keep stakeholders and product management people up to date on the actual progress, so they can organize or re-organize their work accordingly. Being a connector is not the same as being a bottleneck. Product Owner, not information barrier.

Regardless, the Product Owner is the one person making the final call on the order of the work in the Product Backlog. Product Backlog shows all the work currently envisioned for the product, all work that potentially increases the value that the product delivers. Smart Product Owners show openness for great ideas whatever their source or origin and they gracefully employ skills of development people to convert product ideas and business solutions into requirements. Product Owner, not product dictator.

The Product Owner manages Product Backlog based on the product vision as a longer-term view of the road ahead. A product vision captures why the product is being built and why the product is worthwhile investing in. A product vision helps the Product Owner set or reset specific goals, hopes and dreams, express the expectations and ideas captured in the Product Backlog better and better order the items in the Product Backlog for value.

If anybody wants to know what work is identified and planned for the product, it suffices to look at the Product Backlog, at one artifact only. To understand what is planned for or what is in the product, and why, it suffices to ask the Product Owner, one person only.

Sprint Review is a great opportunity for a Product Owner to learn about the assumed or actual value that the product delivers. At the Sprint Review, (key) stakeholders, the team and (potentially) consumers or (key) users collaborate over what got done and what didn’t get done, what influenced the work and what was the purpose of that work. But value as the overall purpose is a very different driver than volume is. The purpose of Sprint Review is not reporting or justification of the amount of tasks executed and features implemented but sharing relevant information on usage and impact, competition and market trends; feedback that will help optimizing for value in the next Sprint(s). The goal is to collaboratively identify what is the most valuable work to do next for the product. This is evidently captured in the living artifact that Product Backlog is.

There cannot be any doubt that being a Product Owner implies expectations, skills and traits that go beyond those of a traditional requirements engineer, a requirements provider throwing work over the wall to developers or a similar proxy. Product Owner, actually, owns the product and is the owner of the product. Such ownership of a product implies strong organizational adoption of the role. It allows a Product Owner to act like a product-CEO (again, not a product dictator). That accountability cannot be mapped on existing roles or functions, deliverables and meetings. The role simply did not exist in the industrial paradigm.

Note. This article is based on texts that are taken from my current book-in-progress “The House of Scrum” (to be released in 2021).