Better Coordination, or Better Software?
jessitron.com
jessitron.com
Departments are responsible for creating and curating reusable knowledge, project teams are responsible for providing value. The former does not need coordination, the latter needs way too much of it to go through formal boundaries.
In product development work, hand-off between people (i.e. different people dealing with implementation, feedback, responsibility and knowledge for the same goal) is one of the biggest wastes. Every time you pass information between people you lose a huge chunk of information and context that would help provide better value for the end user. At best 30 % of the information makes it through a hand-off, more realistically something like 10 %.
Hand-off results in the right knowledge not being available when needed. It leads to delays and low-value trade-offs. Also finger-pointing, endless series of status updates and reports, responsibility shirking, etc.
Popular management techniques (Taylorism, Critical Chain-type thinking) lead to excessive hand-off, either because it assumes everything is perfect (Taylorism) or because it focuses on activities rather than interactions and thinks global optimum is reached through the right local optimums (both Taylorism and Critical Chain).
Downstream, on one side of contract, as you develop and test, you may find that you understand the problem differently. Then the contract becomes a constraint. This organizational model then requires that parties revisit contracts if needs on one side or the other change. That still looks like coordination.
Perhaps the win is just less frequent, more focused coordination. We still need a common picture of "what", just now as expressed through contracts. I like the peer bob1029 post on consistent labels, in that way. The other decoupling to consider would be "when" - how can we work in parallel with minimal synchronization and blocking?
This is something I'm very interested in at the moment. Trying to read up on how good development organisations do it, but I'm partly coming up short.
I know a Ward-style lean approach of web-based concurrent engineering involves these things:
- Brainstorming up multiple potential ways to break the system into subsystems, and exploring those in parallel.
- Negotiating over interfaces. "If I give you that endpoint, how will you use it to improve the product?"
- Specifying ahead of time which subsystems are inflexible and which are flexible. If an inflexible subsystem has an interface demand, the flexible subsystems have to comply. They, of course, are prepared for this and have explored several variants of their interface.
- Exploring several implementations exposing the same interface.
The main thing I don't get is that this is presented by Ward as a cheaper way to do development, because the subsystems are -- when all is said and done -- virtually guaranteed to integrate cleanly, and by exploring many options in parallel at all levels the risk of failure to deliver on schedule is virtually zero.
But... that parallel development of alternatives sounds really, really expensive. Like more expensive than blowing the schedule by a fair amount. I understand not all the work is wasted -- there's useful learning that happens in exploring an alternative even if it doesn't end up being used. But still!
Reinertsen argues for a more fiduciary view where the number of parallel alternatives to be developed must be balanced against the economically defensible level of risk reduction, but it gets somewhat abstract for me at that point. Can you really apply that logic at all levels in the organisation? Does it get easier with experience?
We basically have 1 github issue bucket for the whole organization, and the repo its in also contains all of the code we care about, as well as all of the tooling and relevant documentation.
We don't lose track of anything anymore. Everything is done on the basis of some issue#. 1 global sequence. Labels are key. If you want to find some phrase across all code, issues, prs, etc, you just have to type it in the search box. This feature has probably saved me weeks of time by now.
We are adding a separate (non-GH) bucket that is more about the customer-product interactions, but it will ultimately answer to the current one if any product (code) change is desired, or if a bug is spotted.
By way of analogy, consider which programs scale better and which scale worse. The best scaling programs are termed "embarrassingly parallel". The communication is constrained to the start and end of the work, issuing the data to be worked on and receiving the result of that work.
Programs that scale poorly often have too many interaction/synchronization points. Some of these are unavoidable, but minimizing them is literally what you do if you've worked on concurrent, parallel, or distributed systems. And the ones which scale the worst have constraints which force sequential execution of every step.
Business processes are not fundamentally different from any other process. There's nothing magical about it being done by people instead of computers or machines. If you have a large number of synchronization points then you have a cap (which may still be very high) on your ability to scale. Remove those points, to a reasonable level since some work fundamentally requires more than others, and you can smooth out a lot of work issues.
I think you're correct. There is a lot of what project management people can learn from computer science.
Operations Research is another rich field that computer scientists often seem to neglect, perhaps out of ignorance of its existence or a belief that it's "just" about managing factories or something.
The first time I worked on a real distributed programming system I "grokked" the issues much faster than my peers because of my math degree (dual major) background that had included a couple OR and math modeling courses where I'd already seen the same thing (but presented in different terms). I'm hardly an expert in it, but by having been exposed I knew the right questions to ask to find out more information and how to analyze systems to find bottlenecks.
This would hurt during the exploring phase of development by eliminating frequent small iterative increments towards the ideal architecture/implementation.
Out of the aftermath of finger-pointing and brainstorming how to improve communication we could have had an additional small agency responsible for tracking, collecting, and making sense of threats across agencies. What we got instead was a major reorganization of the US federal government, the formation of the Department of Homeland Security which oversees far too many investigative and law enforcement personnel under one office, and the PATRIOT Act.