When your project goes badly...

I recently blogged about
"Projects That Suck":
those times when software development eats all your funding, chews months
off the calendar, and saps your energy so you feel drained.

I see this pattern all the time and it's sad. It's a waste
of money, sure—but it also:

causes personal stress and illness,

limits the careers of your best people, and

makes you look bad to not only your immediate boss but company-wide (because no one wants to be the "problem child").

It also undermines the image of software development as a profession,
so it makes me look bad even if I'm not there!

Even worse, many software development projects end up never getting done
at all! So for all that sucking you end up with a complete
waste. An expensive mess.

You're under serious pressure to make things work. Now!

You've tried some things.

When a project gets in trouble, most teams try to:

work more hours, often working evenings and weekends to get more done;

waste a lot of time focusing on a mythical single cause;

complain and blame others for the problems;

bring in more people;

try different technologies; or

throw more money at the problem!

But these common solutions don't work!

Extended long hours don't really help because your people are already
working hard, and pushing it just wears them down. If you add
more people, getting them up to speed becomes a small
project of its own. Finger-pointing and technology thrashing do not
actually move the project forward.

Having more status meetings is the worst idea of all. Even
when the developers are not personally invited (because you need
them on task) they are repeatedly taken off task to provide all the
details that get fed to management. It's not like team leads and
project managers know this stuff automatically; they have to ask
developers, whether it's in meeting or out of meeting. Still a waste
of their time and momentum.

"Insanity," Einstein was claimed to have said, is "doing the same
thing over and over again and expecting different results." What
are you doing differently?

Yes, your project can be saved!

Projects that suck are neither happenstance nor a law of nature. They
get in trouble from a combination of:

vague or unrealistic plans,

skill mismatches,

misfortune,

and sometimes just too much persistence with a plan that's not working.

A planning regime that doesn't take into account
the way creative people actually work makes it even harder
to recover from mistakes, stay motivated, and maintain high
productivity. (Yes, programming is creative work.)

Rest assured, you don't have to put everything up for grabs, but
for many shops those very linear methodologies like Rational Unified
Process (RUP) or the classic "waterfall" don't work either. They're
adapted from manufacturing or industrial processes that have a lot
more repetition than anything you ordinarily see in software
development. Software is so fluid, often so vaguely defined,
and so subject to change, that trying to plan all the
details up front is unrealistic and just makes things harder.

Why you need Agile. Now.

I've worked with many companies over the years who have adopted various
bits of what are now referred to as "Agile" development practices. Agile
is fundamentally a set of values
that favor:

Individuals and interactions over processes and tools;

Working software over comprehensive documentation;

Customer collaboration over contract negotiation; and

Responding to change over following a plan.

These values take the shape of
twelve principles
such as doing very frequent software updates, not overworking, and maximizing
the amount of work that you can constructively avoid doing.
Those principles are implemented as actual methodologies that
various parties have figured out and made to work. A few of well-known
ones are Scrum, Kanban, and Extreme Programming.

What's with the "Emergency" part?

I've found that Agile is rather poorly understood
in most places, as though it were a catchy term for ignoring
management and not doing any planning. Thus the cliché: "We tried
Agile and it doesn't work."

The whole idea of Agile is that you do what works!
If it doesn't work, and you keep doing it, you're not Agile!

The thing is, adopting Agile is really difficult if you just jump in.
Even if you read all the great books on the topic. You need help, and
when your project is already in trouble you need the quickest payoff
first.

Introducing Emergency Agile!℠

That's why I created this program I call Emergency Agile. It's a
small subset of Agile practices, the ones that you can implement very
quickly with immediate results. It goes like this:

Week 1: Begin with pair programming

On the very first day, make it a Monday, we start right in with the
Pair Programming practice. It's exactly what it sounds like: we put
two programmers onto one set of tasks—using one computer—for part
of the work day.

"When I took on an Oracle .NET project
without knowing where to begin, let alone how to code in C# or
JavaScript, definitely the most efficient way to learn was to pair
up with you. Of course in the beginning we were not "pair programming,"
because you were doing all the work, but after a few weeks I was
able to start producing some of my own code and making sense of the
overall structure. Having you at my elbow to encourage, correct,
and suggest made the process very workable. In the end I was able
to take over and finish the project, and I have been maintaining
it ever since. Thanks Mark!" —Beth Kujala, independent
developer

Many people find that a little too intimate to do all day, especially
in a cubicle environment, and it's something that you're better off
being taught by example. So I rotate among your team members at the
beginning, taking an hour or so with each one, switching hands at
the keyboard as the situation warrants, asking questions and
preventing defects before they have a chance to occur.

As the week progresses, we'll put developers together on their own
(without me in the pair) more and more. By the end of that first week,
everyone will have had substantial pairing experience.

You'd think all this cube-sharing would slow you down. In the
very beginning, that's usually true: two programmers working
separately may get more code written than two at the same computer.
Sure. But the defect rate goes way down almost immediately,
which cuts down dramatically on time-consuming rework.

