<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=443149619225659&ev=PageView&noscript=1"> Improving Agile Ceremonies: Treat the Cause, Not the Symptom

We would like to email you valuable insights on software development and DevOps! (We promise not to stalk you or share your info)

 

Improving Agile Ceremonies: Treat the Cause, Not the Symptom

Improving Agile Ceremonies: Treat the Cause, Not the Symptom

Would a doctor prescribe aspirin for a serious illness? Of course not, and when it comes to “fixing” Agile ceremonies, simply chasing after the next great app or remedy is not the answer either. In fact, this will inevitably create additional burdens for your Agile team. In order to have better Agile ceremonies, first you must examine the necessary outcomes for each and uncover the motivation of your team.

The Symptoms

Often, there isn’t full engagement or preparation from each team member which results in a collective feeling that ceremonies, such as retrospectives, refinement sessions and demos are a waste of time. Here’s an example: during a retrospective meeting some team members’ feedback is “things went well” or again, the services that another team are building are not ready on time. This kind of feedback only presents frustrations and doesn’t advance tasks or lead to improvements for the team’s performance.

The first reaction from the Scrum Master might be to find a quick-fix to get those few team members to contribute more, like making the retrospective meetings more appealing by implementing all kinds of fun formats for the meeting. Ultimately, these short-term solutions will only provide short-term improvements.

The Cause

At the heart of most dysfunctions in any Agile ceremony is the team’s buy-in and motivation. In most cases, these are heavily impacted by two major factors: actions from external factors that get in the way of work the team committed to for the ongoing sprint, and actions taken by team members which don’t show the expected results.

Here are a few examples:

  • A product owner that keeps questioning the team’s estimates, and not in a constructive way
  • A project manager that wants an agile team, but only up to the point in which that doesn’t fit with his or her plans
  • A Scrum Master that keeps taking notes of the impediments the team has, but rarely helps resolving any of them
  • A developer that keeps falling behind with the unit tests writing
  • Critical bugs that keep “escaping” into production
  • A product owner that is on the team’s side until it’s on the customer’s side

…and the list can go on.

In order to truly understand the cause, it’s very important to keep in mind the fact that the team needs to feel ownership of the product it builds. If that feeling is undermined by these disrupting factors, it usually turns into an obligation to fulfill a 9 to 5 daily job.

The Treatment

First of all, just like in the doctor's case, be very mindful that this “illness” could become contagious.

The first part of the treatment would be to encourage motivation for the entire team.

Here are some other remedies:

  • Provide feedback to the team members that you see being already affected
  • Address their complaints and encourage them to replace those with alternative solutions
  • Facilitate dialogue with the parties that can remove impediments you cannot
  • Re-focus the team to address first the issues that are within the team’s control
  • Take a stand and ask to reschedule the meeting for when everyone involved will be better prepared
  • Find owners for the actions taken within the team and follow up on their progress

Final Diagnosis

The key here is the "believe in it" factor. When noticing that the team isn’t behind what it builds and doesn’t feel ownership, keep in mind that any given team member has the ability to become a coach and lead the team to success. Focus your efforts on motivating your colleagues, making them commit to the team's success, feel responsible for it and chances are the agile ceremonies that feel displaced now will soon be corrected.

The Challenges of Agile Software Development eBook

Recent posts

Coming Full Circle - Delivering Value through Value-Driven Transformation
How Continuous Integration Benefits Your Software Development Team
Driving Value in Digital Transformation
Exploring NoSQL Databases
What to Do Between Sprints

 

Share this article

 

About the author

Paul started working in the IT industry as a developer in 2003. Becoming a certified scrum master in 2009 he has discovered great value in facilitating successful teams through impediments removal. In 2013 he switched to people management and currently takes great satisfaction in being a team manager and scrum master for self-organizing teams. His passion has been building and coordinating agile teams while being part of them.
Ready to partner with an expert in custom software development? Learn about our fast, cost-effective approach to creating world-class software solutions.
301 N Main St, Winston Tower, Suite 2206
Winston-Salem
NC
27101
USA
Republicii 24
400015 Cluj
Romania

The Small Footprint Blog

Keeping up with the latest in custom software development? Visit Small Footprint's blog for expertise, insights and innovative software strategies.