Plans are for wussies

Several months ago, I posted some statements I heard from "professionals" regarding testing, standards, and code review. Since then, I've heard several more gems and here are a few on planning that I thought worth noting.

These statements are from the same person on the same day pertaining to the same project:

"We have a plan. The problem is not a lack of plan. The problem is our communication."

"We don't need a written plan for this (release of a new product). We are experienced professionals and we know what to do. Writing out a plan is to make other people happy; people who don't have to do the work and don't know how to do it."

"You can't plan for something like this. Things come up and you just take care of them."

So let me see if I got this one right.... You have a plan for the thing that can't be planned, but since you are professionals you don't need to communicate the plan for the thing that can't be planned because only ignorant observers need plans? Is that it?

Let me share with you some common challenges within this environment:

1. Team members have differing expectations of what is to be done, by whom, and when
2. Team members have no idea what other people on their team are working on
3. Almost all projects are late due to unforeseen circumstances such as the code that was written won't run in the target environment (actually happened)
4. Projects get delayed because other departments are "uncooperative "
• Other departments don't know what is going on
• Other departments want justification for the tasks they are told to do
• Other departments require more heads up on simple tasks like configuring a VLAN and building all the servers to the unwritten specification that is needed immediately
• Other departments won't violate security standards or other documented practices in order to "get it done"
5. Once a project "feels" like it is about half-way complete, it is "almost done". Sometimes projects are "almost done" two or three times as long as any other project phase.
6. Completed work sits on the stage server for months or even years because nobody tests it and certifies it to go to live.

Final note - lack of planning != Agile

Getting Some Help

I'm not talking about seeing a phychologist or psychiatrist. I'm not talking about a 12-step program. And I'm certainly not talking about booking a stint on Dr. Phil. I'm talking about reaching outo to your team for input, for feedback, and for another pair of hands. I'm talking about actual teamwork.

Developers who struggle with the same piece of code, won't leave their cube, won't acknowledge a problem, and refuse to get anyone else involved. They sometimes become paniced or desparate. They stay extra hours alone, suffering under their self-assigned yolk, blaming others for what is happening.

Managers who can't deliver a project on time and whose staff is unmotivated. Half of the staff know nothing about the project, tasks are not getting done, and new unforseen issues keep popping up. But the manager will tell you they're doing everything they can while they refuse anyone's help. They too become paniced or desparate, putting in heroic effort when it is all but too late, suffering under their self-assigned yolk, blaming others for what is happening.

I've seen this all too often. I've been these people.

As a manager, it is not your job to know every last detail of the project. As a manager, it is not your job to assign every task. You are not supposed to have all the answers or even understand every part of the solution. As a manager, it is your job to enable the team, solicit their input, guide them, direct them, clear their obsticles, and let them do their jobs well. This doesn't mean you aren't in control. You set the standards, you set the expectations, you monitor what is happening, you address the issues, and you participate without dictating.

So why did I call this post "Getting Some Help"?

Because the help you need comes from your team. As a team member or as a manager, unless you are literally a team of one, help is always available. Ask your fellow programmer to take a look at the code that haunts you. Ask your team to review the plan or ask your team to help put together the plan.

What does it mean to be Agile?

What is Agile?

Is it XP, SCRUM, or some other process? If you are using all of the SCRUM mechanisms, are you Agile?

Agile is a philosophy, NOT a set of practices. This is not to say that those that use SCRUM mechanisms are not Agile. It is only to say that implementation of mechanisms does not make you Agile. And most certainly, failure to implement certain mechanisms does not mean you are not Agile.

I've heard on several occassions statements such as "Oh, you don't do pair programming? Then you're not doing Agile." Pair programming could be replaced with standing meetings, weekly iterations, monthly iterations, test driven development, or any other mechanism.

I intend to discuss more about Agile in this Blog. What do I think it is and what have I learned about it.