Ralph Maria Jocham's Blog, page 23

The story of the book: “The Professional Product Owner”

The story of the book: “The Professional Product Owner”

How did I end up writing this book with Don McGreal? We have a deep love for product development in an agile and scrum environment. Within the Scrum framework, we both have a particular affinity for the Product Owner role

How it all began

It all started in 2015 at the Scrum Conference in Washington DC. Don and I were both at the conference and we sat down and talked about the Product Owner curriculum. We had some ideas about it, so we headed to a bar and discussed how we would teach the class. We took out our laptops and thought about values being the most important aspect. We quickly realised it doesn’t really work like that. We had to first talk about actual product management, then talk about value, and so on.

Developing the curriculum

After five days at the conference, we had only completed about half of our work on the curriculum. We continued to work on it for another three months – mainly over Skype. Once it was ready, we presented it to Dave West and Ken Schwaber at Scrum.org. They liked our work, and we became the stewards for the product owner training at scrum.org.

And so, we created this training and took care of maintaining it. Sometimes people discovered that there was something problematic on a slide or they had another idea to add to the curriculum, which we would then incorporate into the training.

Writing the book

Around 2016, I met with Dave West at Scrum Day London. We discussed product ownership and he mentioned that Ken Schwaber thought there was a need for a book about proper product ownership. I called Don that evening and asked if he was ready to write this book with me. He’d started a similar project before but had never finished it, so he agreed and we decided to give it a try and began writing.

It took us one and a half years from start to finish. It was an interesting process, and it was rewarding to finally hold our “baby”, the finished work in our hands.

And you know what? Our book has already been translated into simplified Chinese, South Korean, Polish and German, so I guess it’s doing a good job!

About Effective Agile

Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and also a Professional Scrum Trainer based in Europe.

As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #scrum.org certified courses.

If you’re looking to invest in training that transforms and empowers teams to successfully adopt #scrum or #agile, and create high-performance #productdevelopment environments leveraging the agile values and principles, visit https://effectiveagile.com/agile-scru...

If you would like to work with Ralph and company as an #agilecoach, #agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #agile #productdevelopment, visit https://effectiveagile.com/agile-tran...

For more great ‘how-to’ videos, blogs, and insights, subscribe to this channel and visit https://effectiveagile.com/blog/ for more valuable content.

#scrum #agile #scrumorg #scrumcertification #scrumcourses #scrumtraining #agilescrumtraining #agilekata #agility #businessagility #agileprojectmanagement #projectmanagement #productdevelopment #agileproductdevelopment #switzerland #germany #europe #scrumteam #scrumframework #professionalscrumtrainer #PST #certifiedscrumtrainer #certifiedscrumtraining

 

A strong business case for Scrum

A strong business case for Scrum

I’ve seen Scrum succeed in numerous projects and products across different industries. One particular case, however, stands out as an exceptional demonstration of Scrum’s effectiveness. Let’s take a look at the remarkable success story of Scrum implementation at Swiss Post.

The challenge
At Swiss Post, the team embarked on a critical endeavour – developing a scanner that would be used by 22 000 devices, serving around 20 000 postmen every day. The seamless functioning of these devices was vital, as any malfunction would disrupt the delivery process.

To add to the challenge, the project had a tight timeline of 12 months, with a target completion date set at 10 months. With seven organisations and multiple vendors involved, creating a cohesive and efficient workflow seemed like an uphill battle.

Creating the Scrum bubble
The key to the success of this Scrum implementation lay in the commitment and dedication of the people involved. We recognised the importance of approaching the project in a natural and agile manner. To facilitate this, we created a “Scrum bubble”: a controlled environment that allowed the team to operate autonomously, free from the constraints of existing structures, cultural mindsets and behavioural norms.

Within this bubble, the team embraced the core principles of Scrum, fostering a collaborative and iterative atmosphere that encouraged innovation and adaptability. The Scrum framework empowered us to embrace change, promote transparency and focus on delivering incremental value to the end-users.

A resounding success
The implementation of Scrum at Swiss Postal Services exceeded all expectations. Our team’s commitment, combined with the agile practices of Scrum, enabled us to complete the project within the challenging 10-month timeframe. The successful development of the scanner ensured uninterrupted operations, allowing parcels, signed letters and other mail to be efficiently delivered each day.

The project’s success was not solely due to Scrum as a methodology but also because the people involved genuinely wanted to approach the project in a natural way. We created a bubble that fostered collaboration, energy, and a sense of purpose. We could sense the energy and see how well Scrum was working for us.

