Area of Collaboration: Product Owner and Team

Saturday morning 10:00 in Karlsruhe, Germany. Last event of XP-Days 2009: community day with a very well moderated World Café. All input for this posting was created in a 20 minutes timebox with four random conference attendees including myself as host of the table.

The initial question was: "Does a Product Owner need technical skills?"

We came to the conclusion that the break-down process from product vision to detailed, small user stories may require not only business and domain know-how but also some amount of technical understanding. In theory this should not be the case but experience shows that on a very detailed level of user stories it may happen that technical issues need to be discussed: the smaller the story, the more technical it gets.

Theorem: The technical scope of a user story is reciprocal to its business scope.

This led to the follow-up question: "How many business know-how does the Team need?"

For best collaboration it is obviously required to maximize both the Product Owner's technical skills and the Team's business know-how. The more both parties understand of each other's field, the better does the break-down process work to get small user stories.

Following image was drawn on our World Café table to illustrate the theory.

The image shows an ideal situation. Both the Product Owner and the Team have very high skills and know-how so that maximum collaboration is possible. All the way of breaking down the product vision into small user stories can be a collaborative effort with best results.

We now can define four points in space which made up the so called Area of Collaboration:

1. The Product Owner's position with her strong business expertise.
2. The intersection of the Product Owner's level of technical understanding and the break-down transition. This is the point within the break-down process up to which the Product Owner is able to collaborate.
3. The Team's position with its strong technical expertise.
4. The intersection of the Team's level of domain and business know-how and the break-down transition. This is the point within the break-down process from which on the Team is able to collaborate.

Following image illustrates the Area of Collaboration for an ideal situation. In such an ideal world the team can be fully involved right after the first vision of the product is born. This is the wanted condition of understanding and collaboration!

The less know-how either party has of the opposite field of expertise, the smaller is the area of collaboration. In typical project organizations the know-how is restricted to a low or medium level. This leads to split-up efforts: first a lonely Product Owner breaks down her vision into epic stories forming the big picture of the product. Then some collaboration of Product Owner and Team breaks down into smaller stories and this is the part to brief the Team so that it gets a broad understanding of the business values. In the third step the Team must break down into most detailed stories on its own, as the Product Owner does no longer fully understand the technical issues to be discussed. This is the dangerous part which can lead to misunderstanding and wrong product decisions.

But things can be even worse. Image a Product Owner and a Team who both do not have any common know-how and understanding. The Product Owner breaks down her vision into stories without any involvement of the Team. Then the Team takes over and breaks down into detailed stories without any collaboration with the Product Owner. That kind of approach has great chance to get lost.

Conclusions

• The Product Owner needs at least as much technical skills to understand the Team's break-down into detailed user stories.
• The Team's domain and business know-how is even more important than the Product Owner's technical skills! If the Product Owner lacks technical understanding the Team has to compensate with domain know-how.
• 
  A goal for every agile team should be to reach the ideal, maximum area of collaboration.
• As agile coach, mentor, or Scrum Master you should determine the respective know-how and skills of Product Owner and the Team. Handle low values as impediments instantly and increase the area of collaboration.

Final rule: Make the Product Owner and the Team work together from the very start of the project!

Teach Scrum 6 Times!

We had a really nice Open Space session with Alistair Cockburn at the community day of XP Days 2009 in Karlsruhe, Germany. As the concept of Open Space was just too restricted for Alistair, he simply invited to "Whatever U want 2 talk about" what I'd like to define as Open-Open Space.

After several topics we started to talk about energizing teams and how to do this. The group mentioned good examples of situations when a team was able to show energetic motion.

We finally found the solution and the underlying method to trigger a team's energy and make it self-explode into a hyperproductive state! This is a quantum leap in agile team driving!

Take a look at the whiteboard Alistair is pointing at. The third line from the top shows the overwhelming truth:

Teach Scrum 6 times ("Repeat Yourself")

(Note: this post is pure nonsense. Do NOT teach Scrum 6 times to the same team or you will burn in hell.)

It's just that easy: if you're coaching or mentoring a Scrum team then simply teach Scrum 6 times to that team and it will suddenly jump into hyperproduction for sure!

The underlying principle and general method is "repeat yourself". "Repeat yourself" itself is an iterative process that should be timeboxed for maximum effectiveness. With the theory of dialectic constraints it can be proven that "repeat yourself" will lead to pure truth in the receiver's processing unit after infinite repetition.

Fortunately Scrum is such a reduced and simple framework that 6 iterations are enough for any team.

Try this and be surprised of its simplicity! Should you run into any problems with this approach, you should go on, try harder, and inspect and adapt as always.

Remember, if things do not work well it's always human failure due to the first tenet of the agile manifesto: humans and interactions over processes and tools. Humans err, processes and tools don't!

