|
|
|
|
|
Tales of Fragility
Some
business organizations are bravely retro about their software goals. Their fear
of change is a greater motivator than their mixed history of success in
delivering working software. In these organizations (and they come in all sizes)
the technical management is quite often represented by managers who were COBOL
or RPG programmers 20 years ago, moved into middle-management at the advent of
client/server technology in the 1980s, and have no development experience in
today’s distributed, event-driven systems. They think in out-dated terms and
honestly believe that “programming is programming.”
Another
group of companies comprises those that say they want to change (because of
their checkered history), embrace the latest buzzwords and continue to do the
same things they have done in the past. They sound committed to change, but the
reality is quite the opposite. BRUF―Big Requirements Up Front
On
one large project I heard a manager say, “we’re going to iterate after we
get all the requirements”. He was
dead serious: they had engaged 9 analysts for 6 months developing what they felt were
requirements. This quote quickly became a slogan of gallows humor among the
developers, but it was indicative of a major fragility on this project.
This
was a project fraught with uncertainty. The hardware was new, there was huge
uncertainty about the features needed, and the development team had only passing
familiarity with the new software technology chosen for the system. The
iterative, incremental approach is made-to-order for this type of project so you
can get early and continuous validation that you are on the right path. But the
waterfall approach that this company was actually following is best on projects
with known requirements, and with little uncertainty.
And
to my utter amazement, the developers on this project were actively prohibited
from writing code until the requirements were completed. When that day finally
arrived the business manager announced with a flourish of ceremony that the
functional group had that day signed-off on their last big deliverable of the
project― a total of over 300 pages of big deliverable. But when the
developers saw this document the unanimous response was, “But what are the
requirements?” Later I told that
manager, “On an iterative project, there is no such thing as a big
deliverable.” He didn’t understand.
A
justification for iterating is to “eat the elephant one bite at a time”
until you can determine just what the elephant really is. (Remember the story
about the blind men and the elephant?) BRUF
is justifiable if it is actually possible to capture all requirements up front.
But it usually isn’t possible. The requirements on any significant project
change over time, as does our understanding of those requirements.
An
agile culture will embrace these principles:
The
last principle that agile cultures adhere to is the most crucial justification
for an iterative, agile approach: you move forward so you can quickly
discover what you overlooked. It is easy to spend months trying to get every
last detail. But it is impossible to find everything you have missed until you
move to the next step in the process, and look at your system from a different
perspective. The project I have been discussing did not incorporate the humility
and tentativeness that is integral to an agile approach. Dis-Serving Your Customer
The
party who buys your product is not the only customer you have. A customer is
anyone who accepts a deliverable from another group or person. QA is a customer
of development; development is a customer of the requirements team. In any
delivery process it is the vendor/supplier who determines cost, and produces and
transfers the deliverables; it is the customer who establishes the priority and
acceptance criteria for those deliverables.
On
a large business project the development group specified that the operational
requirements be delivered in use case format. The business analyst group,
however, delivered data flow diagrams, internal algorithmic descriptions, and
RDBMS table references. This was what they knew how to produce, but it was not
what the development team needed, or asked for.
This
gross mismatch in expectations was simply a perversion of the supplier/customer
relationship. On this project the supplier determined what the development group
needed, how much it needed, when it needed it, and the form in which the
deliverable (a requirements specification) would be represented.
In
an agile culture the customer’s (i.e., development’s) request would have
been honored. The customer would have established the format (use cases,
please), the priority and time-frame (these 3 use cases in rough form by next week, these next
4 use cases before the next iteration…) and the content (no ER diagrams or technical
details, just how the system interacts with its users). The supplier would have
been able to offer cost and conflict estimates to development, and they would
have agreed to a delivery schedule that allowed both teams to be fully occupied
simultaneously. In the project above, the process was emphatically linear, and
only the business analysts were doing any work while the developers waited…and
waited, eventually receiving a specification that still did not tell them how
the system should interact with its users. Model Hobble
Sometimes
values get turned upside down.
It
was a mission-critical project for a multi-billion dollar a year company. The
development team had never followed an iterative approach, and they were not
familiar with UML. Before the use cases were scheduled to arrive, we
petitioned management to obtain a large room where we could do the initial
modeling sessions on the project. Nothing could be found. We offered options:
The
development manager even volunteered to vacate his private office!
I offered my truck to carry whiteboards from the office supply store.
Silence.
Then we slipped our schedule for our first iteration. The next day we received word that we had a room
for modeling. The team immediately went to inspect. The room was in a locked and
secured area, 3 floors below the development team’s offices, it could
comfortably seat only 3 people (it actually was a closet)―and it had no
whiteboard.
We
never did get a whiteboard. We made do with clingy-sheets on the wall, and
getting very cramped together in the room. It was always warm, we fell over each
other, and we wasted a lot of time taking down the cling-sheets and stacking
them in order so we could transcribe the models on them.
Sometimes
values get turned inside out.
What
amazed me about this dysfunctional organization was the response we got from the
Vice President with direct organizational responsibility for this project. He said he
wouldn’t move the office furniture to create a modeling space for our team
because “it would
look like elitism and other groups don’t have the same space.”
Apparently he was not aware his rather plush and well-appointed corner office was
shouting “elitism”. But, that’s a whole different story.
Even
in hindsight it’s obvious that this organization purposefully chose to hobble
this team and not provide the resources the team said they needed to do the job
they had been assigned. The managers had clear reasons why they would not
provide a suitable room, why they would not buy 4’ x 8’ whiteboards, why
they would not deviate from the corporate standard office layout that had been
dictated to them by some anonymous bureaucrat who was clueless about what kind
of office a software developer needs. For lack of a $500 whiteboard, and an Allen wrench to take apart the modular office walls and move them 4 feet―and for lack of the proverbial “can-do” attitude, this software project was brought to its knees. And it never recovered. Actually, what was wrong with this organization is that if forgot what it's goal really was: develop software to support the business goals of the company. Instead, they focused on self-imposed constraints--better known as self-inflicted wounds. By thinking that every developer needed the same office space, that every project has to have only the resources available to every other project group, by trying to enforce some Public Relations image—they actually guaranteed they would not achieve their real goal.
In
an agile culture each group, each person is considered individually. If you
really need a tool to do your job, justify it and it will be obtained. If a room
isn’t suitable, or whiteboards aren’t available, any and every alternative
should be considered. On another project where we didn’t have whiteboards, we
did our modeling on the floor-to-ceiling windows of the office building. The
markers work perfectly, and people would come up to our floor just to see that
we really were drawing on the windows! All
we were trying to do was get our job done.
On
yet another project we simply commandeered a large conference room that
contained two large white boards. We put a sign on the door reserving the room
for the next 10 months. It made waves, but we made our case and it became
our war-room for the remainder of that (successful, commercial) project.
Sometimes
we actually value what is really important. |
|
