Practicing Earl

Serious and not-so-serious thoughts about the practice of talking about software development and, perhaps, software development itself.

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

Innovate Or Execute?

"We want our employees to be more innovative." Where have you heard that one before? Why are more and more employers wanting their staff to become innovative? Have our brains been stuck in the day-to-day muck for too long? Do we just need to innovate ourselves into greatness? I don't think so and I don't think employers really want us all to innovate. You see, to innovate means to disrupt the current status quo. It means to take a chance on something we haven't done before,...

  1. Posted on February 21, 2011 2:18:PM by Earl Beede to Practicing Earl
  2. execution, innovate, Management

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

What Marketing Requirements Look Like

I recently went with trepidation into a class with Pragmatic Marketing called “Requirements that Work”, part of their Practical Product Management series. Marketing professionals have been my foil for bad requirements for years and here I was, ready to hear from the experts themselves how marketing, and not engineering, should be making all the decisions about the...

  1. Posted on August 24, 2009 11:12:AM by Earl Beede to Practicing Earl
  2. Technique, problem space, solution space, requirements, marketing

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