Reading Time: 4 minutes When you ask Teams or Product Owners the question "What is your Product?" they often first answer with a list of functions and features. In the second attempt, then they describe the purpose from the view of the engineers and designers, and how they intend it. Very seldom does the customer occur.
Reading Time: 7 minutes Software Project Management is managing all kinds of Dependencies. We have to deal with Technical Dependencies due to the SW tools we use and the product architecture decisions we agreed to. And we have to deal with non-Technical Dependencies caused by workflow and team dependencies due to the organizational work model and the design of our organization.
Reading Time: 5 minutes If you dive into Agile Product Development, resp. in Agile Software Development you get into a lot of new and abstract terms. One of the most blurred and therefore most fascinating ones is "Value" resp. "Product Value". However, the Scrum Guide 2020 is keeping very quiet about an explanation. In this post I argue for the customer to benefit from value.
Reading Time: 5 minutes In the traditional way, a Product Roadmap states when and which functionality will be released. The Roadmap is aligned with business strategy and release dates. It is a kind of Roadmap, a long-term plan. Instead, an Agile Roadmap is more about communicating our product strategy than it is about communicating features and dates. However, important dates should and could be mentioned, the Roadmap is a statement of intent and direction. The Roadmap visions the certainty and uncertainty of the project/product evolution. It is not a Gantt-chart, or milestone table.
Reading Time: 4 minutes You can sabotage your product delivery by focusing on customer/user feedback over product vision, by changing given requirements or by adding new requirements too often. In delivering a product there are six well-known anti-patterns: Product Death Cycle, Product Build Trap, Feature Hell, Experience Rot, Scope Creep, and Feature Creep.
Reading Time: 4 minutes In Lean Development/Manufacturing resp. Lean Production value is attached to „Value-adding“ and „non-Value-adding“ activities. it is not related to customer needs or usage. In Agile Product Development, “value” is interpreted differently.
Reading Time: 5 minutes To make customers happy, we have to have a potentially shippable and executable Increment at the end of each Sprint. There are many ways to slice or split User Stories to accomplish this. Here are the Good and the Bad Ways to do it.
Reading Time: 5 minutes Story point estimates are relative and subjective, factoring in a team's unique blend of experience and skills. They shouldn't be used for procurement and billing. According to the Hawthorne effect, Story points-based procurement incentivizes the delivery of Story Points, not the value, and by manipulating them you can easily trick the system.
Reading Time: 5 minutes Many agile glossaries still refer strongly to software development. but since Scrum Guide 2017/20 the new paradigm is Agile Product Development. One of the most blurred and therefore most fascinating concept is "Value" resp. "Product Value".
We lay the foundation for a shared common Glossary for Agile Product Development with a nucleus of only a few important concept definitions of user-centric Value-creation.
Reading Time: 42 minutes
Many companies show big misconceptions in using the notions of value and value-creation. Value is hard to measure. To measure the value of their products, companies often tend to place different kinds of proxies there.
However, the Agile Community, Agile Product Development, and Design Thinking use the term „Value-Driven Development“ frequently with a clear understanding of “value”. This interpretation differs dramatically from the traditional Value-Stream approach of Lean Manufacturing.
Value-driven development is an illusion as long as we are all trapped in different manifestations of the Feature Factory mindset and Project Thinking. As long as organisational silos between product management, design department, development department, marketing department, and supplier management are not broken down and all participants work together in a solution-oriented rather than product-oriented way Value-driven development is an illusion.
When we talk about Value-Driven Development we should be very sensitive to our background and the context we are talking about so that it does not become a new cargo cult.
