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.

When everything is a priority

I was asked what to do when the customer won’t prioritize the stories and insists that everything has to be done now. That brought back memories of the first time that had happened to me. This was a very long time ago and I can’t remember who had given me the idea to approach it this way.

Flow Efficiency

Flow efficiency (sometimes called Cycle Efficiency) is a metric that gives us a sense of how much time work is waiting. A flow efficiency of 100% would indicate that we are adding value to the work item for the entire time it’s in progress. 50% would imply that half the time we’re working on it and half the time the work is just waiting.

Self-sufficient teams

A number of years ago, a client of mine had a new feature request come to one part of the company. It was a significant change that would touch quite a few teams to get done and when they asked those teams how long it would take, the answer was somewhere between 10 and 12 weeks.