Swimming with the Razorfishes

Friday, November 19, 2004

POTD

Via Gawker:

"Freemans tuesday night the 16th of nov. the bush twins along with 2 massive secret service men tried to have dinner they were told by the maitre 'd that they were full and would be for the next 4 years upon hearing the entire restaurant cheered and did a round of shots it was amazing!!!"

Hooray for people with balls! Go eat in a fucking red state.

[Still bitter? Me?]

Software Project Retrospectives

At the conclusion of a software development project, a project retrospective is a best practice for process improvement. The retrospective can help identify best practices and anti-patterns, acknowledge effective and not-so-effective practices, and provide a sense of closure or completion for team members.

Before jumping into a retrospective, take some time to think through the motivation for having one:

What are the goals for having a retrospective?

  • Improve process / artifacts / quality
  • Motivate the team to improve its own processes
  • Focus on a specific objective, such as improving communication within the team or between the team and other functional groups
  • Better serve the client
  • Identify team-wide or department-wide opportunities for improvement

Who will benefit from the retrospective?

  • Project management
  • Company / department management
  • The current development team
  • Future maintainers of the same project
  • Other development teams in the department

Make sure you have a plan for the deliverable(s) you'll create (memo / report / best practice list)?

Answers to these questions should help frame the questions you ask during the retrospective.

Planning the Retrospective

It is a good idea to pre-generate ideas by sending out questions before the actual meeting and to set ground rules. Like any well-planned meeting, a retrospective should have an agenda: specific questions to be answered, topics to be discussed, actions to be taken, and responsibility to be assigned. The retrospective should not be an undirected discussion.

Also following good meeting practices, someone should lead the retrospective (a facilitator), and someone should be responsible for taking notes and publishing a follow-up. Ideally, the facilitator and note-taker should not be team members, and the facilitator should have experience leading project retrospectives.

Part of a retrospective should be commitment from management to actually do something with the information gathered. Otherwise, we're just wanking.

Be certain to have a plan for the questions you’ll want covered in the retrospective. Phrase the questions so they can’t be answered with "good," or "bad" or "yes/no." Asking "how was team communication" won't generate the same kind of feedback as "describe an instance of effective / ineffective communication between team members." Asking for specific examples forces people to actually think about what they are saying. Anonymous feedback or "on a scale of 1-5" feedback are not useful.

Team and project dynamics are complex; they deserve more than a yes/no answer.

Questions you might want to ask (many ask the same question in different ways):

  • What happened on the project that surprised you? What events during the project did you not anticipate?
  • In which cases would stronger / different project management have prevented problems?
  • What do you know now about the project that you wish you had known earlier? How would this have changed the project?
  • How clearly defined was the project life cycle? Was the project life cycle used effectively to driving project deliverables?
  • What have you learned from this project? What lessons are you taking away?
  • What skills or knowledge turned out to be the most important? What skill gaps did the project encounter?
  • What work turned out to be a waste of time?
  • How effectively did the team understand and communicate the needs of the customer?
  • What aspects of the system were well designed?
  • What aspects of the project’s design need to be refactored?
  • What aspects of the project’s code/implementation need to be refactored?
  • What components should be considered for reuse outside this project?
  • How effective were the project’s quality control and assurance activities?
  • What is your level of comfort with regard to the product’s quality? What aspects of the system cause you to lose sleep.
  • What is your overall impression of the end product (does it fail/meet/exceed the users needs and wants)?
  • What one aspect of this project would you change if you could?
  • What one aspect of this project would you keep unchanged?
  • When did communication between team members on the project work well?
  • When did communication between team members on the project break down?
  • When did communication between team members and management work well?
  • When did communication between team members and management break down?
  • If the system is a rewrite of an existing system, what aspects of cutover / migration to the new system went well? Which aspects didn’t?
  • Which part of the system are you most proud of?

It is a good idea to "prime the pump" or pre-generate ideas by sending out selected questions before the actual meeting. A pre-meeting memo is also a good place to set ground rules:

Purpose

  • Spot gaps in process or implementation
  • Look for opportunities for process improvement
  • Help everyone better understand the development process

Not The Purpose

  • Evaluating individual’s performance
  • Lengthy discussion of solutions

Principles

  • There is no ownership: anyone can suggest issues / improvements with any aspect of the project
  • Mutual respect; choose your words carefully; don’t ever get personal
  • Topics covered in the retrospective are for process improvement; the retrospective does not feed into individual employees’ performance ratings.
  • Issues must be specific: "I don’t like it" isn’t good enough.
  • Identify problems, but don’t try to solve them
  • Think through the issues beforehand

During the Retrospective

The facilitator’s role is important. Facilitators must be able to direct the conversation and should have skills to elicit feedback and conversation from the whole team. Project management should prepare the facilitator with specific examples and project situations to help get conversation started. The facilitator should also be able to sense the team dynamic; some teams are very collaborative, outspoken, and confrontational while others will fear "rocking the boat." Different teams require different tactics to start conversation.

