It’s getting boring here…. how to keep scrum ceremonies interesting?


As I walked into the backlog refinement session for this team that I had been coaching for about a month, I felt a low in energy. Team members were busy doing their own “stuff”. While some were busy texting, others were on their laptops and since a backlog refinement meeting is typically linked to the Product Owner role, she was the one doing all the talking. It reminded me of the economics lecture in college where the professor was the only one talking while the class was busy thinking about the college annual festival.

Humans cannot survive any kind of repetitive event for too long. Scrum ceremonies are no exceptions. Sustaining interest in scrum ceremonies becomes difficult and they say “it is getting boring”. Their minds are always in search for the next exciting thing happening around them and the ceremonies are all about going through the motions without understanding the intent and outcome of the same.

Every scrum ceremony has a desired intent and outcome which is to be built on the core principle if team work driven by communication, conversations and collaboration. However, most Scrum teams lack the kind of chemistry to make these possible.

So what can one do to keep things interesting. Well, here are some pointers:

1. Location – As much as my kids love to eat at home watching their favorite TV show, every once in a while we go out for a meal. Change in surroundings  brings in interesting changes in people’s view point like sharing their dishes to get a sense of other’s taste, time for some family conversations and more.

So try to experiment with the locations for your ceremonies and observe the different it makes. An informal retrospective at a local restaurant or over a bowling session goes a long way in bringing in a positive change and  creative thinking.

2. Activities and games – Playing games with my kids is the best way to get some leanings across to them which otherwise is a big ask. As kids make their moves, I ask a question to help them select the best option. Other times they correct me if I  made a wrong choice.

Leverage games and activities to help create a collaborative environment between team members., are some great resources for such creative and fun filled games. In fact there is a whole book written about how to conduct retrospectives. Check it out here.

3. Rotate – As much as I love to get a nicely cooked meal from my wife, I like to try my hands at cooking and trying new recipes from the internet or of my own. While the intent in doing so is to stick to have a plate of food that is healthy and also tastes good, a different approach to cooking can bring in unique flavor and taste.

So when it comes to facilitating a backlog refinement session or a sprint retrospective, allow other members of the team to get into the shoes of the Product Owner or the Scrum Master. Not only will this introduce them to the challenges associated with the role and ceremonies, it will also help to bring in some fresh ideas to the table on running the ceremonies and solving problems.

4. Reward – Rewarding the right behaviors and penalizing the wrong ones is something that everyone can relate to. This something that happens with is right from our childhood to when we grow up as adults.  Right or wrong, this has worked in majority cases.

When dealing with mature teams, this might not even apply, however; when starting with new teams and going with the “Shu-ha-ri” approach, following the rules becomes critical. Having followed the rules for a period of time, it becomes second nature. According to a research, for any action to become a habit, it takes an average of 30 days of focused effort. So while you would want to reward right behaviors, penalizing wrong ones will help sustain a balance. So discuss with your team to decide what rewards or penalties will work in your unique environment.

5. Don’t wait – I was never good at maths. I would avoid solving math problems as much as possible till the time my father would catch me just before the exams and make me solve a few. No marks for guessing that I would struggle. This would repeat each year and my father would tell me to share my challenges with him all through the year so he could work with me right then and address my issues.

Solving problems and raising issues as they occur is extremely important. If the team has to wait for the next ceremony to happen before they can bring up a problem, chances are they might forget it or not have a productive conversation given that the issue happened in the past.

Post Script – I wonder why scrum ceremonies would become monotonous and boring when the team has complete control of the “how”. Is it because the ceremonies do not achieve the desired objectives or because the team is still under some kind of control where they cannot exercise their decision making powers? It is quite obvious that these complaints sound exaggerated but these are common too.

So what is your view on this subject? What are some techniques you have tried with your teams? Leave a comment…

Distributed teams and dependencies – My talk at Austin City Limits Conference

I recently had this opportunity to talk at the Agile City Limits conference at the Dell headquarters in Round Round, Texas. There were a lot of awesome things about the conference. Awesome crowd, awesome energy and from the audience an awesome urge to ask some really great questions. Not to mention that the topic itself “Distributed Teams and Dependencies” was one that is the biggest concern with any large organization trying to adopt agile.

The primary intention behind this presentation was to decouple challenges with a distributed setup and agile. The problems teams and individuals face with a distributed team are resolvable through the use of right tools and techniques. With large and distributed teams, there is so much focus put on process that most teams gradually move away from individuals and iterations and drag themselves back to be driven by using more processes and tools.

The key to overcoming challenges with distributed teams is through using the right balance of agile teams with focus on product/project vision, cross team collaboration, building the right level of trust and understanding cultural sensitivity. Additionally, communication and collaboration tools along with required development tools become great facilitators for collaboration between teams. Teams using agile methods have had great success with tools like story mapping, backlog grooming, scrum of scrums.

