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.

Monkey Grassing

A common anti-pattern that I’ve seen is managers taking a highly effective team and scattering them across a larger number of teams in the hopes that they’ll take everything they know and make those new teams great. Then instead of having one great team, they’ll have many great teams.

Tracking metrics

Most companies I work with have a desire to track metrics for their development teams, and I support this. It’s hard to improve something we can’t see so metrics are a good first step as we seek to improve.