(Note: if you really didn't get it, this post is pure nonsense. Do NOT teach Scrum 6 times to the same team or you will burn in hell.)

ScrumBut: Method Picking

After two conference days I attended several sessions and talked to lots of people. It is amazing how many claim to do Scrum but mention following typical statements:

"How should I change Scrum to fit into my organization?"
"With which part of Scrum should I start?"
"There is no Product Owner in our team, we don't need one."
"We don't do Sprint Planning because we planned all project phases at the beginning and execute that plan in 3 week sprints."
etc.

This is the wrong way! If you pick a few single methods or practices of Scrum the result will not be Scrum.

Or as Jeff Sutherland said: "You may change anything in Scrum but don't call it Scrum!"

One may argue this is just another dogmatic restriction of Scrum. Let's find out why it makes sense to leave Scrum as is.

Think generally about your team's definition of done. Everyone of your team is able to understand what you mean by saying "this story is done." It is just useful to have such a common basis of understanding. Now replace "done" with "scrum" and extrapolate your team to the rest of the world. The definition of Scrum is based on its roles, activities, and artifacts as described in the Scrum Guide or any other serious book on Scrum. Everyone in the world with such knowledge of the Scrum framework will understand what you mean by saying "we're doing Scrum." Take a look:

"done" = done

"Scrum" = Scrum

"not done" = not done

"not Scrum" = not Scrum

"I'm almost finished with this task" simply means "not done".
"We're using only a few things of Scrum" simply means "not Scrum".
It's that easy.

There is no binary black-white scale, of course. In the beginning of your transition to Scrum you will see many things that won't work as scrummy as intended. The important point is not to exclude these things right from the start of your transition. Always start with the full Scrum set even if nothing is working well. Go on, learn, inspect and adapt - with good mentoring and coaching your team will improve soon enough even if you think that is not soon enough.

Pedantic Coders: Warnings are Waste!

Some days ago I had a discussion with a Scrum Master, a Project Manager, and the team leader of a bunch of developers. We talked about an upcoming big project and how to guarantee high quality output right from the start.


At one point in the discussion I thumped the table and raised my voice:
"No, I do not want to see a single warning! If there is a single tiny warning I will declare the result invalid and failed!"


Everybody looked at me wondering about such a hard call. Let me explain why my request is so important:

Any Warning is Pure Waste!

Imagine the typical logging mechanism in your software. As your system grows your logging output grows in parallel. If there are several developers working on that system anyone of them at some point needs some private debug logging. Or maybe some informal output is written to the log files of the running software.


Now imagine the guys working as administrator, service technician, or customer service manager. What do they expect of this software in their specific role? If the customer did not report an issue, they expect an empty log file, nothing else! Every single line of informal or warning message would be pure waste for them.


The system has to write output only if there really was a problem the user could experience. This is a general constraint of software architecture and design your developers have to take care of.


Now we come to the deeper and underlying reason of my request: your compiler must not show a single warning!


"Yes, in theory, but we have old legacy code. And there are always language specific things that just throw a warning."


Don't allow yourself and your team to be that lazy! No, there is not any reason to let your compiler talk to you. Your compiler has to be silent. If it really wants to raise its voice, the message has to be of major importance! Any other gibberish compiler output is pure waste and distracts from important things.


"If you really want this, we could suppress all warnings in the compiler settings."


No, stop, you didn't get it yet! My request is not about hiding important messages, it is about avoiding important messages. Any compiler warning your code produces is an important hint to a possible defect in your code. In my point of view a compiler warning has an even higher priority than a red unit test.


Go and fix your code! Make it beautiful and clean. And let your team define a working agreement or even include in the definition of done as follows: "Code producing any compiler output is not done!"


I don't know why lot of developers do not have the attitude to be a pedantic coder. Maybe modern developers have lost that discipline because they got too used to deal with uncompiled scripting languages. Maybe they simply lack the knowledge of handling any theoretically possible error situation in their code. Back in the old days when I took a system programming course at university, we had to prove our skills by executing this command:


   gcc -ansi -pedantic mysource.c


You should do the same nowadays by applying following rules:

• Never suppress compiler messages
• Analyze every compiler output and take a deep look at your code to avoid that output
• Handle any theoretically possible error situation in your code, or to be more precise:
• Handle any theoretically possible error situation in your code even if you think it will never happen

Be a pedantic coder and do not allow warnings!

Be lean and remove waste!

Inspect and adapt!

Book: Taiichi Ohno - Toyota Production System

Everyone interested in historic basics of Scrum and other agile approaches should read this book.

Author: Taiichi Ohno

Title: Toyota Production System

Taiichi Ohno - Toyota Production System: Beyond Large-Scale Production

Rating: recommended

If you want to understand several basic principles of Scrum and other agile approaches then take a deeper look at Taiichi Ohno's book. He describes the historic development of all those famous Toyota principles one can see adopted in many agile frameworks:

• kanban
• just-in-time
• five why's (real cause)
• production leveling
• visual control (management by sight)
• waste recognition and elimination

All of this was started some 80 years ago by the visionary Toyoda Sakichi and brought to perfection by his successor Toyoda Kiichiro. The book shows some insight how these people thought and managed their organization. It also covers some economical history of the competitive automobile markets of Japan, Europe, and the USA in the first half of the 20th century.

Overall the book does not unveil the deep details how to implement a Toyota-like production system but it gives great background information why and how this system was invented with all its principles and practices.

The appendix "Glossary of Major Terms" is a nice reference of all important concepts.

Lose Customers with Disorganized Workflows

Last week my wife and me went to the traditional Saint Martin Procession with our son. It was a nice walk with all those gleaming hand laterns of the kids. The walk ended at a school were the local music society had prepared some food and beverages. Ordering and delivery was organized as follows:

• At the cash desk customers have to buy vouchers for specific food and beverage
• One person works at the cash desk
• Left of the cash desk all beverages are handed out
• Three persons are in charge of handing out the beverages
• Right of the cash desk all food is handed out (french fries, German "Bratwurst", stuff like that)
• Four persons are in charge of handing out the food

When we arrived at that location I hurried to the cash desk only to append myself to a long row of approximately 50 people waiting. After 5 minutes there were still 40 people in front of me.

There were several severe problems in the way of organization:

• Only one person at the cash desk. Maybe a single resource would have been able to handle the queue of people but unfortunately this person was the slowest imaginable.
• No team work. All the resources had been strictly assigned to their specific stations. No one was able or willing to help at another station to deal with overloads.
• No one-way routing of customers. After the cash desk first you had to decide to move left or right and cross the row of people in front of the cash desk again to go to the other side.

It really was a mess and I analyzed all these problems within the first minute of waiting. If they only would have organized their work order with a simple kanban, everyone would have been happy with a faster delivery of finished orders to the customers.

We finally decided to abort this experiment after 15 minutes, walked away and got something to drink at home. So my conclusion is: disorganized workflows loses customers.

The Untrained Team

"Patience. Discipline."

Undead NPC, Undercity, WoW

Successfully getting to Agile requires two important abilities -- patience and discipline:

Patience of the ScrumMaster to let the team self-organize and learn to improve. This may sound contrary to the drive-driven personality a ScrumMaster must have. But it is important for every driver to power up an engine and just let it run on its own from time to time.

Discipline of the team to stay focused at self-organizing and improving. This may sound contrary to the good mood Scrum creates. But discipline is needed both on a personal and team basis. It is barely possible to succeed with test-driven development, pair programming, or continuous integration without discipline.

Now here is the issue: how to deal with missing discipline?

Two answers depending on the underlying root cause of missing discipline: either fire them, or train them!

If discipline is missing simply because team members do not want to be agile you should consider to break up with these guys.

If discipline is missing because team members do not know how to be agile you have to mentor, guide, and train them. It is not enough to give your team an one hour up-front presentation and tell them "you have to write unit tests for everything now because we have it in our definition-of-done." A developer without knowledge and experience how to write good unit tests will get lost. She will try to test the written code afterwards and you will hear statements like "no, I can't write unit tests now because the implementation is not finished yet."

Another fruitless approach is to tell your team "we will do continuous integration now because we are agile." It won't work as long as the team does not know how to integrate continuously on a daily basis. Developers again will get lost mentioning "yes, of course we will integrate but we have to wait for the three stories in this SVN branch to be finished before we can do so."

Do not wait any longer, act now! Your developers will fall back to old, traditional, waterfallish behavior. This will destroy huge parts of the team's success. Do not blame them - they simply do not know better.

Start now to set up training lessons, coaching sessions, and workshops to gain knowledge of all the things anyone of your team must possess. Use experts available in your organization to spread knowledge. Or get professional external help - there are lots of experienced trainers out there to help your team. And the team will be thankful to get something fresh from external people. Just weigh the pros and cons of the money invested in a trainer and the inspirational motivation of the team.

Pure self-organizing advocates will argue that the team by itself has to find all of these issues and how to improve accordingly. Yes, your team should do so. But if you as a ScrumMaster notice slack of improvement it's your turn to brief the team and kick-off some hints.

And always remember:

"Training is useful.
But there is no substitute for experience."

Rosa Klebb, From Russia with Love

Scrum Checklist: German Translation

I proudly present the German translation of Henrik Kniberg's Scrum Checklist.
Download: http://agilecoach.de/scrum/Scrum-checklist_German_v2016.pdf

Have fun with it and give me feedback if there is a typo or anything else is broken.

If you are interested in Henrik's original version, take a look at his Scrum Checklist site.