What does this show us?
The Scrum implementation at Swiss Post stands as a shining example of how Scrum can drive project success. By creating a dedicated and autonomous environment, we were able to overcome obstacles and deliver exceptional results. Our commitment to Scrum’s values and principles, combined with the bubble we created, allowed us to work cohesively and achieve outstanding outcomes.
This success story emphasises the importance of embracing agile methodologies, creating an environment that fosters innovation and adaptability, and empowering teams to follow Scrum’s principles. Swiss Post showcases that Scrum can be the catalyst for exceptional project outcomes, no matter your industry.

About Effective Agile

Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and also a Professional Scrum Trainer based in Europe.

As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #scrum.org certified courses.

If you’re looking to invest in training that transforms and empowers teams to successfully adopt #scrum or #agile, and create high-performance #productdevelopment environments leveraging the agile values and principles, visit https://effectiveagile.com/agile-scru...

If you would like to work with Ralph and company as an #agilecoach, #agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #agile #productdevelopment, visit https://effectiveagile.com/agile-tran...

For more great ‘how-to’ videos, blogs, and insights, subscribe to this channel and visit https://effectiveagile.com/blog/ for more valuable content.

#scrum #agile #scrumorg #scrumcertification #scrumcourses #scrumtraining #agilescrumtraining #agilekata #agility #businessagility #agileprojectmanagement #projectmanagement #productdevelopment #agileproductdevelopment #switzerland #germany #europe #scrumteam #scrumframework #professionalscrumtrainer #PST #certifiedscrumtrainer #certifiedscrumtraining

When did you know that Scrum was an effective answer to complexity?

When did you know that Scrum was an effective answer to complexity?

Let’s start by describing the difference between complicated and complex environments. It’s so important to know the difference between the two that I always start an Agile consulting or Agile coaching engagement by asking my clients whether they know what complexity means.

Complicated versus Complex.Complicated

If you know more than 70% of the answer upfront and need a team of experts or deeply experienced professionals to figure out the remaining 30% of the solution, you’re in a complicated environment.

This is the domain of professions like accounting, civil engineering, or marketing.

Sure, it’s hard but you have a really good idea of what to do and how to achieve the outcomes you are looking for.

Complex

If you know 10% of the answer upfront and despite having a team of experts working on the problem or opportunity, you still don’t know if you will succeed moving forward, you’re in a complex environment.

In other words, the problem has never been solved before, nor has a solution ever been created and so there is no formula to follow. There is no predetermined path to success.

You must discover the answer through trial and error, and you are best served using Empiricism aka Empirical Process Control to achieve that.

Transparency: Make the work, hypotheses, and systems transparent.Inspect: Inspect the work that you are doing as well as the data that you gather.Adapt: Use the data and feedback to adapt what you are doing and respond appropriately.

It is incredibly important that my clients understand what complexity means because it provides them with insight into the implications of complexity and why we need to adopt a completely different approach and mindset to traditional project management if we are to succeed.

I highly recommend an article on Harvard Business Review titled ‘A leaders framework for decision making’, by David Snowden and Mary Boone, to understand the difficulties associated with navigating complexity effectively.

Complexity in Product Development.

In complex problem-solving or solution development, we have what is referred to as unknown unknowns. Things we couldn’t possibly know upfront but are almost certain to encounter as we move through the ideation and development of a solution.

As we encounter the variable, we stop to assess what has happened, what it means, how it impacts our hypothesis, and what would be the next best step we could take to make progress.

Because we don’t know all the answers or variables upfront, we need enabling constraints – guardrails or boundaries that prevent us from going over a cliff edge – to ensure that we navigate complexity effectively.

Scrum Framework

Scrum has these enabling constraints embedded in the framework to ensure that we continuously make problems and challenges visible, frequently inspect the work we are doing as well as the data and evidence that we gather, and regularly adapt or respond based on the knowledge, skills, and capabilities we have in that moment.

This is what we have learned.This is what we know now.This is what we think will happen if we do X,and this is how we will measure the success or failure of that experiment.

Simple. Effective. Empowering.

We don’t need to be right up front; we need to figure out what the right answer is at each step of our product development or product discovery journey.

Sprint Reviews.

I like to think of this as the freedom for the Scrum team to work autonomously, but every month they need to show us what they have built or what problems they have solved. So, although Scrum advocates autonomy, it comes with the responsibility of accountability.

Definition of Done

The definition of done (DoD) is another enabling constraint in Scrum.

How the team go about solving the problem or building the work is up to them, and as a product stakeholder or customer, you wouldn’t want to get caught up in those technical conversations. That said, you do get to specify what the acceptance criteria or definition of complete looks like before the team tackle the problem.

