EppsNet

The goal on a project is not to have the correct plan in advance but to make the right decisions every day as things that were unknown become known.

— Jim McCarthy

For 3-1/2 months, we’ve been using a scrum board — not the one in the photo, but similar — to track tasks on a development project. Tasks start out on the left side of the board in a Not Started column, then move through In Progress, Code Complete and User Testing on the way to Done.

Today someone said, “We need a list of everything that still needs to be done — like the scrum board, but could you put it in a spreadsheet?”

Ummm, I could, but it wouldn’t contain any additional information than what’s on the board.

That was an eye-opener to me. I like the scrum board format because it keeps things visible. It’s easy to see what all the tasks are and it’s easy to see the status of each task.

It never occurred to me that if you record information on Post-Its and stick them on a wall, rather than recording the same information in an “official” format like Excel or Project, there will be people who assume that you’re just screwing around.

NB: It’s not their fault for not getting it; it’s a communication failure by me because I didn’t anticipate the situation.

Thus spoke The Programmer.

• RT @mashable Bill Gates’ Plan for Fixing the World http://bit.ly/4ABw03 #
• RT @SarahKSilverman: Sometimes when I'm by myself I say out loud, "BarTHelona" & giggle at that lispy accent they have. ah shit, I have fun. #
• RT @capricecrane: They say a lie gets around the world before the truth gets its pants on. Why the truth is pantsless, no one ever says. #
• User Story Mapping: modeling user stories for effective understanding of your system and planning incremental releases: http://bit.ly/1LQ17h #
• If my office gets one degree colder I'm going home… #

Jerry Weinberg has been for almost 50 years the leader in considering software engineering not just as a technical practice but as a human activity. I’ve read seven of his books and with the exception of people I’ve actually worked with, I’ve learned more about IT from Jerry than from any other person.

He’s recently been diagnosed with what doctors say is a fatal illness. He has a CaringBridge site where he can read messages.

Pretend that your project is an obstacle course and you want to get the biggest obstacles over with in the beginning. Here are some strategies for being on time or early:

• You want to know what all the obstacles are as soon as possible.
• You want to deal with the biggest, hardest obstacles first.
• You want to complete every obstacle as soon as possible, rather than “on schedule.”
• If you can go around an obstacle or skip it, do that.
• Your team has to stay on the same course. You don’t want part of your team on a different course.
• Getting your team aligned about the blocks and how to deal with them using the entire team IQ is much more efficient than “working hard” or pounding away at the problem. Look for the big ideas.
• Make sure team members aren’t going over obstacles that don’t exist.
• What’s the biggest obstacle? Get that done. What’s the next biggest? Get that done. Repeat.

— Michele McCarthy

To understand control’s real role [in software development], you need to distinguish between two drastically different kinds of projects:

• Project A will eventually cost about a million dollars and produce value of around $1.1 million.

• Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?

— Tom DeMarco, “Software Engineering: An Idea Whose Time Has Come and Gone?”, IEEE Software, July/August 2009

I’m not wholeheartedly endorsing the Ultra Lean Planning approach but it does lead you to question how much of the overhead of traditional software development is really necessary. It may be important to know that the author is one of the top guys in the industry and not a random flake.

• RT @KathySierra: We discuss UI 4 books, but isn't it UX that matters? Non-fiction could look 2 game design, theater, learning, persuasion #
• RT @agile_coach: The sustainable delivery of business (customer) value is more important than the platform used. #scrum #agile #

The graphic on the right came up for discussion at the office today.

The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons.

1. Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad.

2. If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find out that the system is a failure until we’ve already invested the entire cost of building it, thus the rich history of big-ticket IT failures, where huge sums of money were spent and nothing usable was ever delivered.

IMO, you can use a design-code-test V model, but you have to use it iteratively every week or two weeks or at most every month on a project to avoid these problems and make sure users are getting what they want.

Thus spoke The Programmer.

I’d just finished reading another tiresome “why oh why aren’t there more women in IT?” article when I found a former colleague on LinkedIn . . . he lists his job title as “Analyst, Software Quality Assurnace.”

Would you hire him as a QA guy? I wouldn’t, and that’s even before I saw how he misspelled “Assurance.”

The IT “profession” is chock full of idiots like this. Why anyone thinks women are missing out on something if they don’t work in IT is a total mystery.

If I had a daughter, I would tell her to be a meeting planner or a flight attendant . . .

Thus spoke The Programmer.

It’s done but we’re still working on a few things.

Then it’s not done, is it?

It mostly works, but it still needs a lot of testing.

