Audit

We commonly hear things along the lines of “that’s required for audit purposes” and it’s therefore not to be questioned. If it really is needed for audit then we should certainly do it. Yet, every time I’ve had the opportunity to talk to an auditor, I discover that they don’t want most of the things that we give them.

Fractional people

I worked with two teams that shared a database specialist, for a fairly proprietary system. Because she was on two teams, they had her attend all meetings for both teams. Two standups, two planning meetings, two retrospectives. She ended up doing crazy amounts of overtime because she couldn’t get her regular work done during the day. Her days were filled with meetings, and it was only after everyone else left that she got anything done.

Optimizing for time overlap

If we want people to actively collaborate then they have to be working at the same time. It’s irrelevant whether they’re in the same physical room if they don’t work the same hours. If one person comes in early and another comes in late then there is no benefit in forcing them into the same place.

Learning to say no

A team I was coaching was coming up on an important deadline. Specific functionality had been promised for a certain date that was now eight weeks away, and they wanted to know if they were going to make it.

Intent of standups / scrum meetings

The intent of a team standup/scrum meeting is to resynchonize on the work in progress and decide how we, as a team, are going to complete it. If your standup is horrible, then focus on the intent, not the format you’ve been doing. What would you have to change to make the meeting useful?

Understanding the users

My very first professional programming job was at a large bank that had invested in a full UX lab. One-way glass, cameras, and a full setup where we could watch real branch staff using the software we had been working on.

No blockers

When I was a kid, we liked to play with two way radios. I’d say something and end it with “over”. Then my friend would say something and again “over”. The word “over” had no actual meaning to us, except to indicate that we’d finished speaking.

Excessive sub-tasks

I worked with a team once that had gotten into the habit of creating sub-tasks for every little thing they could think of. This list included such obvious items as “write the code” and “test the code” and a typical story would have about twenty of these sub-tasks attached.

Ambiguity in wording

If I say that a thing costs five dollars but I don’t specify if that’s Canadian Dollars, US Dollars, or Australian Dollars then we might all think we understand the price but we don’t, because I used language that sounded precise and yet was actually ambiguous. What I think I said and what others think I said were substantially different.

Definitions of Ready and Done

I keep seeing heated discussions about Definition of Ready (DoR) and Definition of Done (DoD) in a Scrum team. People argue whether they’re part of Scrum and whether they’re necessary.