Let the Team play Product Owner

Today I made a nice but rare experience: team A could play Product Owner for team B.

Team A is settled since several iterations and is working on a new product. Team B is only a few days old and is going to build an internal, technical product to emulate the behavior of depending external hardware.

As the developers and testers of team A are going to be the real users of team B's product it was obvious to do a short user story workshop with them. So I gathered everyone of team A around a table in the team room bringing some blank index cards and a marker to start with.

I made several interesting observations during the workshop:

• Some developers show the same behavior as many customers do. They have problems to state what they want to achieve and rather base their statements on the currently planned product features.
• Some developers think very broad so that new themes and stories emerge no one had thought of before. Of course these stories look obvious afterwards but nevertheless would have been forgotten if the real users were not involved.
• Some developers fully understand the agile roles and do not care about the technical implementation. "I don't care how they realize it but I want to have this and that."

We finished that session with a dozen user stories which will result in many more smaller stories after some backlog grooming. I'm going to do the grooming exercise with the team as well so they have the chance to get more and deeper insights into a Product Owner's work and responsibility.

A team and it's Product Owner need mutual understanding and a prospering relationship. In the end it's again--as almost always--a game of Individuals and Interactions.

Recommendation to Scrum Masters and Agile Coaches: let the team play Product Owner every now and then.

Generalize Your Specialized Generalists

The software developers in a well-known Scrum team have undergone a transition from generalists to specialists in former times. They have been responsible for no specific parts of the software system. Every developer was assigned to the next high priority tasks regardless of knowledge and experience. Combined with classical waterfall project management, solo programming, missing code reviews, and missing unit testing, the resulting quality of the system was extremely low. There was a vast lack of knowledge of the old legacy code the team was working with. To compensate that knowledge all parts of the system were assigned to specific developers - a step that turned them from generalists to specialists.

Instead of moving out of the waterfall into Scrum and introducing pair programming and unit testing it was decided to go the pretended easy way and transforming generalists to specialists. Now single persons were assigned to specific parts of the system but unfortunately there still was a vast lack of knowledge of the old system. The major disadvantage of assigned specialists is the "not my job" syndrome: there always is another guy responsible for the task on my table so work can easily be pushed away. The next disadvantage is the "don't touch my baby" syndrome which instantly blames developers who dared to touch code not in their area of responsibility.

The team resulted in a hypoproductive group of developers, controlled by waterfall processes, solo programming, missing code reviews, missing unit testing, vast lack of knowledge, and individual code ownership: the worst of all worlds finally was born.

Productivity raised instantly after installing a working Scrum with that team. Bug rates dropped rapidly simply by applying the definition of done: code reviews and unit testing now are mandatory. As a next step single team members were asked to spread their knowledge via pair programming. This opened the way to collective code ownership.

The team has to improve a lot more and it will find out all those issues as impediments in the next retrospective meetings. Well, if they don't, the Scrum Master will give some hints by defining appropriate retrospective goals.

In the end, the team will become hyperproductive and will finally re-generelize their specialized generalists.