Upfront Technical Planning and The Paradox of Scaling Responsibility

Most people’s #1 misunderstanding about Agile is that no planning
is ever done. You just get a list of story haiku (“the system must be
508 compliant, we have a contract” or “the system must interact 5,000
wing-dings, our customers demand it”) and start hacking away. More
importantly, Agile folks poop all over water-fall planning, and so it
seems that any sort of planning is “bad.”

Big Teams Aren’t So Agile

If you have one small team, this is somewhat OK: the team will
naturally do this planning as needed because they’ll take on full
responsibility to make sure things work. If planning is needed,
they’ll do planning. If prototyping is done, they’ll do that. A small
team that contains all responsibility for coding and project management
(as a canonical Scrum team does) can be trusted to Do The Right Thing,
as needed. So, you don’t have prescribe “first you must do all this
planning, then you do the design, then you code, then you QA.” The
small team will figure out what needs to be done and do it. They can
be Lean.

Software Development Tribalism

But once you have 5-10 inter-dependent teams, leaving out up-
front planning is an unhelpful mindset. Once you reach a certain
amount of people (10-20?), individuals begin to shrug off that
responsibility to Do The Right Thing as needed. They start to think
things like: “Someone else is doing that planning. And if problem
occur, well, it must be someone else’s responsibility to fix them.
I’ll just do my stories or tasks, and that’s it. What other power do I
have to do otherwise? I’m just one of 50 people!”

Paradoxically, by taking on an Agile approach, the organization has
caused individuals to take on a water-fall mindset.

There are two separate problems here:

  1. technical planning does need to happen in a multi-team
  2. as the number of people involved scales, due to the paradox at hand,
    each individual contributes less value to the project.

Stability Requires Planning

Stability is a good example of where upfront, technical planning is
needed. When it comes to multi-team efforts, my theory (as yet
unproven) is that you need to lock down a good (a.) API and (b.)
data/domain model before the dependent teams start. Things can be
added to those two, but you need a stable and “complete” code-base to
start with or the API and client teams will spend too much time
thrashing about what and how to implement things. That is, if you want
to move fast, when it comes to APIs and domain models, you really need
a benign dictator and not a committee.

Theories of the Fix

The second item is, of course, more vague and difficult to deal
with. So far I don’t have any solutions. The only thing I can think of
are the spider diagrams, and accompanying methodology for figuring out
how Agile you can be, in Cockburn’s Agile Software Development. That
is, all the people involved may not be skilled enough and/or of the
right work-mindset to be fully Agile.

There might also be something to the notion that more education
could help. If all the people involved haven’t received even the most
basic training or “thought-syncing,” it’s going to be difficult for
the process forces to execute correctly: people just won’t know what
they should be doing.

Tags: , , , .

Leave a comment

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.