1. Source code branching and merging made easy with distributed version control
2. PM Classic: "Adrenaline Junkies" and "Mañana"
3. Gantt charts and software projects
Distributed Version Control Systems (DVCS) represent a massive improvement over
centralized version control systems such as CVS and Subversion. DVCS makes developers'
lives better by making it easy to merge changes and simple to maintain branch repositories
for new (or experimental) development.
In this StackExchange question, Fog Creek's Jason Rosoff shows off the
basics of branching and merging using
Fog Creek Kiln:
"Kiln Branch and Merge How-To"
Adrenaline Junkies and Template Zombies is a Project
Management classic by a group of six experts who have collectively spotted 86 distinct
patterns of Project Management behavior. As the introduction puts it:
Most people who do project work are pretty good at pattern recognition and derived
hunches ("I sense that this project is headed for disaster"), but not
so good at abstracting their patterns into a more usable form. Thus this book. We
six authors have put our heads together to articulate the patterns we've been
absorbing during our combined one hundred and fifty years of experience.
The first pattern it describes is the (often unfortunate) culture of "Adrenaline
Junkies:"
Pattern #1: Adrenaline Junkies
The organization believes that frenzied activity is a sign of healthy productivity.
The phone rings.
"We really have to fix a requirements specification this week. Can you come
and see what you can do with it?"
"What's wrong with the specification?"
"We were in a hurry, so we got a bunch of new hires to write it. We think they
don't know what they're doing."
"Then wouldn't it be more productive for us to coach them in writing requirements?"
"But we need the specification this week."
"Okay, I'll come tomorrow."
Two hours later:
"Can you come and look at our estimates?"
"What happened to the specification?"
"We don't have time. We'll go ahead with the requirements as they are.
My boss wants the estimates to be handed in today..."
You probably recognize the characteristics of the adrenaline junkie organization:
Priorities are constantly shifting; everything is needed "yesterday;"
there's never enough project time before delivery; every project is urgent;
and the urgent projects just keep coming. Everybody is frantically busy... all the
time.
People in these organizations do not think strategically. Work gets done on the
basis of its urgency alone. Unless a project's "frantic factor" is
high, it will be ignored—even though it promises a significant long-term advantage.
It will remain ignored until it suddenly (surprise, surprise) becomes urgent. Adrenaline
junkies believe that the best way to work is not by planning but by running as fast
as possible.
This kind of culture equates desperate urgency with effective performance. If you
are part of such a culture, it is difficult to avoid becoming addicted: Urgency
is encouraged. The programmers who work through the night to meet an absurdly short
deadline are lionized (never mind the quality of what they deliver). Teams that
routinely come in on the weekend, just to keep up with their workload, are regarded
more favorably than those that don't. Moreover, if you're somebody who does
not work excessive overtime and are not frenetically busy all the time, then you
are not "one of us"; you are not one of the busy-busy-busy people who
keep the organization afloat. Non-heroic activity is plainly not acceptable.
Most adrenaline junkie organizations contain at least one bottleneck. This is the
hero who makes all of the design decisions, is the only source of requirements,
or makes all the architectural decisions. He is playing two roles: One is to make
himself appear to be busier than mere mortals can hope to be. The second is to produce
a logjam of decision-making that once released, causes the rest of the organization
to become even more frantic.
Most adrenaline junkie organizations enthusiastically embrace the customer service
ethic: They confuse responding to urgency with admirable responsiveness. When a
customer makes a request, regardless of its potential for profit (or even usefulness),
it instantly becomes a project, often with a ridiculously short deadline. (See Pattern
38, "Project Sluts," for more on this.) This new project naturally increases
the workload on the already overloaded heroes, so more busyness comes about—all
of it feeding the insatiable need for the organization to be very, very busy. Many
of these organizations think—falsely—that this is what being agile is
all about.
Adrenaline junkie organizations react rather than consider. The result is that most
things are in a state of flux, and nothing is settled or long-term. The fluid state
persists: Specifications are fluid—nobody really knows what to build. Designs
and plans are fluid—they will almost certainly be changed tomorrow. There
is no attempt to prioritize by importance or value—there is just urgency.
There is no Betty Ford Clinic for adrenaline junkie organizations, and there may
well be no cure short of eliminating the adrenaline junkies and replacing them with
managers who understand that the organization is most effective when it is not in
a state of emergency. Such a replacement may well be impossible, though: It is usually
upper management, and often the CEO, who wants to see the organization in a constant
state of frenzy. After all, frenzy sustains the illusion of healthy productivity.
And if the managers of a company are adrenaline junkies, then project teams are
not far behind.
Adrenaline junkie organizations don't always fail. Some of them continue to
operate at a frenzied pace for years. But none of them can ever build anything big—that
requires stability and planning. Junkie behavior is not scalable—it is limited
to what can be achieved by a relatively few people working very, very hard with
little direction or strategy.
Naturally, in any organization, there are times when things need to be done urgently,
and there are some roles in an organization that need to concentrate on urgent tasks.
But all things are not always urgent, and all roles are not concerned with urgent
matters. Unless urgency can be replaced with prioritization and restraint, there
is little hope of curing the addiction of adrenaline.
But on the opposite end of the spectrum, there's "Mañana:"
Pattern #7: Mañana
We all have windows of time within which we recognize that we need to start moving
and keep moving to complete some work. Delivery dates beyond those windows create
no sense of urgency, and therefore little motivation to act.
What if Paul Revere took his midnight ride through the villages and towns of Massachusetts
shouting, "The British are coming! The British are coming! Sometime next year—I'm
not exactly sure when or where, but next year, the British are coming!"
You've got to expect that he just wouldn't have gotten the response he was
hoping for. He probably would have been met with angry shouts of "Put a cork
in it, Paul!" He may have even met with the occasional projectile chamber pot.
A sense of urgency is a magnificent catalyst for action. Remove that urgency, and
that action slides down the list of Things To Do Today. Other matters become more
compelling, and today is consumed by all other stuff that consumes days.
We all have windows of time within which we recognize that we need to take immediate
action in order to complete some work. For most of us, the window is about 30 to
90 days out. We can look at ourselves today, and see the path of work ahead for
the next 30-90 days. We can plan our work for those days, and we can feel the urgency.
We get a move on; we get an eagle-eyed focus on what needs to be done.
Outside that window is mañana. Mañana is our state of recognizing
personal responsibility to complete some work—without recognizing that we
must commence work now in order to be successful.
Most projects are longer than the human window of urgency. People cannot feel the
urgency in their soul when the organization tells them that it is incredibly important
to complete a project within the next 30 months. They hear it; they understand why
it is important; but a little voice inside their head says, "Thirty months,
by then you could be dead."
Big projects stay out of mañana by keeping most people focused inside the
window. They do this by directing the work toward tangible deliverables inside 90
days, often inside 30 days. You hear proposed deliverables like these:
"Let's build a prototype of the trading screens—just for the bond
traders, within the next two weeks."
"Let's build the code so the system can take in new orders, check if the
items are in stock, and send a message to fulfillment. Don't worry about changed
or cancelled orders or anything else, just new orders. We should be able to demonstrate
this by mid-month, all right?"
The wonderful thing about project people is that they can take on these near-term
tasks as though they are up against the actual finish line. On basically healthy
projects, people will work hard and stay focused on the prototype due in two weeks,
just as if they were delivering the final system in two weeks.
Be careful, though: The key is a real deliverable at the end of the window. Progress
alone is insufficient. Something like "Let's get the spec to fifty percent
complete by the end of May" just does not supply satisfying closure. The little
voice says, "Fifty percent-that means not done by the end of May. What
other work do I really have to complete by then?"
Watch out for a particularly virulent form of mañana: inordinate amounts
of time spent ready to get started. Everyone spends time hunting for the perfect
tools to support testing; everyone debates exactly how the libraries will be set
up to provide the best possible support for developers. This time has much more
value if it is saved for finishing the work at the end of the project.
Shiela Brady, recalling her days as a project manager at Apple, had this observation
about mañana versus what is in the line of sight:
"There has never been a project that, as it came down to the finish, wouldn't
die for an extra week on the schedule."
Like all good project managers should, Sheila realized that the early days of the
project are not treated as preciously as those at the end--and that the best way
to get going is to get going, not mañana, but today.
Have you ever worked with "Adrenaline Junkies?" Have you ever been
faced with a far-off "Mañana" deadline? Or has your organization
found the perfect balance of urgency and long-term planning?
Discuss it on our StackExchange
site:
Developer Newsletter 01/05/10: "Adrenaline Junkies" vs. "Mañana"
Gantt charts, a means of managing a complex network of project dependencies, are
99 years old. (Older than the Turing Machine!) Do they have a place in software
project management? Fog Creek's Rich Armstrong explores the question:
"Why doesn’t FogBugz offer Gantt charts?"
Text passages from Adrenaline Junkies and
Template Zombies printed with permission from Dorset House Publishing.
Copyright notice:
Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior.
ISBN: 9780932633675. Copyright (c)2008 by Tom DeMarco, Peter Hruschka, Tim Lister,
Steve McMenamin, James Robertson, and Suzanne Robertson. Reprinted by permission
of Dorset House Publishing.
Available on Amazon.com:
http://www.amazon.com/Adrenaline-Junkies-Template-Zombies-Understanding/dp/0932633676/ref=sr_1_1?ie=UTF8&s=books&qid=1261170911&sr=8-1
|
