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


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
Focusing On Projects Rather Than Products (Agile Transformation Pain Point #17)
Rachael WilterdinkRachael Wilterdink  |  
Jan 10, 2019
This is a difficult transition for waterfall companies to wrap their heads around. It's a big mindset shift that needs to happen to be truly successful. I'm not saying that you can't have an agile Scrum team that works on projects with a distinct beginning and end. That might be a...
Blog Article
Skipping Over Quality (Agile Transformation Pain Point #16)
Rachael WilterdinkRachael Wilterdink  |  
Jan 03, 2019
You should not skip over quality because it’s inherently meant to be baked into agile. There are many ways you can do that. You could consider doing acceptance test-driven development, behavior-driven development, or you can write automated tests wherever possible. Again, I really like the...
Blog Article
“O Testing Tree, O Testing Tree” - A Comprehensive Look at QA Testing for the Holidays
Tim MorrowTim Morrow  |  
Dec 21, 2018
“O Testing Tree…O Testing Tree…how lovely are your branches!” Yes, for a Quality Analyst (QA) tester, the tree pictured below is a thing of beauty! It represents a comprehensive plan for testing an application and a roadmap for delivering high-quality products free...
Blog Article
Pre-assigning Work to Team Members (Agile Transformation Pain Point #14)
Rachael WilterdinkRachael Wilterdink  |  
Dec 13, 2018
This pain point is something you definitely don’t want to do. Agile and Scrum teams are meant to be self-organizing. They should volunteer to pick up assignments, not be assigned. Development team members are volunteering to do stories, and they might want to learn something new &ndash...
Blog Article
Taking on Too Much Work in a Sprint (Agile Transformation Pain Point #13)
Rachael WilterdinkRachael Wilterdink  |  
Dec 06, 2018
Some teams are super ambitious, and they just think they can climb a whole mountain in a single Sprint, but the whole goal with agile is to maintain a sustainable pace. Take on only what you really think you can get done within your Sprint. Don't overestimate your velocity, and don't...