Hacker News Reader

This.

That is why the retrospective meeting is at the heart of agile. A truly "agile light" setup would be:

Every other week, do a retrospective.

That's it!

On the retro, ask yourself 3 questions (or work with these 3 themes):

1. Is the way we are working helping us, and the rest of the organization, make the right decisions and reach our goals in an efficient way? If not, what needs to change?

2. Is our understanding of the customer (or whatever system we are trying to improve) correct or are we basing our decisions on the wrong assumptions? If so, what do we need to learn?

3. Do we have a clear picture of where we are going and what we want to achieve and how that is aligned with the goals of the organization? If not, how do we course correct or make our progress towards our goals clearer?

There you have it: the retrospective and the 3 dimensions of agile.

I would say that retrospectives are the biggest waste in agile in my experience.

For one thing, retrospectives often come at a time when everyone has been busting ass for a long time and they just want to go home. If you put it off till next week then it seems like another distraction.

Like the planning meetings, the timebox for a retrospective is often wrong. In some cases things went smoothly and there is a little to say. That is where you should be. In some places you budgeted 45 minutes but there really is a day worth of material.

On top of that in many (most?) firms there is no sense of psychological safety. Often the real message is that the process is 99% bull but you can't say that in a meeting which is claimed to be about continuous improvement but is really about how to rearrange the deck chairs on the titanic.

In his book "Good to Great", Jim Collins points out the use of the word "alignment" is a bad smell. In a healthy organization there is alignment, naturally, built into it. If you feel like you have to paint alignment onto it after the fact you are just causing more misalignment.

That was a very good list of things that would typically come up in a healthy retrospective. But, yes, there has to be psychological safety first.

In some cases things went smoothly and there is a little to say.

Has been my experience (on good teams.) After a while, you tend to gel pretty well and don't need to spend that much time introspecting. The issues raised are either generally intractable organizational problems (that'll never get fixed), or fairly minor, and on several teams I noticed that retrospectives tended to feel pretty similar after a while (To the credit of the team, at that point we were like "we probably don't need retrospectives every sprint.")

> when everyone has been busting ass for a long time and they just want to go home

This sounds like a smell. You should not be busting ass and have everyone feel like they just want to go home at the end of the sprint. You should be working productively every day without burning out. Perhaps the team is forced to make too many commitments? Kind of sounds like it from your other comments.

Judging by my retros, I think other dev teams trying this will rapidly find that the answer to all 3 questions can be “no, but there’s nothing we can do about it!” Past a certain company size/amount of bureaucracy, simple agile seems nigh-on impossible.

Good points. I would rather have these answered in planning, rather than a retrospective. If these questions need to be asked after every week of work, that's a sign that the retrospectives are not helping much.

It's ironic to me that even this "Lite" version of Agile (Scrum really) clearly puts process over people and conversations. I think it's great to have a starting point of a known process and tools, but we should have much more focus on adjusting to the concrete problem, the people and larger organization.

It's ridiculous to me that this proposal is set to reduce burnout, yet we still seem to commit on what gets done and by whom by the end of a time period that has the asinine title "sprint". What we are doing inherently deals with new and unknown, we usually aren't building, cookie cutter, prefab homes. What we are doing is certainly not a sprint, it's not even a marathon. Nomenclature like that creates a culture of heroes and cowboy codes who will burn themselves out. Hard rules like "can't change or add to the backlog" don't serve anybody. Nobody wins of the ship keeps moving in the wrong direction or stops. Let's just have a conversation! People should work together as a team and communication is paramount to a successful team. Let's not process our way around that and solve that problem!

>Often agile "teams" have a "normalization of deviance" situation where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but actually do something entirely different to get the job done.

You’ve succinctly defined the problem in a very profound way. A verbal punch to the gut for sure.

>The timeboxing of planning is also a very bad idea. I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do. After that the work was mostly downhill, at least the way I saw it, but one of the other team members would consistently burn the midnight oil at the end.

If your backlog is properly groomed and you have sufficient time for planning and the team has the last word on how much it tries to take in, then it works beautifully.

If my team was to have that problem, it would come up during the retro, we would add a few more hours for the planning event, hold more or longer grooming sessions, refuse to plan work which we can not yet estimate because the requirements are not clear, etc.

And btw, your "implementation of Scrum" wasn't working properly; probably because you weren't living up to the Agile principles.

> I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do.

Wow! Sounds like decision-making processes needed tweaking even aside from Agile practice.

We might not have been so exhausted if the process itself was not in the way of makign realistic plans.