Quality requirements.Legal requirements.Compliance requirements.Testing requirements.Integration requirements.

And so forth.

Scrum enables the customer, product stakeholders, and product owner to determine what a great result or outcome looks like BEFORE the team bring the work into a sprint backlog.

Scrum as a great answer to complexity.

As soon as I began to work with Scrum, I immediately witnessed how powerful the framework is in giving teams a great starting point, regardless of how difficult or complex the problem is, and provides them with a framework to guide them through complexity effectively.

I love this quote from Dave Snowden, it really brings the challenges of complexity into perspective beautifully, and I often take a moment to let these powerful words soak deep into my mind.

“In complexity we manage the emergence of beneficial coherence within boundaries and that allows temporary, locally valid solutions to emerge.” – Dave Snowden

These are words to be savoured. To be considered. To reflect upon.

It provides a glimpse of how we might manage to navigate complex environments, and with the help of Scrum, even thrive in complex environments.

About Effective Agile

Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and also a Professional Scrum Trainer based in Europe.

As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #Scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #Scrum.org certified courses.

If you’re looking to invest in training that transforms and empowers teams to successfully adopt #Scrum or #Agile, and create high-performance #productdevelopment environments leveraging the Agile values and principles, visit https://effectiveAgile.com/Agile-Scru...

If you would like to work with Ralph and company as an #Agilecoach, #Agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #Agile #productdevelopment, visit https://effectiveAgile.com/Agile-tran...

For more great ‘how-to’ videos, blogs, and insights, subscribe to this channel and visit https://effectiveAgile.com/blog/ for more valuable content.

#Scrum #Agile #Scrumorg #Scrumcertification #Scrumcourses #Scrumtraining #AgileScrumtraining #Agilekata #agility #businessagility #Agileprojectmanagement #projectmanagement #productdevelopment #Agileproductdevelopment #switzerland #germany #europe #Scrumteam #Scrumframework #professionalScrumtrainer #PST #certifiedScrumtrainer #certifiedScrumtraining

 

 

When did you know that Agile was a great answer to complex engineering?

When did you know that Agile was a great answer to complex engineering?

As I’ve spoken about before, my journey to agile started with a quest for excellence in the software development space and evolved through a series of agile experiences and agile frameworks before I found my home in Scrum.

After leaving University, I followed engineering practices to the letter and sought to master technical excellence in my field through process, but it didn’t take long before I recognised that how I worked was just as important as the work I was delivering.

Doing what is required versus doing great work.

Following a process to the letter and leaning on solid, technical skills doesn’t lead to the best solution, it just ensures that you meet contractual requirements.

Knowing why a specific product or feature matters to a customer and how it will help them do a specific job, or achieve a specific outcome, helps provide you with the context that enables you to create something that truly delights customers.

eXtreme Programming

eXtreme programming deeply changed my belief system.

Before working with an agile framework, software engineering was largely about managing projects.

Checking the right boxes in the right order to get a sign off from a client.

A focus on making sure you didn’t get it wrong rather than a deep commitment to getting it right.

A radical shift in philosophy and mindset.

Encountering Agile is a lot like spending your whole life believing that the Earth is a disc and then having someone tell you that the Earth is a sphere. A part of you immediately discounts what you are reading because it is such a radical departure from everything you have ever learned.

It’s round?

Really???

And then comes the proof.

The irrefutable evidence that this approach to software development is a game-changer.

That is the moment that I believed. That is the moment when I knew that Agile is a great answer to complexity and software engineering.

The moment I started to see the difference between the quality of work I was producing using eXtreme Programming and the difference in customer satisfaction we experienced when compared to the traditional style of software development.

It was a deeply confusing initiation into the world of agile because I was drawn in two directions.

The old me wanted to stay nice and comfortable by checking the engineering boxes, and the new me was in love with everything I was learning and experiencing through eXtreme Programming.

It took a few months of moving between both worlds – the old project management style of getting work done and the new, dynamic and engaging style of agile software development – but then I fully committed to Agile and embraced that journey wholeheartedly.

The rest is history.

About Effective Agile

Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and also a Professional Scrum Trainer based in Europe.

As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #scrum.org certified courses.

If you’re looking to invest in training that transforms and empowers teams to successfully adopt #scrum or #agile, and create high-performance #productdevelopment environments leveraging the agile values and principles, visit https://effectiveagile.com/agile-scru...

If you would like to work with Ralph and company as an #agilecoach, #agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #agile #productdevelopment, visit https://effectiveagile.com/agile-tran...

For more great ‘how-to’ videos, blogs, and insights, subscribe to this channel and visit https://effectiveagile.com/blog/ for more valuable content.

