Back to List

Misusing Scrum Ceremonies (Agile Transformation Pain Point #15)

Rachael Wilterdink Rachael Wilterdink  |  
Dec 20, 2018
 
Avoid having runaway meetings, meetings that go past their time boxes, and meetings that are not for their original purpose. Keep it focused.

Create and follow an agenda for the more formal Scrum events –depending on your company and culture. I’ve worked at loose organizations and formal organizations. At both, the Scrum events worked because they followed the lead of the company and their culture.
 

Keep out saboteurs

Make sure you don't invite the wrong people. If there are problem people that shouldn't be involved, don’t invite them. Maybe there's politics going on, or maybe somebody's nosy and wants to see what's happening. You do want your stakeholders there, but you want to make sure they're the right people. Otherwise, you can get some saboteurs who try to create blockers for your team and set up your team for failure. You don't want those people in there if you can avoid it.
 

Stick to your time boxes

Don't use meetings for purposes other than the original intention. Be prepared and make sure you're ready when you go into your review meeting. Make sure you know who's going to be showing what and what they're going to be showing.
 
time boxes

I always have an extra meeting that I hold on my teams, which is the day before or right before the actual Sprint review meeting. I'll gather the team to get the logistics out of the way. We go through what we got done, who's going to show what and in what order. Showing the work with a dispersed remote team is more challenging, especially on something like a mobile application where you can only sort of simulate it. Ideally, you want to be there in person if it's possible and show them the real deal.
 

Preparedness is key

Be prepared, especially for planning. You don't want to go into a Sprint review and say, "Oh, sorry, I only have a couple of stories that are ready.“ You could start sprinting and have the person continue to work on fleshing out and getting approval of the stories that are still to come. Ideally, however, you'd have done that and are ready for the team to pull from the backlog when they're doing their planning.
 
preparedness is key
 

No pointing fingers

Also, don't use retrospectives as a blame game. That should be a safe place where everyone can be honest with each other and not take it personally. It's about getting better together. Things don't always go smoothly, so take those as learning opportunities.
 

Follow through on action items

Finally, follow through by acting on action items from your retrospective. Typically, you want to pick at least one thing from your retrospective that you can improve upon that was part of the empirical process of inspecting and adapting. Either add it to a board that says “action items”, or add it to your actual Sprint backlog with tasks and follow through on it.

Going back to the waterfall world, many teams will hold a lessons-learned meeting at the end of a project, but then the team disbands and no one takes any action on the items learned. They're pretty much doomed to repeat the same mistakes they made before. I think agile makes this more visible and more actionable because you're doing this throughout the process, not just at the end.
 

Get the free eBook

This is the fifteenth of 20 blogs on 20 Agile Transformation Pain Points (and how to avoid or manage them). To read them all right now, download our free eBook.
 
agile transformation pain points ebook
Agile

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Roles and Responsibility Activity (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Jul 11, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this blog series is right for you. This is the third blog in the Trifecta of Greatness series. For more background on the strategies and tactics our Solutions Consulting Director learned...
Blog Article
10 Communication Tips for Business Analysis and Project Success
Brian LaehnBrian Laehn  |  
Jul 09, 2019
I am often asked what is the most essential skill that a Business Analyst (BA) should possess. 100% of the time my answer is that a BA must demonstrate the ability to communicate effectively with their project team and all project stakeholders.   Communication, when performing...
Blog Article
How to Use Report Tables to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Jun 27, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. Over the next several months, we will be releasing 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements on our blog...
Blog Article
Seeds of Vulnerability (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Jun 20, 2019
My last blog (Introduction to Team Delta) talked about a project team I was on called Delta that was very successful. In this blog, and the ones following, I'm going to talk about the characteristics and the foundation that we found was key to our success, as well as what was different from...
Blog Article
How to Use a Glossary to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Jun 13, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. Over the next several months, we will be releasing 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements on our blog...