How do you know it mostly works if it still needs a lot of testing? Isn’t that what testing is for — to figure out if it works?

I’m not making these up, by the way . . .

More of my customers have been asking me how to use agile processes, particularly Scrum, to help them manage offshore development. Since offshore development undercuts many of the practices that promote agile productivity, I ask them why they don’t just increase the productivity of their teams by thoroughly introducing agility? It seems that offshore development, with its potential for lower unit costs (dollars per programmer day), offers management hope that their losses can be reduced. Since the project is probably going to fail anyway, let’s minimize our losses by lowering our investment by using lower priced resources. A more optimistic, agile, way of looking at this problem is to fix the problem at home and increase the probability of success.

— Ken Schwaber

The last place I worked, I kept my James D. Watson bobblehead on a cubicle divider, next to a Spongebob bobblehead that belonged to a colleague.

Everyone who saw these two guys recognized Spongebob, but not one person ever recognized James D. Watson.

I mean, they knew it was someone named James D. Watson because his name is right there on the base, but despite the fact that he’s holding a double helix structure, nobody recognized him as James D. Watson, Nobel Laureate and co-discoverer of the structure of the DNA molecule.

(Ironically, one of the main reasons I got into software development was the opportunity to work with smart, educated people.)

I brought Watson with me to the place I work now, but unfortunately I accidentally knocked him off a credenza one morning and his head broke off. I tried a couple of times to glue it back on but it didn’t take. So I had to throw him away.

The real James D. Watson is actually still alive at age 80.

Someone left a box of Nerds on a cubicle wall in the IT department. (The door in the back left is my office!)

What is that supposed to mean? We are not (just) nerds!

From Alan Shalloway:

Essence of Lean for People Doing Scrum

• Lots of concurrent tasks cause waste
• Focusing on removing delays will remove waste
• Adding value and getting feedback quickly is important
• If you make a mistake and don’t attend to why you made the mistake, it will likely repeat itself
• Minimizing work in process (WIP) is a way of improving efficiency and minimizing risk

There’s a guy at work who tells me he’s the best IT customer in the organization.

When I ask him why he’s the best IT customer, he says it’s because he understands that we in IT are very busy so he doesn’t bug us too much.

That’s funny because the person I think is our best customer is just the opposite — she knows what she wants, and she doesn’t mind being difficult if it leads to better results.

Yes we’re busy, but we’re trying to do this stuff as well as we can do it and it helps to get a sense from the customer that the work is important and that doing it well is worthwhile.

I had a great meeting today — eight women plus myself.

That’s not why it was great though.

These ladies want to launch an online Education Room with webinars, a speaker directory, announcements of upcoming events . . . they have none of the content ready . . . and they want to launch it on Jan. 1, 2009.

So instead of talking about how they’re planning to get the content to me so I can build the thing, they’re saying things like, “When you hover over a webinar link, it will display a description of the content — like on Netflix . . .”

Netflix. Right. So I say, “You’re not gonna get that.”

Oh, they loved it! They laughed and laughed. They knew it was ridiculous, they just wanted someone to tell them it was ridiculous.

Women love a masterful man who’s good at his work.

Thus spoke The Programmer.

Here are 38 tips from the designer of the C++ programming language.

These in particular jumped out at me:

[5] Don’t try technological fixes for sociological problems
[8] Design processes to encourage feedback
[9] Don’t confuse activity for progress
[10] Don’t generalize beyond what is needed, what you have direct experience with, and what can be tested
[19] Use existing systems as models, as inspiration, and as starting points
[22] Design for change, focusing on flexibility, extensibility, portability, and reuse
[27] Keep it small. Don’t add features “just in case”
[29] Repeatedly review and refine both the design and the implementation
[31] Experiment, analyse, and test as early as possible and as often as possible

There is no accountability without volition, you’ve noticed, right? You can’t go “You got to ship that by November 1st and I am holding you accountable.” It doesn’t work that way.

You can’t hold someone else accountable, you’ve got to hold yourself accountable. It’s just like you can’t motivate someone else; you got to motivate yourself. And the more that you motivate people and hold them accountable, the more infantile they become.

— Jim McCarthy

I use charts like this one to track open project tickets, color-coded by priority.

At a meeting last week, I pointed out that the number of open tickets on this particular project had peaked out at 70 and was now dropping faster than the value of my house, at which one of the attendees laughed more enthusiastically than I thought was necessary.

“Why is that funny?” I asked. I mean, it was supposed to be a little funny, but not laugh-out-loud funny.

“I’ve been there,” she said.