#scrum #agile #scrumorg #scrumcertification #scrumcourses #scrumtraining #agilescrumtraining #agilekata #agility #businessagility #agileprojectmanagement #projectmanagement #productdevelopment #agileproductdevelopment #switzerland #germany #europe #scrumteam #scrumframework #professionalscrumtrainer #PST #certifiedscrumtrainer #certifiedscrumtraining

What is Scrum?

What is Scrum?

Scrum is a framework that enables product development teams to solve complex problems and build complex solutions.

Origin of the word Scrum in Scrum product development.

If you search for Scrum on Google, you will often find the Scrum framework process images, but the inspiration for the name Scrum comes from rugby.

A sport featuring 15 players on each team, 8 of which form the Scrum – also known as the forward pack – who are often the protagonists in driving the ball up field to help the team score points or focused on wrestling the ball away from the opposing forward pack to prevent that team from scoring.

That hustle and bustle of focused, committed energy to accomplish a valuable goal – as a team – is the inspiration for the word Scrum.

But this is not the whole story.

What inspired Scrum and its name?

A Harvard Business Review white paper called ‘The New New Product Development Game’ was written by Hirotaka Takeuchi and Ikujiro Nonaka in 1986, and in it the authors explored the reasons behind five (5) products becoming highly successful.

Five (5) products from completely different industries, from a copier machine to Honda (motor car), assessed to determine what each success had in common.

What were the primary reasons for that product succeeding despite fiercely competitive markets.

What they discovered was:

Interdisciplinary and self-organizing teams.Bottom-up knowledge, skills, and capabilities.Incorporation of rapid feedback loops.

These discoveries were described in a paragraph called ‘Moving the Scrum down field’.

This white paper was read by the cocreators of Scrum – Ken Schwaber and Jeff Sutherland – and it was a Eureka moment for them, independently. Something which made perfect sense in the context of software development and complex product development.

When Ken and Jeff were considering what to call their new agile framework, that word Scrum, and the concept of moving a team forward in the game of rugby, became the perfect way to frame their new product development framework.

So, the work of Takeuchi and Nonaka played an instrumental role in the inception and development of the Scrum framework.

What the Scrum framework means to me, as an agile practitioner and trainer.

I like to think of Scrum as the rules of the product development game, in a complex environment.

We bring a team of people together, and despite complexity and uncertainty, we play the game of solving complex problems and developing complex solutions as best we can. We may well be navigating unknown territory, but we can bring a torch and safety rope to help us move forward.
The rules of Scrum are applicable for any open ended, non-linear game.

Scrum is purposefully lightweight and incomplete.

It doesn’t tell you exactly what to do, but it is designed to help you leverage empiricism and cope with complexity using enabling constraints. Transparency, inspection, and adaptation are the pillars of Scrum. They allow you in rapid iteration cycles to help you discover the best way forward.

There aren’t many rules in the innovation space, but I like to think of Scrum as a set of rules that allow us to play the game effectively.

Values and principles, supported by a framework of events and artefacts, led by a trio of accountabilities to act as a rock-solid guide rope when navigating unknown terrain.

Unlike rigid, robust project management methods, the rules of the product development game are open to interpretation.

We don’t follow the rules blindly simply because a book tells us to, instead:

We develop a hypothesis based on the knowledge and understanding we have now.We design an experiment to validate or disprove our hypothesis.We do the work and gather data, feedback, and evidence.We inspect the data, feedback, and evidence to inform what we should do next.We adapt, based on data and evidence, and respond appropriately.

Scrum helps you build the most valuable product or feature given the constraints that are present in the environment. The best you are capable of, in that moment in time, with a solid commitment to improving with each iteration and growing product development capabilities on a continuous basis.

About Effective Agile

Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and a Professional Scrum Trainer based in Europe.

As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #scrum.org certified courses.

If you’re looking to invest in training that transforms and empowers teams to successfully adopt #scrum or #agile, and create high-performance #productdevelopment environments leveraging the agile values and principles, visit https://effectiveagile.com/agile-scru...

If you would like to work with Ralph and company as an #agilecoach, #agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #agile #productdevelopment, visit https://effectiveagile.com/agile-tran...

For more great ‘how-to’ videos, blogs, and insights, subscribe to this channel and visit https://effectiveagile.com/blog/ for more valuable content.

#scrum #agile #scrumorg #scrumcertification #scrumcourses #scrumtraining #agilescrumtraining #agilekata #agility #businessagility #agileprojectmanagement #projectmanagement #productdevelopment #agileproductdevelopment #switzerland #germany #europe #Scrumteam #Scrumframework #professionalScrumtrainer #PST #certifiedScrumtrainer #certifiedScrumtraining

