Not authorized

You are not allowed to access this resource.
It is available to a closed user group only.
To join the discussion please contact me privately.

more

Analyzing & Management

Christian Meier is a Systems & Business Analyst 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. In the last ten years, the focus has been increasingly on Learning Technologies.

more

Conway's law

»Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.«
—Melvin E. Conway (1968)

BASICS: Keep learning

Handling complexity: Think tools for dynamic-robust high performance
The dynamics of global markets have changed value creation fundamentally. Dynamic-sensitive organizational structures are the problem – not unwilling people. Human inventiveness has to be (re)integrated into value chain. To understand this, think tools with conceptual distinctions are helpful, e.g.: complicated vs. complex, plan vs. strategy, unawareness vs. uncertainty, "blue" vs. "red". More dynamics does not only mean faster and cheaper – today there is no problem with that. What we are not used to is the confident handling of surprises. The anticipation of the future for planning or control purposes is no longer possible in sufficient quality – planning, budgeting and incentive schemes are more of a hindrance than helpful. The successful thinking traditions for sluggish markets are not a solution today, but the problem. There are not enough methods and tools for problem-solving thinking. A precise description of a problem takes time – and always saves more than it costs. (by dynamikrobust.com)

Product & Business Value
based on training by Christoph Mathis at improuv, Munich

Achieving Certified Agile Leadership, CAL I (2/2018)
Achieving Certified Scrum Master, CSM (7/2014)
Overview of CSPO training topics
Achieving Certified Scrum Product Owner, CSPO (7/2013)
Overview of CPRE training topics
Achieving Certified Professional for Requirements Engineering (12/2012)

Scaling the Product Owner Role
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)

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

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

Phases of Disillusionment in Waterfall Development
based on Dean Leffingwell's Blog featuring Lean and Agile software requirements for larger enterprises (5/2009)

Network-based organisation as foundation for cooperation
based on Christian Meier: Construction of educational resources in context of open source experience, Institute of Educational Technologies, Dresden University, TUD (2007)

STEP #1: Evolve team work

Identify Difficulties
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.

Avoid Confusion
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

Use Timeboxing
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.