The last point in the article (how flow enables quick validation of ideas) is perhaps the most important.
When we are wrong (and we often are) about what adds value to a product, the time between idea and feedback is critical and must be reduced to a few minutes if possible.
However, the plan-driven approaches many use for their software deliveries work precisely the other way around: they increase time between idea and feedback.
So, to your article I'd add the following: our goal should always be to reduce time between idea and market/customer feedback.
I would say the challenge is real. In the Technical Program Manager role interfacing between OPS and Platform ENG, I hear that phrase all the time. It's just software, tell me what you want and I can do it. The next thing we know we've created a complex thing that is no longer just a simple software update. Think of the tools we developed when you worked at TT.
I love the idea to iterate quickly and see is what the customer, OPS in general, but me being the POC for OPS with the Platform ENG team, really wanted. Develop fast, deliver and like you outlined in most cases, probably fail. You are spot on about developing too much to only then find out after the fact the customer isn't using it.
It's a challenge, to pardon the pun, constantly challenge both the customer (OPS in general) and the Platform ENG team.
Yes! I would add that a specific challenge of being a role like what you described is to make operational teams to understand that the sort of burden of start using earlier something not totally polished up does pay off in the long run... I remember having that trade-off conversation at TT, to which extent be re-training users for stuff we want to move fast changing to learn, things like that...
Indeed that is the biggest challenge I face. It's beneficial to both teams and organizations. The Engineering teams learn along the way and so they can "easily" adapt / change instead of developing something and then in a month or three or six find out it's not what the customer needed / how they needed it and it's too much tech debt to address properly so more hacky solutions on top of other hacky solutions.
The last point in the article (how flow enables quick validation of ideas) is perhaps the most important.
When we are wrong (and we often are) about what adds value to a product, the time between idea and feedback is critical and must be reduced to a few minutes if possible.
However, the plan-driven approaches many use for their software deliveries work precisely the other way around: they increase time between idea and feedback.
So, to your article I'd add the following: our goal should always be to reduce time between idea and market/customer feedback.
Very nice way to articulate that indeed!
I would say the challenge is real. In the Technical Program Manager role interfacing between OPS and Platform ENG, I hear that phrase all the time. It's just software, tell me what you want and I can do it. The next thing we know we've created a complex thing that is no longer just a simple software update. Think of the tools we developed when you worked at TT.
I love the idea to iterate quickly and see is what the customer, OPS in general, but me being the POC for OPS with the Platform ENG team, really wanted. Develop fast, deliver and like you outlined in most cases, probably fail. You are spot on about developing too much to only then find out after the fact the customer isn't using it.
It's a challenge, to pardon the pun, constantly challenge both the customer (OPS in general) and the Platform ENG team.
Yes! I would add that a specific challenge of being a role like what you described is to make operational teams to understand that the sort of burden of start using earlier something not totally polished up does pay off in the long run... I remember having that trade-off conversation at TT, to which extent be re-training users for stuff we want to move fast changing to learn, things like that...
Indeed that is the biggest challenge I face. It's beneficial to both teams and organizations. The Engineering teams learn along the way and so they can "easily" adapt / change instead of developing something and then in a month or three or six find out it's not what the customer needed / how they needed it and it's too much tech debt to address properly so more hacky solutions on top of other hacky solutions.