How did you come to be the first Professional Scrum Trainer in Europe?

How did you come to be the first Professional Scrum Trainer in Europe?

That journey begins a very long time ago.

It started with my work as a programmer – software engineering – when I began to realise that the way in which you work is just as important, if not more important, than what you are working on.

At that point, we were very process driven.

We checked all the boxes from the requirements provided.The work was technically solid in terms of engineering practices.We tested the usability of the product with end-users and customers.

And so forth.

Our focus, back in 1998, was on meeting contractual obligations and making sure that we checked all the boxes according to the project management structures and procedures of the time.

It struck me that there must be a better way to create complex solutions, and my research led me to the Unified Processes (originally developed by Rational)

The Unified Processes is no longer popular and widely used today, but at the time, it was revolutionary and led me into the realm of approaching software product delivery differently and eventually to agile software development and the emerging practices and frameworks of that time.

Unified Processes

In the Unified Processes, customer or end-user use cases were the centre piece of software development rather than the system shall do requirements collection.

The use cases provided a lot of context and enabled me, as a software engineer, to think about why the work mattered, how it would enable a customer or end-user to do the things that most mattered to them, and what the primary focus of my solution should be.

I liked that.

I researched and embraced Unified Process as a better way of working and began to embrace the more agile style of working over the traditional project management approach. I worked with Unified Processes for a little over two (2) years before discovering eXtreme Programming.

eXtreme Programming (XP)

My research led me to a book about eXtreme Programming, which turned my entire belief system upside down because it challenged everything I had ever learned or believed about software engineering and product development.

Everything we know about Agile today was created back in the 1990s.

The emerging frameworks, philosophies, and pursuit of excellence was a radical departure from the strict engineering focus of software development at the time.

Concept of eXtreme Programming

The primary concept of Xtreme Programming is to move proven ideas to the extreme.

If we take this idea and move it to the extreme fringes, what would it look like?

An example of this might be testing.

Instead of testing the product or feature at the end of its construction, you would test it on a continuous basis to ensure that every single element of its construction was proven to work, in multiple scenarios, whilst you are actively building the solution.

A shift from development to test-driven development (TDD).

Once you have mastered that element of software engineering, you would recognise that integration of the solution is incredibly important, and so you would repeat the exercise by exploring the extreme fringes of integration.

Instead of building the product or feature, then testing whether it integrates into the working solution, you would focus on continuous integration and testing.

In software engineering, we used to refer to the integration testing moment as ‘plug and pray’ rather than ‘plug and play’. eXtreme Programming removed the element of surprise and uncertainty because it encouraged developers to continuous integrate and test the solution.

This concept of continuous integration and testing is now a standard part of the software engineering process, but at the time, it was revolutionary.

Just the continuous testing and integration elements of eXtreme Programming ensured that you had a significantly more sophisticated build pipeline than traditional project management processes, and with each iteration, you would increase the standards.

Customer Focus

The business element of software engineering had often been neglected in traditional project management because the focus was on contractual obligations rather than customer delight.

eXtreme Programming brought in the concept of an on-site customer.

Someone that a programmer could interact with and engage every day rather than at the end of the product development phase when they saw the product or feature for the first time. You could ask the customer:

What were they trying to achieve in their environment?What the most compelling problems were?What jobs were most important to them?Why this solution mattered?

And so forth.

Feedback and insight that could inform what you built and why you built it that way.

Context.

This customer focus was embraced by the cocreators of Scrum and incorporated into the Scrum framework in the form of a Product Owner, product backlog refinement with customers and product stakeholders, and the regular Sprint Reviews where customers and product stakeholders met with developers to provide feedback on what had been built and what the team would attempt next.

Code Reviews

Technical debt – the work you have to go back and rework to improve its quality and functionality – is a massive problem in high-pressure software development environments.

Traditionally, a project management team would cut corners and build as fast as possible to make sure they met project deadlines and operated within cost constraints, but the product would have a significant amount of problems beneath the surface.

Problems that wouldn’t be addressed because as soon as the product was delivered, the software developers would move onto the next thing, and nobody would be able to communicate with the original software development team about what was done, why it was done that way, and what needed to happen to resolve the problems that were accumulating because of the technical debt.

eXtreme Programming focused on continuous code reviews rather than a single review once in a while. It brought technical excellence sharply into focus and ensured that product development teams were accountable for delivering the highest quality work, every day.

This focus on continuous code reviews lead to the idea of pair programming.

Pair Programming

