Team & Product Management

Christian Meier is a Systems and Business Analyst (CPRE, CSPO) and focussed on conception and implementation of information systems in a wide variety of industries. This may range from a technical low-level flight to a high-level analysis of requirements fulfilling your business needs. Furthermore he may serve as an Agile Team Coach (CAL, CSM).


BASICS: Keep learning more...

Die Dynamik globaler Märkte hat die Wertschöpfung verändert. Das Problem sind dynamikempfindliche Strukturen – nicht die Menschen. Dynamikrobuste Höchstleistung (re)integriert den menschlichen Ideenreichtum in die Wertschöpfung. Um das Phänomen dynamikrobuster Höchstleistung zu verstehen, sind begriffliche Unterscheidungen als "Denkwerkzeuge" hilfreich, z.B.: kompliziert vs. komplex, Plan vs. Strategie, Unwissenheit vs. Ungewissheit, "blau" vs. "rot". Hohe Dynamik heisst nicht nur schneller und billiger. Damit hätte man heute kaum Mühe. Was man nicht gewohnt ist, ist der souveräne Umgang mit Überraschungen. Die Vorwegnahme der Zukunft zum Zwecke der Planung oder Steuerung gelingt nicht mehr in ausreichender Qualität. Planung, Budgetierung und Anreizsysteme stehen im Weg. Die erfolgreichen Denktraditionen für träge Märkte sind heute keine Lösung, sondern das Problem. Es fehlen Werkzeuge für problemlösendes Denken. Eine präzise Problembeschreibung benötigt Zeit – und spart immer mehr als sie kostet. (

Achieving Certified Scrum Product Owner, CSPO (7/2013)
Achieving Certified Scrum Master, CSM (7/2014)

In theory, the product owner is one person. But in practice, managing a larger, complex product is usually a shared effort. How can product ownership be split without resulting in decisions by committee and creating a weak or even inconsistent product? In this post, Roman Pichler discusses different techniques to help scaling the product owner role successfully and he explains when each technique should be applied during the product's life cycle: unbundling and product variants, feature and component owners, strategic and tactical product roles (6/2016)

based on Roman Pichler's Guide to Transitioning into the new role of a Product Owner: Agile Product Management with Scrum (2010)

based on Mike Cohn's Guide to Succeeding with Agile: Software Development Using Scrum (2010)

based on Dean Leffingwell's Blog featuring Lean and Agile software requirements for larger enterprises (5/2009)

based on Christian Meier: Construction of educational resources in context of open source experience, Institute of Educational Technologies, Dresden University, TUD, unpublished. (2007)

STEP #1: Evolve team work

Great impact on applying e.g. the Scrum framework successfully is the question how to deal with problems, because Agile methods make organizational problems visible. Either that created transparency is desirable and the disclosed problems are processed – or the organization rejects Agile methods in general.

From my point of view the biggest misconceptions in daily work are:
1. Effort equals duration
2. Specification can substitute communication
3. Multi-tasking induces earlier completion

Time boxing methods provide a possible escape from the annoying forecast of effort and duration. They turn around the logic to get work done by focussing on the functionality – which tailored solution can be delivered by the available resources within a fixed period of time.

STEP #2: Create common understanding

BPMN for example can be used to model and visualize business processes. Practice shows this is an appropriate way to generate common understanding with all stakeholders involved.

Furthermore a common terminology of the domain has to be evolved and optimal traceability of changes made has to be guaranteed. Throughout the entire lifecycle the »What & Why« of a requirement should be crystal clear to all participants.

These are challenges for both Team and Product Management – or in other words: the communication structures of the organization.

In contrast Project Management stresses the »When & How« focussing budget, timeline and policies. To achieve these commercial objectives and constraints it is necessary to ensure productive teamwork at continuous rhythm – in my opinion this is the key for reliable forecasting and predictable delivering.

STEP #3: Follow a continuous rhythm

In my opinion the cornerstone of an agile process is the automation and scheduled execution of routine tasks – to create scope for non-routine jobs. The stated aim should be the delivery of product increments on-demand at the push of a single button. I contribute to the development of packages, which help to solve such tasks (see zms3.deployment and zms3.behave).

I am involved in Behavior-driven development (BDD) practices as an agile software development technique that encourages collaboration between developers, operations and non-technical or business participants.

BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends Test-driven development (TDD) by writing test cases in a natural language. This may minimize translations between the domain language spoken by the business, users, stakeholders, project management, etc. and the technical language in which source code for test automation is written.