Remove From Your Process as Often as You Add To It - Mike Cohn
Can you imagine being so angry about a team doing something wrong that you institute a rule for them to follow for the next 100 years? Literally 100 years.
Queen Victoria was that angry.
One day in 1894, the Queen went to the Horse Guards building expecting her Household Cavalry to be ready to escort her back to Buckingham Palace. She instead found the guards either asleep, drunk, or gambling.
Infuriated, she commanded that an inspection of the Guards be held at 4:00 p.m. every day for the next 100 years.
I’m guessing the Guards got the message to stop sleeping, drinking, and gambling on duty long before 100 years. The 4:00 p.m. inspection could have stopped after perhaps a year or two. Maybe sooner.
Things that become part of a team’s process sometimes stay there too long, like that inspection of the Queen’s Horse Guards.
This happened in a company that had a large database that was shared by multiple applications. When one team changed the database, they screwed up the change and left other teams scrambling to quickly change their code in production.
They held a multi-team retrospective and agreed that each team would produce a Database Impact Report every sprint. The report would describe how a team’s work would affect the database.
This doesn’t sound horrible yet, except it was rare for most teams to do any work at all in a sprint that would affect the database.
These teams were still expected to complete a Database Impact Report each sprint that basically said:
- No impact
- No impact
- No impact
These no-impact Impact Reports were emailed to all other teams.
After opening a PDF every two weeks that said “no impact,” recipients stopped bothering to even read the reports that were still being generated.
Stop. Just stop.
These reports were probably useful for a period. They may have helped identify a risk. They certainly made people more aware of the impact a database change could have on other teams.
But after a while, they should have been removed from the teams’ process, especially once the teams who actually did routinely alter the database had found better ways of communicating potential impacts.
In retrospectives, it’s always tempting to look for new things to add (“Let’s start using AI to inspect our code!”).
But make sure you also reserve time in retrospectives to look for things to remove.
Unless your team members are all drunk, gambling, or asleep at 4:00 p.m., you can probably find something to remove from your process.
A barely sufficient process with unnecessary actions and rules removed will help you succeed with agile
How to connect with AgileDad:
- [website] https://www.agiledad.com/
- [instagram] https://www.instagram.com/agile_coach/
- [facebook] https://www.facebook.com/RealAgileDad/
- [Linkedin] https://www.linkedin.com/in/leehenson/