Pair Programming – where two people code together as a pilot and co-pilot – was born out of eXtreme Programming and the quest for technical excellence in software development.

The desire to eliminate technical debt and deliver the highest quality solution regardless of whether the team would be focused on the product in future or moving onto a new product or project.

Laurie Williams wrote a book about Pair Programming – Pair Programming Illuminated – that demonstrated why pair programming is so successful and how it is a game changer for organizations seeking technical excellence and improved product quality.

And so, it’s a common practice to this day and something I personally like and encourage.

The journey to PST (Professional Scrum Trainer)

As you have seen, I started early on to actively seek out more agile ways of working and actively embraced emerging agile (engineering) practices, processes, and frameworks. Things which I could incorporate in my work as a software engineer and deliver a high-quality, high-impact solution for my clients.

I witnessed the power of Agile, and especially Scrum, in creating high-performance environments that placed people, customers, and the quality of their experiences at the heart of their product development philosophy.

Project Management tended to be about delivering against a contractual obligation with the sole purpose of following the plan and being paid, whilst agile explored the entire value stream – from concept or need to customer satisfaction – and sought to make that experience and product delivery as effective, humane, and rewarding as possible for either side.

Happy product development teams + happy customers = successful organization.

I had implemented agile values, agile principles, and agile frameworks with my teams and seen:

Less problems in the environment.Improved time-to-market.Improved quality.Greater customer satisfaction.Greater employee satisfaction.

In my mind, as a software engineer as well as a business leader, the business case for Agile was significant and I continued to explore emerging agile frameworks and practices to improve.

In 2002, I discovered Scrum.

The combination of Scrum and eXtreme Programming proved highly effective, and I embraced Scrum as a powerful product development framework and set of practices. It proved itself incredibly valuable and effective, and I wanted to help others discover the power of Scrum to help them achieve their business, product development, and Human Resources team member objectives.

I wanted to play an active role in building the next generation of agile practitioners and developers.

I convinced my manager to send me on official Scrum training through the Scrum Alliance, and built up my knowledge, skills, and credentials in the Scrum environment.

Two years later I became a Certified Scrum Professional (CSP) and it struck me that I had a lot to contribute to the Scrum community as a coach, a mentor, and a trainer.

I had the practical experience, I had actively worked with Scrum and worked with teams to successfully adopt the framework, excel in product development using the framework, and to continuously improve and adapt using the framework.

It made sense to explore the Certified Scrum Trainer (CST) path through the Scrum Alliance and I began to prepare for that journey. I reached out to Ken Schwaber – the cocreator of Scrum – personally and actively requested to become a member of the Certified Scrum Trainer community.

Scrum.org

At that time, Ken Schwaber and the Scrum Alliance were parting ways and Ken was building www.scrum.org as the second certification and skills development body for Scrum which at the time had a strong focus on sophisticated agile engineering practises like eXtreme Programming.

Scrum.org created the Professional Scrum Trainer (PST) certification and licensed trainer credential, and it made sense to pursue this path because I liked Ken, I liked what Scrum.org represented, and I liked their commitment to providing the highest standards of Scrum training possible.

I worked with Ken through the process of becoming a Professional Scrum Trainer, which is very much about demonstrating knowledge, skills, capabilities, and deep experience in Scrum environments.

At that time, a handful of deeply experienced Scrum practitioners came together to certify as a Professional Scrum Trainer (PST) and I was fortunate to be a part of that early group, leading to me becoming the first Professional Scrum Trainer in Europe.

As part of my ongoing and continuously evolving relationship with Scrum.org, I also worked with a small team to create the Professional Scrum Product Owner (PSPO) course for Scrum.org and continue to play an active role in helping to improve the learning experience and grow capabilities in Scrum Masters, Product Owners, and Scrum Developers around the world.

About Effective Agile

Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and also a Professional Scrum Trainer based in Europe.

As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #scrum.org certified courses.

If you’re looking to invest in training that transforms and empowers teams to successfully adopt #scrum or #agile, and create high-performance #productdevelopment environments leveraging the agile values and principles, visit https://effectiveagile.com/agile-scru...

If you would like to work with Ralph and company as an #agilecoach, #agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #agile #productdevelopment, visit https://effectiveagile.com/agile-tran...

For more great ‘how-to’ videos, blogs, and insights, subscribe to this channel and visit https://effectiveagile.com/blog/ for more valuable content.

#scrum #agile #scrumorg #scrumcertification #scrumcourses #scrumtraining #agilescrumtraining #agilekata #agility #businessagility #agileprojectmanagement #projectmanagement #productdevelopment #agileproductdevelopment #switzerland #germany #europe #scrumteam #scrumframework #professionalscrumtrainer #PST #certifiedscrumtrainer #certifiedscrumtraining

