There is this legitimate, real tension between planning and action, between BDUF and winging it (in extreme cases), between roadmaps and evolution.
I don't think it's "enlightened people vs dumb clods"
I don't think it's "enlightened people vs dumb clods"
If people don't agree on what they're doing together, then they tend to not have a solid, cohesive collaboration.
When is this agreement reached?
When is this agreement reached?
Let's assume that there is a problem big enough for many people to work on it.
For them to work independently async, they need to have a very solid agreement up-front so that they don't work at cross-purposes.
For them to work independently async, they need to have a very solid agreement up-front so that they don't work at cross-purposes.
It will be a constant complaint that any agreements and documents shared up front won't be complete enough, or won't be accurate enough, or won't be clear enough, etc.
There will have to be alignment meetings often, and if there isn't enough CI there will be many merge conflicts.
There will have to be alignment meetings often, and if there isn't enough CI there will be many merge conflicts.
The other side of it (not predesign) is to work on all the parts together and integrate continually/continously.
This requires constant communication - every work session is part meeting, part validation, part cocreation.
This requires constant communication - every work session is part meeting, part validation, part cocreation.
Two disasters:
* asynch work style without pre-design and alignment meetings.
* collaborative, low-predesign work without constant communication
There seems to be a balance issue here.
* asynch work style without pre-design and alignment meetings.
* collaborative, low-predesign work without constant communication
There seems to be a balance issue here.
The more available the expert on the feature is, the less they need to pre-document and pre-split the work.
The more available team members are to each other, the less pre-design and alignment meetings they need to maintain alignment.
The more available team members are to each other, the less pre-design and alignment meetings they need to maintain alignment.
When people aren't available in the flow of work, the more they need a fully-competent/comprehensive document or a fully-competent/comprehensive proxy to stand in for them and answer all the questions they might have otherwise answered themselves.
In either case, though, some kind of chartering of the initiative/epic/feature is needed in order to create initial alignment. We need a shared intention if we're to make a difference: what problem it solves, what success looks like.
It can be a problem to solve and not much else, if we're all cocreating the solution. It requires communication in flow rather than a formalized and divided specification up front.
Comprehensive documentation vs collaboration, think of it as a slider: you have to find the right level, because wherever you put that slider determines how your team works and which set of risks and failure modes are constantly in their way.
If you set it according to how your team currently works, you're ensuring that they work that way.
It's a driver as much as an accommodation.
If you move it, the team moves accordingly.
It's a driver as much as an accommodation.
If you move it, the team moves accordingly.
Waterfall skewed (necessarily) toward pre-worked, comprehensively documented/contracted solutions, and individual work assignments.
Agile skews toward robust communication, feedback, co-creation, and evolutionary design rather than upfront planning.
Agile skews toward robust communication, feedback, co-creation, and evolutionary design rather than upfront planning.
ISTM that middle ground would have to be light up-front agreements + evolutionary groupwork. Charter and swarm?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
