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 a Product Owner and/or Team Coach.


(1) 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.

(2) 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).

Currently 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.

(3) 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.

(4) Keep learning

Aspects on creating value acting as "Feature Owner" vs. "Component Owner" and options on scaling at different stages of a product's life cycle by Roman Pichler (2/2016)

Sharing Experiences and Ideas at in Munich (7/2014)

based on training by Christoph Mathis at improuv, Munich to achieve Certified Scrum Product Owner (7/2013)

based on Gerhard Wohland, Matthias Wiemeyer: Warum dynamikrobuste Unternehmen Marktdruck erzeugen (2006-2012)

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, TU Dresden Institute of Educational Technologies, unpublished. (2007)