As an app developer, I certainly feel that I have been forcibly relocated into a world where I must explore value. What makes it tricky is that I am simultaneously expected to harvest value as well. In that situation, the Facebook “P50 Goals” that Kent Beck introduced was very insightful for me.
Good stuff! And I think that Scott Adams’s life hack of preferring systems over goals applies here as well. Carefully design what you do routinely, every day. Design that to move you towards the goal. But focus on following that path.
Simon Wardley's map model (Wardley Mapping) puts it in different terms. He uses "Genesis, Custom Built, Product, and Commodity" as an evolutionary spectrum. Dependencies in the value stream (starting with the customer) can be in any stage in the evolutionary spectrum. You can have something in genesis that depends on a commodity that depends on a product.
Each evolutionary phase needs a different style of management. Exactly what you're proposing!
Therefore, the trend in using Agile (some strange version of Scrum) on all dependencies is at odds with the reality. Many projects need the kind of coordination across teams due to these dependencies where the customer:team ratio becomes customer:team:team:team:customers. One customer's needs impact a downstream dependency (or back upstream) in a way that affects all customers.
We can say "oh, that's a structural problem" but those structures are embedded not only in the organization but in the systems and their evolution. That deep rooted structure is difficult, costly and time consuming to change and we can't ignore the fact that we still need to service the needs of customers and implement change even while the structure isn't ideal for that particular change.
Therefore, we need to acknowledge that we can't manage every change/project in the same way. We can't just do "Agile" (some form of Scrum) or anything else and expect it to work.
As an app developer, I certainly feel that I have been forcibly relocated into a world where I must explore value. What makes it tricky is that I am simultaneously expected to harvest value as well. In that situation, the Facebook “P50 Goals” that Kent Beck introduced was very insightful for me.
You may also like this
https://iruafeimi.substack.com/p/the-best-tech-stack-for-startup-mvp?r=57lqd9&utm_medium=ios&utm_source=post-publish
Good stuff! And I think that Scott Adams’s life hack of preferring systems over goals applies here as well. Carefully design what you do routinely, every day. Design that to move you towards the goal. But focus on following that path.
Simon Wardley's map model (Wardley Mapping) puts it in different terms. He uses "Genesis, Custom Built, Product, and Commodity" as an evolutionary spectrum. Dependencies in the value stream (starting with the customer) can be in any stage in the evolutionary spectrum. You can have something in genesis that depends on a commodity that depends on a product.
Each evolutionary phase needs a different style of management. Exactly what you're proposing!
Therefore, the trend in using Agile (some strange version of Scrum) on all dependencies is at odds with the reality. Many projects need the kind of coordination across teams due to these dependencies where the customer:team ratio becomes customer:team:team:team:customers. One customer's needs impact a downstream dependency (or back upstream) in a way that affects all customers.
We can say "oh, that's a structural problem" but those structures are embedded not only in the organization but in the systems and their evolution. That deep rooted structure is difficult, costly and time consuming to change and we can't ignore the fact that we still need to service the needs of customers and implement change even while the structure isn't ideal for that particular change.
Therefore, we need to acknowledge that we can't manage every change/project in the same way. We can't just do "Agile" (some form of Scrum) or anything else and expect it to work.