In Scrum, what is the Increment?

We have a Product Owner, a Product Goal, and a Product Backlog in Scrum.  Why don’t we have a Product but an Increment?

The answer is both historical and essential.

Scrum started as an iterative and incremental approach for software product development.

OOPSLA 1995 Scrum Paper:
SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development cycle. 

Scrum Guide May of  2009:
Sprints deliver an increment of the final product that is potentially releasable. 

The differentiation between product and Increment is important as an Increment might become part of the product if it fulfils all the aspects needed for verification and validation.
In my opinion the biggest problem with the Increment terminology is based on the fact that word Increment is used both in singular (one) and plural (many) in all of the Scrum Guides.

Scrum Guide 2020:
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint.

Let’s untangle the confusion with a simple metaphor.

Soap-Bubbles

Have you ever been to a children birthday party or a circus where there was a show with soap-bubbles. Keep the image of soap-bubbles in your mind.

The product (I’ll explain product in a minute) which is already being used by your customers would be a large soap-bubble as shown in Figure 1.
During the Sprint Planning the Scrum team defined a valuable Sprint Goal, created the corresponding Sprint Backlog consisting of for example 8 Product Backlog items.

Scrum Guide 2020:
The moment a Product Backlog item meets the Definition of Done and Increment is born.

As shown in Figure 2, next to the existing Increment many smaller Increments are created during the Sprint.
Done implicitly includes that all acceptance criteria have been fulfilled (see my other blog [1]) as well that it works with the existing Increment. None of the previous functionality may be broken. Additionally, there might be other items you might need to address through your Definition of Done. Think regulations and governance.

Scrum Guide 2020:
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.

Figure 3 visualises the moment the freshly created Increment is validated and verified with the existing Increment.
If one of the tests of the new small Increment would fail to fulfil any point of the Definition of Done it would not be integrated into the Increment.

Scrum Guide 2020:
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Once the Definition of Done is fulfilled the new Increment gets absorbed into the existing Increment and thereby making it grow as shown in Figure 4.
Now you know why it is called Iterative and Incremental product development.

The moment the Increment is placed into the hands of a user, it becomes the product.
The Increment(s) are internal, the product is external in the hands of the users.

[1] https://effectiveagile.com/product-ow...

Product Owners, You do NOT Accept the Work in the Sprint Review

In 2001 Ron Jeffries coined the 3Cs acronym[1]. 22 years later it is still more then current and relevant, especially in a Scrum context, even though it originated originally in eXtreme Programming.

Card, Conversation, ConfirmationCard

The card can be either a physical card or a ticket in an electronic tool. It is the place where the Scrum Team writes (a strategic Product Owner delegates much of the work to the Developers) down all the relevant information for a Product Backlog item.

Scrum Guide:
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

Conversation

This is where the Scrum Team and even stakeholders talk about the anticipated objective of the Product Backlog items in regards to the anticipated Sprint Goal. How success is defined, what is important, what needs to be considered, what has to be done, what must not be done; often described as acceptance criteria. The insights of the conversation(s) are written on the card. In Scrum, this would usually happen during refinement.

Scrum Guide:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Confirmation

Confirmation has several tiers, ensuring that the created increment is releasable and provides value.

Tier 1:

All the acceptance criteria have been fulfilled, best if some of your users perform the acceptance testing. In an advanced state Product Backlog items would subsequently be verified and validated through test automation (think Continuous Integration based on TDD and Specification by Example)

Scrum Guide:
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
[…]
Multiple Increments may be created within a Sprint.

Tier 2:

The Definition of Done (describing releasable) is fulfilled. Best done as a pair of developers to make sure no corners have been cut.
Consider Tier 1 as an implicit part of the Definition of Done.

Scrum Guide:
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
[…]
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
[…]
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Tier 3:

The Product Owner accepts the work during the Sprint, thereby making it potentially releasable.

Scrum Guide:
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Only work which fulfills tier 1, 2 and 3 can be demonstrated in the Sprint Review. You can consider the work as Done from the Scrum Team’s perspective.

Scrum Guide:
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Tier 4:

The Scrum Team makes the work of Scrum Team transparent to all stakeholders. It is about creating full transparency. If there is pushback for any work (PBIs) completed, the work moves back into the Product Backlog.

Scrum Guide:
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

From Card to Confirmation. The shorter the time frame (think about 2 Sprints) the more you focus on customer value with vertical slices of functionality – Moving away from a project to a product mind-set.

[1] https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

Agile Done Right eliminates the need for classical Requirements engineering.

