Software Development Best Practices Blog

Estimation Types

When I get asked for an estimate, my first response is not a cost, a date, or a functionality number. It is not even #NoEstimates. My first response is a question: "What type of 'estimate' do you want?" What I need to know is what will the questioner do with my estimate. I usually see six action types: They need to make a high probability (practically guaranteed) commitment to somebody else They need to make a go/no-go decision They need...

  1. Posted on August 26, 2013 12:41:PM by Earl Beede to Practicing Earl
  2. Agile, humor, estimation

User Stories Ain't Requirements

Ain't isn't really a word but people use it, so does that make it de facto a word? The gurus tell us user stories are not requirements but people keep using them that way so do we need to treat them as requirements? Actually, why don't we have requirements on agile projects? I think it is because Agile is making two bets at the beginning of a project. Given the desire for a fixed schedule, the scope-what we will build-will flex so you don't want to call...

  1. Posted on May 9, 2013 12:12:PM by Earl Beede to Practicing Earl
  2. user_story, Agile, humor, requirements

Required or Not

I really enjoy teaching my company's requirement seminars. I enjoy it because, frankly, there really is no industry consensus of what a requirement is. As an instructor, I am free to say any darn thing I like. For an example as to the lack of consensus, client after client will tell me that they have a requirements document full of requirements. I then ask them if they actually deliver to all of those requirements and they say, more often than not, "No, we have to cut...

  1. Posted on December 8, 2011 1:52:PM by Earl Beede to Practicing Earl
  2. Technique, humor, requirements

Add Work to Shorten Your Schedule

I love this one; blows the mind of many a project manager: if you add select items to your work plan, you can shorten the project schedule. Absurd you say? You may be right, let’s take a deeper look. Any good development planning should start out with the high level details of only the work needed to get the release out. Let’s call this the Work I Gotta Do (WIGD) plan. I will represent the WIGD plan below.

  1. Posted on April 30, 2010 8:46:AM by Earl Beede to Practicing Earl
  2. Technique, humor, estimation, risk, schedule, Management

Who is NOT Happy

That should be the real question that any project should ask. Far too often the purpose of project work is to make lot of different customers happy. We get requirements from every Tom, ***, and Harry, from the business, from marketing, from sales, from the technology gurus, from the people who will have to maintain the product (OK, we DON’T get requirements from them), and all these requirements get mashed together into a big fat requirements document. Then we go to build the product...

  1. Posted on February 24, 2010 2:23:PM by Earl Beede to Practicing Earl
  2. Technique, humor, requirements

Usability Collateral Damage

Astute followers of my blog (Hi, Mom!) will have noticed that all of my previous posts are now attributed to “Anonymous”. Same as my forum responses to date. Why? Well, I accidently deleted myself from the site. “Smooth move, ex-lax,” my mom would tell me if she actually did read my blog. A little background. This site has attracted the attention of a (some?) nasty little bot that is adding a lot of fake members. The controls in the then-expensive now-outdated software package...

  1. Posted on December 11, 2009 12:51:PM by Earl Beede to Practicing Earl
  2. Technique, humor, usability, Management

Fail Yet Succeed?

If you build EXACTLY what “they” tell you, you do it in the timeframe they ask for, and at the cost they wanted to pay, is that a successful project? The project is On time On budget Delivers the requested functionality No defects The team is ready for the next project Is it successful? “Yes,” you say. Rightfully so. But what if I tell you that the above project (project A) was followed by another...

  1. Posted on September 16, 2009 12:42:PM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, project management, humor, context, quality, requirements, Management

Relationships Rule

Getting better in software development requires change and change is hard and change is unpleasant. Most of all, it doesn’t seem like we actually change. We talk about change, we start change initiatives, they pay people to teach us new ways, we may even read books, but at the end of the day we seem to be unchanged (except a bit poorer). Do we need to change the way they go about making changes? I started addressing this question in my earlier post called

  1. Posted on July 22, 2009 8:36:AM by Earl Beede to Practicing Earl
  2. Technique, humor, change, Management

Logic Loses

I have recently read a book called “Change or Die” by Alan Deutschman that has some good insights on how people change deeply held behavior. I like to share some thoughts inspired from (and some outright lifted from) the book. We spend a lot of time talking about change. We want to become more agile or we want to improve quality or time-to-market. Each one of us has...

  1. Posted on July 8, 2009 9:21:AM by Earl Beede to Practicing Earl
  2. Technique, humor, change, Management

Spirit of Waterfall

It is not uncommon for me to see on blog posts, newsgroups, or presentations the phrase or comment that something is not, "in the spirit of Agile". In fact a project team could be doing many of the practices of Agile but, if it fails, the agilist will claim that the project was not Agile in “spirit”. And I was wondering, if that is the thing that was really wrong with the waterfall approach. Consider it. It appears that many of the failings of agile or the miss...

  1. Posted on June 24, 2009 9:34:AM by Earl Beede to Practicing Earl
  2. Methods & Processes, Technique, Agile, humor, waterfall, thinking