EppsNet Archive: Antipatterns

Antipattern: Daily Standup is Too Long

19 Jun 2014 /

Scrum recommends timeboxing daily standup meetings at 15 minutes. If you can’t finish in 15 minutes, there may be something wrong with your format.

Are you actually standing up? What are you talking about? Each person should answer three questions:

  1. What have you accomplished since the last meeting?
  2. What do you plan to accomplish between now and the next meeting?
  3. What, if anything, is impeding your progress?

Focus on accomplishments, not just assigned tasks, i.e., don’t say “I’m working on A and I’m planning to work on B.” Don’t have discussions. Anything coming out at the meeting that needs to be discussed can be discussed after the meeting. Try saying this more often: Let’s talk about that after the meeting. Immediately after the meeting if necessary, without even leaving the room, but not during the meeting.

Anyone in the meeting who is not responsible for accomplishing things during the sprint should not be talking.

Are you clicking through a project management tool to review what each team member is working on? Don’t do that. Anyone who wants or needs that information can click through the project management tool on their own time. Talk about accomplishments and blockers.

Why is this important? Well, you can meet or you can work, but you can’t meet and work at the same time. I recently observed a daily standup with 20 attendees (including remote workers) that was running 30 minutes a day, i.e., 15 minutes too long. They were losing 300 minutes per day (15 minutes x 20 people), 25 hours a week, and 100 hours per 4-week sprint.

Do the math on your own standups and decide if it’s important to you.

Thus spoke The Programmer.

Antipattern: Exactly on Schedule

18 Jun 2007 /

I work with a company that has the following set of milestones in its standard project methodology:

  • Vision/Scope Complete
  • Requirements Complete
  • Design Complete
  • Definition Complete
  • Build Complete
  • Test Complete
  • Rollout Complete

I’ve noticed an interesting pattern at the weekly enterprise status meetings: a significant number of projects report being exactly on schedule for each milestone — not one single day ahead or behind! — until they get to rollout, at which point they suddenly go several months late.

Some things can be faked and some things can’t. As long as you have milestones that can be met simply by declaring them done, or by signing off on a document, you can always hit them on time.

But when it comes to putting actual working software in front of a customer, that’s when you really have to deliver the goods, and that’s when the milestones start getting missed.

This is a very high-risk approach to software projects. Deferring testing to the end of a project guarantees that if your project fails for any reason — and if your testing is honest, there’s always some non-zero probability that it will fail — you will have already invested in the entire cost of construction.

That’s why the history of software engineering is littered with big-ticket disasters. You never really know what you’ve got until the end, after you’ve spent all the money.

It’s also a good argument for iterative, incremental development. If you have to deliver working software early and often, you can’t fake it.

Thus spoke The Programmer.

Antipattern: Bore People to Death With Your Job Ads

16 May 2006 /

A common piece of advice to job seekers is: Don’t focus your resume and cover letter on what you want; focus on how you offer what the hiring company wants. This advice also applies in reverse to a hiring company writing a job ad, but in practice, it’s almost never followed, which is why this ad for a position at the Irvine Public Schools Foundation (IPSF) jumped out at me:

Continue reading Antipattern: Bore People to Death With Your Job Ads