Meetings

January 22 2021

Something over Nothing

AdamM Agile, Agile Fluency, Facilitation, Meetings, Scrum, Teams 0

It happens to every team. The sprint is coming to an end and the team has nothing to demo. Is it because no progress was actually made? Unlikely. Usually, it’s because the progress isn’t something that can be easily shown. In this situation, most teams want to skip the demo. You can’t blame them really. The team is likely embarrassed and almost certainly frustrated. They worked hard but don’t feel as if they have anything to show for it.

In reality, there was progress made and lessons learned. The team’s concern is that the progress wasn’t what was expected. They may fear the feedback they’ll receive if they present what they have. More commonly they may feel the audience for the demo doesn’t care about progress they can’t easily see.

Many agile frameworks and methodologies are rooted in empiricism, a theory stating knowledge comes from experience. This is part of why short feedback loops are so prevalent in agile circles.

One of the pillars of an empirical process is transparency. Sometimes this is brought in as a value to the framework, sometimes as a benefit of the process, and even occasionally as a side effect. Whatever form it takes, the review is one of the places transparency is delivered.

I believe part of the problem may be a belief that only items that fit the definition of done should be brought to the sprint review. I would agree that only completed items should be given a demo, but the sprint review is more than just a demo of completed functionality. Just as a retrospective is a chance for the team to calibrate their work, the review is a chance for the stakeholders outside of the team to help calibrate the product direction. This meeting involves more than just seeing a demonstration of the increment the Product Owner intends to accept. This is a chance for the development team to see people interact with the product in real-time, a chance for the end-users to guide the future direction of the product by giving immediate feedback, and a chance for the Product Owner to learn how the backlog should change going into the next sprint. This review is part of the rapid feedback loop and should be treated as such.

There is a balance to strike here. Any work done which provides new insight or drastically changes estimates on stories is worth presenting for discussion in some form. Another idea is to show partially completed items, in a presentation format, not a demonstration, and gather direct feedback. Big decisions that could have ramifications on future work should also be brought up here. It might be useful to mention any training taken, but going over what was learned in that training probably isn’t. Small decisions made by dev team members, using an integer versus a big integer for instance, probably don’t belong here either.

Getting the team and organization to reframe their idea of what the review is for will make it a much more powerful event. When the review is about gathering feedback on the present and future state of the product then roadblocks and problems become valuable to share in that format. With the meeting turning into a collaborative feedback session the team should no longer fear showing incomplete items and discussing why. The entire stakeholder team can then provide feedback on what should be done, and the Product Owner can move to the next sprint with a great level of confidence that the team and stakeholders are aligned.

In addition to feedback, having the review work a session to go over both completed items and incomplete items increases the team’s transparency. Instead of just leaving a feature that got dropped from the sprint out a discussion on why it was dropped can happen which lets the Product Owner make an informed decision on whether to bring it back in or not. It’s entirely possible once the stakeholder pool finds out a user story has tripled in size they’re going to want to drop it down the priority list. These are some of the true outcomes you should strive for in your review.

Having shifted your team’s view of the review meeting they are not likely to want to skip it anymore, even if nothing managed to make it to the definition of done.

If your organization could use some help with their agile implementation please contact me here. We’ll have a chat and see if it makes sense for us to work together or not.

September 4 2020

The Song That Never Ends

AdamM Agile, Coaching, Meetings, Teams, Tools 0

Oh, we gather for the daily scrum in the morning now.

Oh, we present for the stakeholder group every week now.

Oh, we plan together for the next week after that now.

We reflect and optimize our work now.

Next sprint, same as the last one.

Sure we are agile but what has changed?

If this sounds familiar you are not alone. Every team gets into a funk at one time or another. A seemingly endless pattern of the same meetings over and over is enough to drive any team to the brink of insanity.

Team members take vacations, and it helps. Unfortunately, you can end up with the team in a pattern that no longer delivers the results expected. No matter what “flavor” of agile your organization has settled on (hopefully a custom one based on your particular need and talents but guided by work done before by others) it needs to be shaken up from time to time.

The best place to pattern-interrupt an agile team is the retrospective. In fact, that is part of the purpose of the retrospective. No team improves by sticking to the exact same pattern week after week. Inspecting that pattern nd presenting ideas for change should be the primary focus during a retrospective. It isn’t a time to examine the work product for improvement, that’s what demos and planning meetings are for. It’s a time to inspect the work process and improve that.

Who should be switching it up though? Whether your team is new to agile or high-performing the answer is the same, their agile coach. In the scrum methodology, this is often the scrum master. Without either of those roles, there should be someone who is championing the change from previous project processes to a more agile approach. That person would also be an option. If they’re too bogged down by their various roles, the person who facilitates the retrospective, or an outside facilitator/coach. I am more than happy to help in this regard, contact me for a conversation.

It can be tough to know how to switch up a retrospective, especially for newer teams. One easy idea is framing the conversations as a journey. The team is on a journey, sailing across a lake to deliver their goods. How was the weather? The waves? Did anything on the boat break? Did the destination change? Simply shifting people to look at the project from a different perspective is often a way to get them noticing new things, and opening them up.

More involved variations are also available, there are people selling kits that turn the retrospective into a mini-game. I am a huge fan of gamification and recommend you look to these for some inspiration.

If a team falls into a rut they can lose some of what usually makes agile processes really work. This is something to avoid, and retrospectives are only one way to avoid it. I’d be happy to get together, discover where you are in your agile journey, and help you get further faster. Ask for a free consultation today!

April 22 2014

The New Daily Stand Up

AdamM Meetings, Scrum 0

I’ve spoken about the Daily Stand Up before. I’ve also talked about how it didn’t work right for us. Some time in the last couple of weeks I came across a blog post that resonated with me on these meetings.

See, I’m all for Scrum. It’s a great tool. The process framework is something that will really help enable change in most organizations. That said, Individuals and Interactions over Processes and Tools. The Agilist in me can not allow Scrum to become a sacred cow.

October 15 2013

Trimming Meetings

AdamM Case Study, Implimentation, Meetings 0

The changes to our estimation process have been a huge hit. The project manager has been nothing but pleased with the new methods. She used to fear estimation meetings and no longer does. The team all has an idea what is happening now when previously they did not. The business feels they have a better handle on what we can get done in any given amount of time. It has been a good fit all around. With this initial success it was time to look at what else in our process could be improved within the limitations we have to endure.

As a by-product of a failed Scrum implementation a few years ago we work in two-week sprints and have daily status meetings. We had a lot of other meetings though. There was a planning meeting that was attended by one developer, one person from SQA, and both business analysts. (In fairness, one of them is the project manager as well.) These meetings were long and painful for everyone involved. They went through the requested work trying to define what exactly it was. They picked what would be done next. They broke it down to tasks and times after which they assigned it to a person. After these meetings would be another meeting we called a kickoff in which the whole team was invited.