4 ms·
Huge problem in many orgs. Many product decisions are made on the fly by the wrong person in an attempt to check a box and get something out the door quick. Or
by masonhensley 7y ago
Huge problem in many orgs. Many product decisions are made on the fly by the wrong person in an attempt to check a box and get something out the door quick. Or if the right decision gets made upstream, teams downstream don’t align for a litany of reasons.
Haven’t been able to put my finger on it exactly (definitely a multi dimensional issue), but I don’t think the issues you outlined will continue to fly if you want something of quality that’s not half baked.
This excerpt from agile manifesto comes to mind as part of the problem that I’ve coming to disagree with (at least how I’ve seen it implemented in the past):
> The best architectures, requirements, and designs
emerge from self-organizing teams.
- BlueTemplar 7y agoDo you have any counter-example in mind ?
- Aeolun 7y agoThe best architectures, requirements and designs come from a team with a fantastic lead/architect/product manager?
- maemilius 7y agoThis. 100% this. Any product of real complexity _must_ have a single person or very small group of people overseeing it. This is doubly true if you're product is using micro-services. The product my current employer is working on suffers immensely from a lack of central leadership to the point where each of the pieces of the application have different (and sometimes contradictory!) ideas of what the world looks like. It's absolutely maddening.
- closeparen 7y agoAny product of real complexity is too big for any one person to hold in their head with sufficient detail. That's why we have modularity. (Microservices are just one kind of module boundary). In my experience, central leaders want to impose grand sweeping worldviews that just aren't true when you get into the weeds of particular use cases. The Director gets a pretty architecture diagram but the engineers actually building and maintaining the feature live in a train wreck. And for what? You don't actually need uniformity across unrelated parts of the system. Architecture shouldn't be about a director's view of his kingdom, but about engineers' ability to sustainably deliver business value, which starts with using the right abstractions for the problem at hand.
- Aeolun 7y agoI think we would be able to deliver business value a lot easier if everyone was consistent in the major ways. As it is, everyone has their own idea of what constitutes a dropdown.
- masonhensley 7y agoYes. If you think of it, the industry has been growing faster than fantastic leads/architects/ project managers can be developed. Those roles take time & experience to nurture, develop battle scars & grow. As a backfill, many orgs are forcing people to pinch hit that are in over their head (not their fault, often times they are also stepping up to help which is great!) The problem is that these people & teams get to the point where they are just trying to survive until the next sprint. Wash & repeat sprint to sprint, deploy something to check the box but it’s building a house of cards.
- BlueTemplar 7y agoThis isn't a counter-example, but a counter-motto. Since you want to stick with theoreticals, a lot of great projects come from groups of close friends working together. You need a "fantastic lead/architect/product manager" when a team like that isn't available, and you need to compose one artificially.