Posts Tagged “planning”

Superflu weekend struck our family — and all the families in our daughters’ playgroup. Based on preliminary reports (and my own condition) this could stretch into superflu fortnight.

This reminds me to ask the question: Has anyone planned for sick days in February?

I spotted a trend a few years back that I blogged about in 2009. Now I’m convinced that February is the Northern Hemisphere’s worst month for sick days. And I do account for February sick days in the delivery commitments that my teams make.

Of course, there are other perspectives. I once had a manager who, when contemplating the likelihood of illness-reduced delivery in February, rebutted: Plan at the standard velocity. That’ll encourage the healthy employees to work overtime and cover the shortfall.

He was all about morale, that one.

Comments No Comments »

Most project managers want to track actual effort and dollars toward the completion of their projects and deliverables. The goal is obvious and laudable. By knowing the actual cost of something we can provide more precise estimates the next time around.

However, I don’t find actuals useful. I have little faith in the quality of the data that gets collected. Low-quality data is, at best, not useful. At worst, it will lead you to wrong conclusions and bad decisions.

Four issues seriously degrade the reliability of actuals.

  1. We, as individuals, remember pain. And we are much more inclined to remember when we took 100 percent longer to complete a one-day task than when we went 50 percent under on a two day task.
  2. Professionals prefer producing results over pushing paperwork. Sometimes we don’t put any mental cycles to tracking and remembering our effort against discrete activities. When the time come to push out the paperwork we can do no more than look back at our estimates.
  3. Sometimes we don’t work in sequence. Tasks get entangled. Priorities shift. We deviate from our plan to help other team members. The work gets done, but there’s no accounting for where the effort went. Again, our only fallback is our estimates.
  4. There is an expectation that each of us contribute a minimum number of hours per week, regardless of whether one is an employee, consultant or contractor. Will there be a problem if my actuals don’t add up to 40 hours (or more) a week? What about meetings, email, chores and helping other teams — where do those things go? No matter what reassurances you provide, too many of us will ensure that our weekly actuals total to the company work week, regardless of our actual effort toward shippable product.

Is it really worth spending your team’s limited resources on this?

Comments 5 Comments »

For some this is a heinous anti-practice. For others it’s standard operating procedure. Either way it’s the fast track to project ruin.

Plan and Ignore is the practice of quickly drafting a project plan (typically to satisfy an external demand; typically in Microsoft Project) then tossing the plan and never looking back. This happens for any number of reasons. Some people don’t know how to plan. Some people don’t know how to track. Some simply don’t want to invest the time to do either activity correctly.

Plan and Ignore should never be confused with even the simplest forms of agile planning. Even the lightest-weight planning (such as a product backlog, t-shirt size estimation, and a burndown chart) can keep a team free of this anti-practice trick-bag.

The fundamental problem with Plan and Ignore is that no one actually knows the status of the project. Behind? Ahead? Safely on track? Likely no two people on the project team will give you the same answer.

And when your team has no consensus on its status all manner of bad mojo can result.

If you are actually behind, the people who don’t see this will likely be busy cathedral-building and apple-polishing instead of developing the much-needed ladder that the team will use to climb out of its current hole.

Furthermore, lack of agreement on a team typically raises the attention of management, especially when that lack of agreement is around status. But management often does not know how to be helpful in situations like this. They’ll demand to see status against the current plan, go hulk-mad when they discover that there is no current plan, demand a new plan be drafted, and waste yet more precious time prying tracking data from team members who are frantically trying to not fall further behind.

Finally, if management doesn’t cop on to the lack of consensus then the team will know they are behind only when they reach a consensus on the matter. Typically this happens one week before a major milestone, at which time the team recognizes the obvious – that it is no less than four weeks behind. And that’s when the fit will really hit the shan.

Comments No Comments »

Self-Reported Reasons for Sickness -- Eurofund Report NL0607NU04

I think I’m seeing a pattern here. For the second year in a row a blight of sick days has swept the office in the second half of February. Currently, we have multiple teams sorting through their iteration backlogs to account for and replan missed commitments.

This raises an interesting question. Next February, do I ask the project managers to account for potential sick days (basically, commit to less) in their iteration and release planning activities?

Perhaps that’s taking things too far. But I’m going to be on the lookout for this one next winter.

Comments 1 Comment »

In my last post I mentioned the Iteration Zero technique in passing. I’m going to tackle it head-on today.

Agile teams strive to deliver functionality that can be touched or even used by the customer at the end of the first iteration. Sometimes, however, it does make sense for the team to focus on building its foundation before delivering functionality. This may be the case for larger applications, for teams new to agile development, or for projects where the the features are still extremely fuzzy. These are perfect opportunities to execute an iteration zero.

Read the rest of this entry »

Comments 9 Comments »

“Where do user stories come from?”

This is a question that I hear constantly from people new to agile development. Lots of places, is the stock answer. User stories — or features — really can come from everywhere, as anyone on the team may have a good idea and propose it. Another common answer to this question is the Story-Writing Workshop, which is a good technique for quickly collecting a diverse set of stories from many people. But when the team’s customer already has a decent idea of what he or she wants built, and no user stories have yet been collected, the Feature-Building Workshop becomes the sharpest tool in the shed.

This is also a great Iteration Zero activity. Read the rest of this entry »

Comments 2 Comments »