And you'll quickly find that a good pair gets almost as
much code written as two individuals; it's a matter of
finding a rhythm, learning each other's habits, and developing
trust.

Week 2: Start a Daily Scrum

The second Monday, we'll introduce the Daily Scrum standup
meeting. Everyone's invited to that meeting, but only the
actual team members are allowed to speak. For real.

Scrum is a particular Agile methodology that's all about
keeping a project moving forward. A proper Scrum has
accoutrements and features like "burn charts" and "product backlogs"
and whatnot. I'd be happy to explain them if you'd like. But when
you're behind the eight ball, I'm saying that the Daily Scrum meeting
itself gets you the greatest positive effect in the shortest time.

Here's how a Daily Scrum goes: Every team member
should be there, including developers, testers, and business analysts.
The project manager might be there as an observer. Other people—such
as you, the project owner—are welcome too, but it is important
that the observers stick to observation. They're not there to talk
or ask questions.

"[Mark] provided the kind of close cooperation and creativity that this very challenging project needed." —Jim Lynes, Things Remembered

The gist of the meeting is that I ask each team member, one
at a time, these three incredibly simple questions:

What did you get done yesterday?

What will you get done today?

What obstacles do you face?

That's it! I take down the answers, and we resolve "issues" outside
of the meeting. If an "issue" cuts into a developer's (or tester's)
time, I'll arrange the resources to solve it so the developers and
testers don't get distracted.

It is very important that the team members have no other status
meetings. The idea of the Daily Scrum is to keep things
moving, and extra meetings interrupt the flow.

Week 3: Add Information Radiators

As a manager, the Project Owner, you still need to see what's going on.
If you're depending on this software project, status meetings aren't good
enough. And it's so hard to get the straight story when it's filtered through
a layer or two of management. You need transparency.

An "information radiator" is any kind of highly visible display,
in the team's work area, that gives useful (and changing) information
to any and all viewers... the same way a regular radiator puts out
heat whether there are a dozen people in the room or none. The beautiful
thing about the "radiator" is that the information comes to you
instead of your having to go looking for it. It really is in the air!

That's why in the third week, we continue the pair programming and
we continue the Daily Scrum, but we also try several different ways
to make information about the project unavoidably visible
to team members, passers-by, and the project owner (you). That might
include a modified Kanban board (which I can also explain if you
like), a simple task priority list, maybe a wall chart full of
color-coded sticky notes for known defects, or something heretofore
unheard of.

The point is to make the project visible to everyone at all times.
No obfuscation, no waffling in status reports, no half-truths.
Information is power, so hoarding information prevents power from
going where it needs to. Information Radiators stop the hoarding!
They make it really easy to know what's going on, and
really hard to provide information that is overly complex,
contradictory, or just wrong.

Bottom line: You will know where things stand,
what you are getting for your budget, and what's left to do.

Week 4: Consolidate and review

After three weeks of all this change and growth, there will surely
be some loose ends, another Agile practice to apply, or at least a
need to refresh and review. We plan on a week for that too.

If there is time, we'll set up a Product Backlog (a prioritized
list of all the possible product features that aren't being worked
on yet) and from that a Task Backlog (a similarly prioritized list
of the nuts-and-bolts items that developers and testers have to
do). These make great inputs for the Daily Scrum meeting, because
a team member's answer to Question 2 ("What will I do today?") can
come from whatever's next on the Task Backlog. Thus guaranteeing
that your team is always working on the most important things.

Bonus! Homemade Indian food on Fridays!

My friends and many colleagues are already aware of my finely honed
cooking skills. When you get the Emergency Agile program,
it comes with homemade Indian food for each Friday's
team lunch. My Red Aloogobi (not pictured here—normally a more yellow
kind of dish, with cauliflower and potato in a light curry sauce) is
already a legend.

Never underestimate the power of home cooking to build work relationships!

What you might ask

So this is Emergency Agile! It's a month-long process of getting your
troubled software project back on track, engaging your team in
sharpening their skills and motivation, enhancing communication,
and making it all transparent to you.

Who is this for?

You make me think differently. Not so left-brained!—Trish Rouru, Wingman NPO

Since I borrow so much from Scrum practices, the ideal team
size is around seven members. If more than about a dozen, we might
reorganize into two or more Scrums, but the rest of the program works
as designed.

Your team will make great strides with Emergency Agile if
you sincerely seek success, rather than the ability to redirect
blame or to prove a point; if you are strongly biased towards results
over methodologies; and if you are very willing to be surprised,
because Agile practices aren't like what you may be used to.

What kind of languages? Platforms?

Emergency Agile isn't a technical system; it's a system of organization
and teamwork. So it doesn't matter what kind of languages, tools,
platforms, and environments you're into. .NET, Unix, iSeries, mobile
and smartphones... the Emergency Agile practices work regardless.

Can we afford a whole month of training?

No! This is a whole month of accelerated development in which the
training is in the doing. Everyone's read about Agile, but the way to
learn is to see for yourself. Rather than being time away from work, this
month is time more focused on achieving your project goals!
Quite honestly, this is program is short-term gain and
long-term gain. Your team will make more progress in this single month
than ever before, and those productivity gains will be permanent.