'Requirements engineering is the process of eliciting stakeholder needs and desires and developing them into an agreed-upon set of detailed requirements that can serve as a basis for all subsequent development activities. The purpose of requirements engineering methodologies is to make the problem that is being stated clear and complete, and to ensure that the solution is correct, reasonable, and effective.'(1)

‘Stakeholder needs‘ seem strange. Sure, we have stakeholders but in the end we only have to make sure that we satisfy the needs of our users. (users are a type of stakeholder). ‘Clear and complete … to ensure that the solution is correct …‘ is another interesting choice of words; I would be reluctant to claim that my requirements are clear and for sure, never as complete. How can we ensure correct? We are not solving a mathematical equation but are designing a solution for a customer who does not yet know what they want, in a technology we don’t yet understand in an environment which is changing(2). Regardless of how much you polish your crystal ball, there is always volatility, uncertainty, complexity and ambiguity. Welcome to the VUCA(3) world.

The outcome of RE for software products is documentation. What is the intention of this documentation? It’s about codifying knowledge by persisting information. You can read them months or years later and still get same meaning. Well, too bad that writing down and reading is a very lossy process. So, the meaning gets often twisted.

So why do we do it? It’s historical. In the past we worked in sequence: Planning, Analysis, Design, Implementation, Testing, Release. The first activities where all about eliciting needs, phrasing them into requirements and then cast them into specifications which were then handed over to the programmers in the IT department. Once they were done the complaining and finger pointing started. Product discovery and product delivery are clearly separated.

Agile to the rescue (check out the principles in the Agile Manifesto(4))! Instead of being driven by activities, where we plan everything, analyse everything, design everything, …. (interesting that we do all the planning in the beginning even though we know the least – but that is another post) with Scrum we are driven by maximising value for our users. Combining product discovery and product delivery. We slice vertically, we do all of the above activities within one Sprint. A little planning, some analysis with design sprinkled on top. Instead creating documentation we create a real working software product which is demoed at the Sprint Review to our stakeholder as well as users. The important benefit about this approach is creating a shared mental model by having enough conversations with all parties involved: Product Owner, Developers (covering all required skills like: programming, testing, business analysis, ux, …) as well as users if needed. The information we create is often written into User Stories (in case you don’t know, the definition of a User Story: It is a promise for a conversation to take place(5), it is about the talking, less the writing). The conversation creates the cognitive alignment which allows us to pull together into the same direction. Ron Jeffries put it perfect with his Card, Conversation, Confirmation model. (6)

In short: We have conversations with the right people, our findings are written down on a card (including acceptance tests). Confirmation makes sure it works correctly  and is accepted by the users (verification and validation). A full vertical slice of product discovery and delivery, just in time – Lean RE.

If you are about to say, ‘We need documentation, because …‘, don’t worry, I’ve good news. For this Scrum has the Definition of Done (DoD). A DoD might require that there is a requirements document, specification document, architecture document, test  document, operations document, … well then all these documents would be kept up to date each Sprint in parallel with the usable product. What’s even better, as the documentation is created after the work has been completed, the document tends to be correct not in need of rework (which usually never happens). This can be even applied in a regulated environment.

(1) https://www.sciencedirect.com/topics/computer-science/requirement-engineering

(2) Alistair Cockburn

(3) https://en.wikipedia.org/wiki/Volatility,_uncertainty,_complexity_and_ambiguity

(4) http://agilemanifesto.org/principles....

(5) Alistair Cockburn

(6) https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

Scrumday Germany – Product Management at Scale – The 5Ts

Title: Product Management at Scale – The 5TsYear: 2022Location: Stuttgart

Abstract: With all the different scaling options that exist today, it may seem like there is very little agreement on how to scale the Product Owner role. Ralph, (and Don not at the conferee though) authors of the best selling The Professional Product Owner book, will introduce five Product Owner Delegation Models that can guide you regardless of what scaling framework may be in place. Depending on your context, they can be implemented individually or combined. You will leave with a better understanding of the role of Product Owner and what their true focus should be, especially at scale. You will also leave with a way to map each model to your existing structure. This session takes a scaling framework agnostic approach to the Product Owner role. We really want people to take away practical advice that can be applied no-matter their situation. This is done by introducing Five Delegation Models (5Ts): * Tactical Delegation Model – have others help manage the Product Backlog and other tactical things * Technical Delegation Model – build your work into the product *Team Delegation Model – delegate to the team members, let them talk to customers * Temp Delegation Model – assign a representative to each team until the teams are self-sufficient * Theme Delegation Model – create representatives (SMEs) for different product areas that teams can consult

Get the presentation