Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / DevOps / Agile

Boris Gloger on SCRUM 3.0

4.89/5 (2 votes)
22 Jun 2016CPOL5 min read 12.5K  
In early June, Boris Gloger gave a highly inspiring talk about current tendencies in the agile community in Munich, Germany. I want to share three topics, that, for me, were most important ones.

In early June, Boris Gloger [^] gave a highly inspiring talk about current tendencies in the agile community in Munich, Germany. Boris' talk, titled SCRUM 3.0, he shared experiences with SCRUM in real industry projects and which practices he saw working or failing.

39; talk covered a long list of topics. Here, I want to share three topics, that were most inspiring to me.

SCRUM 3.0?

Since the release of Schwaber's and Beedle's book Agile Software Development with SCRUM in 2001, 15 years have passed. The popularity of SCRUM arose during these years, as it got implemented by development teams in variant projects in different companies – from start ups to international corporations – in different countries.

The agile community learned a lot from these projects over the years. Boris talked about coaching SCRUM teams today and where he does not stick with the practices of the original (say old) SCRUM books – although he recommends focusing on the original SCRUM values. This "upgrade" of SCRUM is named SCRUM 3.0.

The Product Owner – Focus on Value and Vision

In SCRUM, the Product Owner is responsible for the product's value. His or her business is to align all resources to developing a product that creates the most benefit possible for the company. Most often this equals generating cash flow, sometimes it can be improving brand image, increasing market share or similar. This was, is and will be the first priority of the Product Owner.

Following the old books, he or she will do this by writing User Stories, prioritizing them in a Product Backlog and introducing them to the team in a Sprint Planning 1 session. Experiences of the last years have shown, often teams do not need to be fed with detailed User Stories. They know the details of technologies and the product under development much better than anyone else, including their Product Owner. When they understand users and their needs as well (we'll come to this in a moment), they are much faster and more efficient in detailing rough thoughts into well-prepared User Stories.

What the team needs from the Product Owner is something else. They need someone focusing on the Product Vision. Someone who can mirror concrete problems against the big picture of the product. As a Product Owner, you should at first provide two things to your team:

  • A Vision. A vision how the product should influence users, the company and probably even society.
  • Constraints. Which constraints have to be complied with to launch this product in the planned setting / environment / industry?

The Development Team – Bring together skilled people

The setup of a cross-functional development team, described by Boris Gloger:

Quote:

Bring together the people with the skills needed to solve this problem

Your cross-functional development team should match team members with a broad variety of education and experience to come up with all the skills needed to get the job done. This is not limited to typical developer topics. If you have to test your product (in most cases you will) – put a test expert on the team. If you have to promote and advertise your product (in many cases you will) – put a marketing expert on the team. By working together in the same team, these people cannot only reduce development time ("Still waiting on the input from marketing department :( "), they can also easily share their knowledge, educate themselves and reduce additional work for both sides.

The Source of User Stories – Understand your User

When launching the development of a new product, one of the hardest missions is to get a clear and detailed understanding of the future result. Boris Gloger described a typical project kick off like this: >

Quote:

"How should the new FooBar look like?"

– "We want all features of the old FooBar, plus X"

"Ok, and how should X look like?"

– "Well, can't you tell me? You are the expert."

Detailing requirements for the new product is neither extremely easy nor extremely enjoyable. In addition, there are many uncertainties, how concepts will work out during development. All this makes those requirements specifications less clear, probably inconsistent and very often lacking an inadequate level of details (sometimes too much, sometimes too little).

In an agile development culture, development teams does not need a most detailed requirements analysis or a maximum populated Product Backlog. Upfront, they need some orientation were their effort should lead to (remember the Product Owner and his or her Product Vision). The best way to get detailed requirements is to work them out with real end users during the development process while the product emerges.

The development team needs direct contact to real end users. In need of detailed requirements? Have a look at the current solution and how an user interacts with it. Uncertain about how to solve a specific problem? – Build a thin prototype and test in with real users. A feature is done? Deploy it and test it in real environments: Does it (technically) work as expected? Does the user use it in the intended way? Which side-effects occur, that were not taken into accounting – And can they benefit the product? Does it have the planed impact on the product as a whole? Especially this last step will give you important feedback to improve your understanding of the users' problems and how these influence the success of your product.

tl;dr

With his idea of SCRUM 3.0 Boris breaks with some established practices of today's SCRUM, like the task division between Product Owner and developers. But he remains consistent with the underlaying SCRUM values [^]:

  • Focus
  • Courage
  • Openness
  • Commitment
  • Respect

He drew an inspiring but challenging vision, of how to collaborate in agile, lean companies. The discussions during and after the talk made clear, there is still a long road ahead. Especially for traditional project management structures, some essential adoptions will not be easy.

Credits + References

  • Thanks to Agile Munich [^] for hosting this great event.
  • Here I found some notes by Sebastian Radics [^] about an event with Boris Gloger in Berlin, Germany in December 2015. Although this was a different talk, many topics and details sound familiar.

History

  • 20th June, 2016: Initial version.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)