How much does it cost?

Emergency Agile gets high-impact projects back on track, delivers
long-lasting results, and makes your whole team more productive.
My fee for the month-long program is $8,895 plus any travel expenses.

Isn't that a lot of money?

I just heard from a colleague who got called in to deal with a
project, employing about twenty professionals, that wasn't going
well. Because the company couldn't adapt their development process
for the circumstances of that project, they finally had to shut
it down. With six million dollars lost.

If you think you might need Emergency Agile, you've probably already
invested much more than that in your project, with unhappy
results. Continuing on that path, even if it appears to be less
expensive, won't get the job done. And nothing's more
expensive than a project that never actually delivers!

It's not just the money though. When you commit to Emergency Agile,
you're involving your whole team in a new way of doing things. It's
somewhat informal at times, but don't let that fool you: it's also
a lot of work, and it requires a significant mental shift. Agile
practices are effective because they cut through the
defensive habits and tactics that keep software teams stuck. So
you have to really want to change. The motivation to do
this is probably harder to come by than the money.

One other thing

Few other consultancies that advertise things like
"Agile Coaching" reveal their fees publicly. And they make you set
up an appointment even to find out what they actually do.
My costs and program are right up front! I think that's important
when information and transparency are essential to the process.

I feel your concern about the price though. It's not trivial, but
then again continuing on the path you're on isn't without its own
costs. If you're not ready for the dollar commitment, let's hang
out on my blog for
a while instead. We can talk over your particular situation in the
comments.

Isn't a month a long time?

I'm more concerned it isn't long enough. We're talking about changing
a lot of habits here. Remember, Emergency Agile doesn't just move your
current project along, it makes your whole team smarter and more
effective. It's not that much time considering the benefits.

What if it's not an emergency?

Do you mean it's not an emergency yet?

Seriously, Emergency Agile is a pretty good way to adopt Agile
methods even if you don't quite have a gun to your head. I've
organized the four-week sequence with "projects that suck" in mind,
but almost every team can benefit from pair programming, the Daily
Scrum meeting, and information radiators. It's a great start.

Why should I trust you?

"[His work was] always well thought out and usually exceeded customer expectations." —Kathy Crowley, PMP

I could quote someone who loves me, and I could say reassuring
things about my steadfast loyalty to friends and my kindness towards animals, but
that's probably not the kind of trust you mean. This is more like
will-I-screw-up-your-project kind of trust, right? Well.

I've developed all kinds of software for over twenty years and have
personally worked for fifty different organizations in that
time, giving me ample opportunity to observe what does and doesn't
work. So these techniques aren't just theoretical, or picked up from
a book—they're things I've actually tried, refined, and adapted.

Also, my blog has a
couple dozen posts about how I approach the Agile concept,
how I solve problems, and how I deal with people. You can also get
my groundbreaking ("accurate and fun!" according to one executive)
paper on the eight reasons why software
projects suck and how to make them not suck. (It's an opt-in
link. Hope you don't mind.) After reading all of that, you'll have
a very good idea of what I do and how I do it.

Where are you?

Can we cut the travel costs and do this remotely?

I'm telling you, Agile is an incredibly personal thing. Books are
good, videos are good, remote is good, but... no. You really do have
to be with people and breathe the same air for this to work.

And it's guaranteed.

The practices that make up Emergency Agile are proven to get major
projects done faster and with far fewer errors. That's why I use it!
And it's why I can offer this money-back guarantee.

It's simple; the process works when we work the process. Working the process
means:

Full participation in the Pair Programming week;

Full participation by all team members in the Daily Scrum meetings;

Open communication via the information radiator system; and

Weekly overview meetings to develop metrics with the project owner and project manager.

The guarantee itself is that if the agreed-upon metric goals are
not met, I will continue working with your team to ensure that they
are. Or alternatively, if it becomes apparent that this just isn't
possible, I'll return your money.

I sincerely care about your organization's success. When we work together
and get great results, your project succeeds, you succeed and your team
succeeds. And when you succeed you refer me. In my business, word of mouth
is the best marketing and I really want you to have a great reason to tell
others about me.

Ready to get started?

If your software project is running late or not getting done at all,
just fill in this easy contact form and we'll talk. Or just call me.
It's 216-661-2000, US Eastern Time. I want to hear from you!

(Feel free to email
if you like, but it's probably a good idea to use the phone or the
contact form too just in case my spam filter silently muffles your
email.)

Your name:

Company:

Phone:

Email:

How did you find this website?

Anything else to add?

No pressure. This is all about finding out if Emergency Agile
is right for you! If you're really not sure, go ahead and submit
the form. It's basically impossible to hurt my feelings by talking
it over and deciding this isn't quite what you need. But I'd feel
really bad about it if you skipped the opportunity to find out!

Privacy Notice: I will not rent, lend, or give your email address to any third party, nor will I publish your name, without your prior written consent. You'll never get unsolicited email from a stranger as a result of your relationship with me. You can unsubscribe (remove yourself from my contact list) whenever you want.