Here’s another shot of my robo-Hemingway “costume.”
I’m not sure I buy Cockburn’s machismo angle, in his
article “Are Iterations Hazardous to Your Project?”, as the complete reason for the prevalence of 2 week iterations. As we’ll see, I think the underlying problem isn’t so much machismo as it is, well, not being wise enough to do otherwise as needed.
But I like his summary of why you’d want your iteration to be a
month instead of 1-2 weeks:
Usually, as I am witnessing it, the pressure that drives
teams to form pipelines is the machismo around short iterations. For
many teams, if they used an iteration length of one month, they could
jointly develop the requirements, database, code and tests for a set
of user stories all in one iteration, and then possibly even deploy it
and get feedback from their user base. However, they won’t set up a
one-month iteration, because then they will be viewed as sissies in
iteration-length bragging matches.
There’s a Lot of Work To Do
I’m interested in that middle sentence: in my experience, cramming
all those things into less than a month is difficult. I can see that
if you had an almost purely UI-centric, smallish application, and you knew
exactly what you were implementing, iterations of less than a month
wouldn’t be a problem. But when you’ve got lots of complicated,
undefined/unknown, non-user facing sub-systems that have to work
together, it gets difficult to come up with something demo’able —
running, tested features — that isn’t lame in less than a month.
To summarize my thinking: yes, if you know what you’ll be coding
and integration is easy, 2 weeks is great. The problem is that there’s
a whole lot more than coding and integration to do, and often-times
those activities are crammed into the 2 week iteration.
For example, you’ve got to: figure out what you’re supposed to
code; come up with designs and/or prototypes; figure out your testing
strategy; do your documentation, internal and external; put everything
together for the demo; and then do all the unexpected things that come
up, like figure out why the previous version of the product that
paying customers are using keeps shitting the bed.
Perfect Planning Doesn’t Happen
That’s all assuming that all your planning and story-carding is
done perfectly so that the everyone can hit the ground running. Of
course, that whole this planning and story-carding is often put into
the 2 week window as well. Defining
the problem sufficiently to efficiently come up with the solution
takes a lot longer than we ever think, but we hardly ever give it
enough time. We’ll always “do it better” this time, as with all things
That is, it’s rare and difficult for an organization to achieve the
pipeline’ing that’s needed to effectively use two week iterations.
Month Iterations are Training Wheels
What I’m saying is that most places probably aren’t mature enough
to do 2 week iterations. They’re not good enough at the process of
creating software to work that fast. Usually, the fact that they’re
adopting a new methodology indicates that how they’ve been doing
things wasn’t too functional in the first place.
As an indication of this lack of maturity, most people I talk with
take a sort of flippant attitude about Agile: “it means we don’t have
to do so much planning or documenting.” In fact, in my experience,
it’s the opposite, with a twist: you don’t have to do worthless
planning and documenting, you have to do thorough, but lean,
planning and documenting.
In my mind, if your going to be coding for two weeks, you’re
probably going to need 2 weeks for planning, designing, and all the
other project managing that 2 weeks of coding requires. Putting all
those activities into 2 weeks doesn’t seem like a good idea. And it
certainly seems to cause you commit the error that Cockburn warns
about: the end-result of your 2 week iteration isn’t
customer-deliverable. It needs more work before you’d think to give it
to an actual customer or user.
Dividing Up the Work is a Bad Idea
The temptation here is to get another group of people — product
managers or analysts — to do all that definition for the
development team. These people take the 2 weeks to write-up
everything. And then you have true waterfall pipelining. You end up
with a sort of process/methodology version of Conway’s Law:
the software development process and organization uses will directly
reflect the managerial and communication structure of that
The bad things about separating the roles out like this are:
- Transferring that plan-think to the development team will be
slow, error prone, and tedious. Ideally, the same group of people
has defined things and, thus, no transfer is required.
- With separate teams comes tribal thinking, that is, “us
vs. them.” When software is created in this type of context, it’s
much more difficult to write good software that users will love
(For more on the tribe problem, check out my
recent post on The Paradox of Scaling Responsibility and this
anecodatal-ish discussion the problem in the auto-industry)
Predicting the Future
Of course, you’ll end up having to re-plan a lot of stuff while
you’re coding it — that is one of the major epiphanies of
Agile-think, not that you don’t need to plan or document. This
suggests that you’ll want to spread out planning into your
coding. Indeed, you do. So, the idea of having 2 weeks for planning,
then 2 weeks of coding seems silly. Really, you need 4 weeks of doing
More importantly, as Cockburn says,
The length of an iteration is secondary in importance to completing
deployment-ready functionality. Replace your worrying about how short
you can make an iteration to worrying about how long it takes to move
from opening a new requirement until that requirement is integrated
into the deployment base with acceptance tests.
Point being, I’m not really attached to 2, 3, 4, or 6 weeks. I’m
more attached to the idea of clearly-enough defining your end-goal,
and then expanding your iteration to fit that goal.
A Theory on What to Do
If you find yourself in a situation like this, what I’d want are
- Lengthen the iterations to a month to start with.
- Make the “planning people” and anyone else working on the product
part of the team (and I mean, really part of the team, not
some half-ass just show up at meetings and take notes sort of
- Make the roles in the team fluid: developers might do some
might do some coding, QA might write some code, planners might do
some QA or coding.
As the team gets better at defining their goals and stories, you
can vary the iteration length as required to meet the customer
deliverable at the end of the iteration. But, as you’re learning, keep
things at a month to give the team time to learn how to better manage
the process of software development.
Being resistant to the idea that you’d have to learn this is where the machismo angle fits in, esp., as is commonly the case, if by “machismo” you mean “stupid” ;>
Ask “Is it Working?”
As with any process improvement, the most important thing is to
frequently and seriously ask if the changes are working. Using rapid
feedback to improve your efficiency and quality is, perhaps, the least
used tool in the Agile tool-box.
If there isn’t a constant stream of constructive-complaining from
the team, they’re either the best software team in existence, or
they’re hiding something from management. As the other side of that
coin: management should be constantly responding to that
constructive-complaining and seeking out ways to improve
things. Otherwise, they
just don’t get it.
Granted, it takes a lot of professionalism on the team’s and
management’s part to even admit/think “maybe we’re not such
hot-shit. We should figure out what we do wrong and fix it.” I mean,
why would you get paid so much if you weren’t hot shit?
Of course, that question was answered
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
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:
- technical planning does need to happen in a multi-team
- 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.
Here at DrunkAndRetired.com we are, of course, obsessed with Enterprise Software. So, e highly recommend and urge you to check out Ed Gibb’s funny (as in “funny because it’s true”) post on Enterprise [Software] Smells.
I think most dorks reading this have either (a.) experienced, or, (b.) written software that does each of the things in the list, such as my favorite one:
Support involves filing trouble tickets or issues that are never resolved though sometimes promised to be in the next release.
The thing is, the analogy was in our minds, but we never paint the final stroke.
Which is, you hold what Barbara Streisand believes under scrutiny and use it to discredit all arguments from the left, and that is you cannot use a single article on wikipedia and use it to discredit the entire enterprise.
As always, we’d love to hear your comments.
Now, I don’t really care about printing the photos I upload to flickr, but Our friends The Late Majority (prolly Early too) sure as shit do. I tell them all about flickr, and they ask, “can I print photos?” and I stutter around, and finally tell them “no.” Then they sigh and give me that “oh, Coté! I’m gonna have to watch you and technology!” look.
And then they go back to ofoto.
So, maybe now flickr will seem even more real and viable to the curve dwellers.
It’s $0.20 if you pick ’em up at Target (sadly, no Austin service yet), and $1.49-1.00 for batches of 25 mail delivery.
IBM released an enterprise app called “Workplace for Business Strategy Execution,” or WBSE recently. It’s supposed to take corporate strategy, and break it out into tasks employees can use. And, of course, there’s dashboards so that “leaders” can keep track of progress on those tasks.
Here’s more from an article:
Users can take a business strategy, such as delivering a new product, and divide it up into a number of objectives. Each can then be assigned to a specific end user, or role, with a customized interface that displays the data that end user needs to execute and track their responsibilities within the overall project.
The WBSE interface includes four main concepts that are implemented using software from partners. Scorecards monitor not only overall progress for higher-level executives, but also overall progress per user/role within the overall strategy. A dashboard provides the individual user with relevant information on a day-to-day basis.
So, the big question is: what is this stuff?
From what I can tell (mostly from the video), the theory is something along the lines of applying Agile thought to business, and the software is a project management tool for managing that. So, you have “corporate strategy” (themes) that’re broken down into stories and tasks. The workers can see how their stories and tasks fit into the over-all themes, and everyone can track progress on those stories and tasks on dashboards. I mean, this is enterprise software: you gotta have dashboards, baby!
BSM for People
An earlier article from last month has an interesting take on WBSE, that it’s a sort of BSM/systems management for people:
The move is really an attempt by IBM to dumb-down performance management, which shares a similar goal of linking strategy to operational execution. Of course performance management is simply more than just rolling out a set of dashboards; the hard work goes on at the back-end. But what’s interesting about IBM’s BI dashboarding solution is the real-time linking of collaboration and other context-sensitive tools to drive real-time responses and actions based on objectives directly from business user desktops without having to get IT involved
The Single Pane of Glass
Also, check out one of my posts from May of this year for a vaguely related “shit you need to do today” thing with Greasemonkey. If anything, keeping a simple to do list in mind is a good point of reference for decoding the meaning of “Workplace for Business Strategy Execution” and other large phrases.
I updated my site JAASBook.com with a short overview page and complete listing of all the chapters in my JAAS book. They’re currently PDFs, but that should be just fine for everyone.
So, enjoy the book…if you’re into Java Authentication and Authorization Service ;>
Those of you men-folk out there who live with women-folk have no doubt learned that women’s clothes take quite a lot more attention when doing laundry. Men’s clothes — at least this mans’s — require almost no attention: you just make sure there aren’t any pens in the pockets (sometimes you skip this step) and throw everything into the washer, then throw it all into the dryer.
Nicer Clothes Require More Attention
Women’s clothes, of course, require all sorts of checks: Is it a bra? If so, skip the dryer? Can this be put in the washer, but not dryer? Can this even be put in the washer? Womens clothes, you see, are typically much nicer, and, thus, complex and brittle (in the software sense) than men’s. (Again, at least this mans’s.)
It’s enough to make a man-head all jumbledy and result in a long, difficult process of twisting several bras around and shrinking all sorts of frilly, silky shirts and skirts.
So I got to thinking this afternoon while I was mindlessly moving a lump of whites from the washer and dryer: this sounds like a job for RFID! Each piece of clothing would be tagged with a wee RFID that would broadcast (or whatever) at least the answer to the questions:
- Can you be put into a washer?
- Can you be put into a dryer?
The washer and dryer would scan for clothes before starting and make a terrible beeping noise. Hopefully it’d give you a read-out better than “Err,” but even that would be better than destroying more of your sweety’s clothes.
This is the kind of thing that I think RFID will make money from right off the bat: (1.) preventing people from doing stupid things and (2.) “thinking” for them. The kinds of things I’m thinking of are even simpler than the classic “you need to get milk” RFID examples (the system needs to be smart enough to know that you had milk and that you’d want more milk).
For example, if I buy the wrong car part and jam it into my car (“jam” because it’s the wrong part), with Stupid RFID, my car would beep at me and tell me “wrong part, dumb-ass.”
The mind can easily cook up more scenarios like these.