Disagreement between team members during the retrospective is OK; it is the facilitator’s job to enforce the ground rules regarding mutual respect.

The note-taker should record enough of the conversation to create a detailed post-retrospective memo. Consider tape recording the meeting. Handing out forms to the participants may encourage them to take notes during the retrospective. The contents of team members’ hand-written notes can often be surprisingly different than the spoken conversation. Be sure to collect the forms after the meeting, though.

After the Retrospective

Hopefully, the retrospective will generate good conversation, some examples of a job well done, and some opportunities for improvement. If well run, a retrospective can also energize team members for their next project.

As soon as possible following the retrospective, the note-taker and facilitator should put together a follow-up memo. The memo should detail the retrospective findings, and should be send to the project team as well as team management.

At that point, management must be responsible for acting on the retrospective findings. At best, if management doesn’t act on the findings, the effort will have been wasted. At worst, the team members will grow cynical and will be less motivated to improve process. Management action need not be sweeping department reorganization; acknowledgement of the findings and a commitment to review process can be sufficient.

Good Morning Thinkers: Finding time to think

Thursday, November 18, 2004

I don't know what to make of this.

This makes me happy.

[via jwz]

POTD

Only color photos for the rest of the week. Promise.

I've embarked on a journey of monitor calibration and color correction. My aim is to create images that look good on both MacOS and Windows-driven monitors, as well as CRTs and LCDs. I find several things quite vexing: 1) the gamma differences between LCD and CRT monitors, 2) the sharpness differences between LCD and CRT monitors.

This heavily compressed image is my first unsuccessful attempt. I'll keep you posted.

Wednesday, November 17, 2004

As per Morgan's request, here is a video of Leonard Nimoy singing his Ballad of Bilbo Baggins. I have this song on CD; I was shocked to find that a video exists.

Frankly, this video freaks me out. Each time I watch it, I feel myself slipping closer to insanity.

Michael Powell is not competent.

POTD

I've been posting so much monochrome stuff lately.

When did Amazon introduce Amazon Films?

Two tidbits about the Barnes & Noble on 21st Street and 6th Ave:

  • There was a huge line to see Andrea Bocelli. Enormous. Around the block.

  • There are several (two or three) hard cover copies of This is the American Earth in the used book racks. I regard this as one of the most wonderful photo books ever written.

Like a phoenix rising out of Arizona, Netscape is being reborn. Not content with their shitty, corporate version of Mozilla, Netscape will now create a shitty version of Firefox.

Tuesday, November 16, 2004

Kevlar ® is a very crystalline polymer. It took a
long time to figure out how to make anything useful out of Kevlar ®
because it wouldn't dissolve in anything. So processing it as a solution
was out. It wouldn't melt below a right toasty 500 oC, so
melting it down was out, too. Then a scientist named Stephanie Kwolek came up with a brilliant plan.

Aramids are used in the form of fibers. They
form into even better fibers than non-aromatic polyamides, like
nylon 6,6.

Why? Why?

Ok, since it seems everyone just has to know, I'll tell you. It
has to do with a little quirky thing that amides do. They have the
ability to adopt two different shapes, or conformations. You can
see this in the picture of a low molecular weight amide. The two
pictures are the same compound, in two different conformations. The one
on the left is called the trans conformation, and the one on the
right is the cis- conformation
.

Five dollars to the first person who can confirm whether or not these people are using the word "vagina" to advertise bread sticks.

Elite Designers Against Ikea. Clever.

I was having so much fun yesterday at work that I forgot to mention this terribly important event: section 404 of the Sarbanes-Oxley legislation went into effect.

Remember, Sarbanes-Oxley covers things with a "material effect" on financial statements. It isn't a consulting full-employment act.

POTD

This was the window I went to photograph when I happened to see this other one. I like the other one better, but I feel somehow duty-bound to post this one, too.

Monday, November 15, 2004

If anyone ever hears me use the term "my work," you have permission to kick me hard in the knee.

I just listed myself (I'm such a whore) on photoblogs.org, and I'm on three people's favorites list (!).

Welcome to New York.

Enjoy the marathon.

Just watch where you stand.

Via Gothamist, the Williamsburg Bank building in Fort Greene, Brooklyn has been purchased, and is being converted to condominiums. This is that tall tower with the multi-colored clock that you can see from Caroll Gardens to Williamsburg. Those condos will have quite a view.

John Updike has a nice article on the new MOMA in The New Yorker.

Also, Colin Powell resigned. The Press Secretary says more resignations are to come. God help us all.

Sunday, November 14, 2004

"In the unlikely event that a vaporised penis can perform ejaculation, then the relativistic semen will create enormous air resistance, burst into flames almost instantaneously, and generate enormous impact forces."