Happy Friday,

I was on a cruise last week, and it was most excellent. People ask, "Where did you cruise do," and I want to say, "Who cares!" It was just great to get away and relax. Unfortunately, that relaxation knocked me out of work mode, so I forgot about my weekly newsletter to all of you.

I was observing a retrospective not too long ago, and I saw three things come up as topics for every team. I thought I'd write about them and what I've found to work for them over the years.

1. Better Requirements
2. Better Documentation
3. Don't Have Time for Retrospective Items

Let me start with the better requirements. The premise for this ask is that teams will say that they'd be more efficient if they had better requirements upfront. Some go further to blame agile practices for preventing them from meeting those requirements. The truth, as I've found it, is that the developers simply prefer to work in the code, and so things that distract from that are considered problems. Ironically they don't want their code work to become a chore so precise or complete requirements rob them of their freedom. Not to mention, it is almost impossible to get requirements to the point of clarity that satisfies everyone while being accurate.

So what do I prefer to do? I prefer to do fewer requirements, bordering on none. When writing stories or whatnot, they act as basic placeholders that the team, the product owner, and I discuss and record our discussion notes in all those lovely fields every agile tool provides. This emptiness winds up being highly engaging for the team as they get to have a say in what options exist and how to execute and assess the feasibility of things. None of those are possible with requirements.

Now let's move on to documentation. This makes heads pop because, again, people corrupt the value of working code over comprehensive documentation, which means they don't document anything. I assume they mean this because their code doesn't work, but I doubt it. The request is that they wish there were better documentation both for the technical side of what they do and the business side of why they do it. A quick check of, "Did you read what we already have," will almost always get an answer of, "No." So what this is more about is how hard it is to make sense of what is currently going on. I've never found a comprehensive way to satisfy this need, but my best answer for developers is automated testing. Tests that run regularly with good names provide small sentences about the behavior of the system in various degrees of detail. This means that running tests will write out what people expect of the system on the screen while proving it does behave that way. If a developer needs to dig in more, they can pop into a specific test, and begin to navigate from there. With good tests, the only question that ever really remains is, "Why did we do it this way," and that is a mystery I think is fine to keep around.

On to the retrospective issue. I see way too many retrospectives where someone asks if anyone did anything with the previous retrospective's items and there is silence from the room. Folks try things like putting the improvement items in the sprint or seek commitment, but the story unfolds the same. This breaks my heart. Over time this lack of movement leads people to feel that improvement is futile. So here's what I've learned about why folks don't act on the retrospective items—they're too vague. The items people come up with are things like, "We should test more" or "Better documentation." These are concepts and are so open-ended that they'd be as paralyzing as seeing a user story that says, "Build the app." When I teach people to do retrospectives, I caution that when they get to their actions, they need the actions to answer three questions:

1. What will we do?
2. How will we know it works?
3. When can we check?

If folks can answer those three questions, then they have an item they can actually do, and they will attempt them far more often.

Sincerely,

Ryan