I also took the opportunity to talk about what makes a good distributed setup and how organizations should focus on running Scrum successfully before scaling. At the end of the day, it is all about managing the distance.

The audience was particularly interested in understanding the opportunities around team dependencies. My focus in this part was to share my experience in how I and the teams I have coached addressed the challenges with team interlocks. After talking about why dependencies exist and the kind of problems dependencies bring, I walked through some tried and tested approaches which included:

  • Approach to plan to keep dependencies to minimum as you form new teams
  • Creating an open source model
  • Planning for dependencies ahead of time
  • Creating communities of practice for better collaboration

All in all, it was a great discussion and I hope the audience enjoyed attending my talk as much as I enjoyed presenting it.

Here’s my presentation.

Agile and software rewrite

Talk about software rewrite and one comes across varied opinions. With the advent of cutting edge engineering practices that facilitate opportunities to build things right the first time, many look at the need to rewrite software as a sin. When coming across developers and architects who want to rewrite software systems, you hear them saying things like the software is way too complex or the system was probably written by a dumb developer etc..

As you investigate the need for a rewrite, some of the more common reasons include:

  • System is not performant
  • System is too complex to understand
  • Technical debt
  • Unfamiliarity with domain and legacy code
  • Use of old technologies
  • Business feels the system is out dated
  • More..

So what is the right strategy for a rewrite?

Most business want to take a “like per like” approach, which means that the software be re-written to implement improvements without introducing any change from a customer experience view point since selling a change to a customer can be challenging. This mentality results in under estimating the complexity of the system and ignoring the opportunities for improvement.

A real world example that one can relate to is a new version of an existing car model that gets offered every couple of years. Would the car sell more if the company was to build a new version in the same exact way as the existing one? Well, not really. Customers look for improvements across the board, from improvement engine performance, latest features, more mileage and a refreshing look. So why should software be treated any different?

Is a complete rewrite acceptable?

The second is the most dangerous system that a man ever designs” Fred Brooks, 1975 & 1995

Complete rewrites will make sense if one can stop the world from changing but unfortunately that is not an option. So the first approach should be to refactor your way out of the problems. Most issues can be resolved by addressing the issues in a prioritized fashion. Systems when rewritten are mostly NOT written very differently from when they were written originally. There are still requirement gaps, architecture does not resolve all of the problems and teams still build a lot of technical debt.

Refactoring your way out turns out to be the most efficient both in terms of effort, cost and risk. Engineering practices like Test Driven Development (TDD), pairing through the issues and refactoring code can go a long way in making an existing system performant, allow teams to familiarize themselves with the domain and inside of the system and cut the effort of rebuilding features that never get used.

How can an Agile approach help?

Does Agile make sense for software rewrite? It absolutely does. Agile is all about continuous improvement and systems are rewritten to make them better in many ways including emerging improved architecture and value driven development. One huge benefit rewrites potentially provide is to get away from features not providing business value resulting in eliminating waste for development and maintenance activities.

In general, there is no reason to treat rewrites any different from a green field project. Agile approach if followed in a organized way should help building the right system maintaining a view of expected benefits. Lets assess one area at a time.

  • Requirements – Business and market situations change by the day. Rebuilding what you have today is not an option. Requirements should be captured and backlog created from scratch. While breaking requirements and creating stories, right amount of focus needs to be on the value each requirement offers. Systems with legacy code built over several years always carries a certain amount of risk. With churn in resources and changing business landscape, it is hard if not impossible to be aware of all legacy business rules. Hence, there is significant risk involved in assuming a complete familiarity of existing systems.
  • Small shippable increments and feedback loops – with focus on key improvements provide an opportunity to compare smaller increments with existing systems and adapt to missing pieces. This will also result in the need to understand only the part that is being recreated. Small shippable increments facilitate continuous feedback loops for faster validation and confirmation.
  • Speed to market – Continuous improvements in existing systems made in small shippable increments can be made available to customers frequently. This can go a long way in meeting customer satisfaction.
  • Customer collaboration – What better than engaging existing customers in making the product better. Most customers will be open to provide feedback about the system. Agile development principles encourage active ‘user’ involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.
  • Team collaboration and knowledge building – Giving the team the space to understand existing system and propose what the new system should look like brings out the creativity to resolve business problem in more innovative ways and facilitates domain knowledge creation.
  • Engineering practices – are the key facilitators towards building software right the first time. Rebuilding is no different. These practices encourage refactoring to address issues with existing code and help in building quality with rewrites.

There are enough benefits to leverage agile principles and practices for software rewrite. Writing the software the way it exists today does not provide any benefits but results in significant waste and limits focus on improvements. I can say that Agile can be as effective for rewrite as it if for greenfield projects.

So, evaluate the opportunities through refactoring before you walk the road to rewrite from scratch. And if rewrite is the only choice, going with an Agile approach will provide the right tool towards building the next version.

Have you used Agile for a rewrite? If yes, do share your thoughts.

%d bloggers like this: