I recently came off one of my most enjoyable Agile projects. No really, I enjoyed going to work and doing Agile. I had been saved. My life had structure. The project had its ups and downs but everyone was satisfied with the work they did and the people they worked with.
Agile is beautiful like a cat riding a unicorn while holding a Desert Eagle in front of a rainbow.
I remember regrouping back at the Slalom Consulting office to share the good news with my brothers and sisters. I started talking to one coworker from a different practice but no sooner had my lips started moving than a look of dread seized his face — the same dread you feel after Thanksgiving dinner when your Uncle starts asking you about politics and why he’s not really that drunk.
Why does “Agile” make people cringe?
I think it’s like getting invited to play paintball with some friends. You start playing capture the flag and just when you have your moment of glory and grab the other team’s flag, a referee jumps out and shoots you in the crotch and tells you that two other flags have been added to the course since the game started.
There is solid science behind Agile and Scrum methodologies. It really can work. It really can be fun and rewarding.
Agile has 2.5 times the potency of Supercalifragilisticexpialadocious
Still, I’ve worked on multiple “Agile” projects that made me want to puke. I remember pitching to my boss back in 2008 and getting rejected, and I’m glad I did because the result might’ve been one of those Scrummy implementations.
The best laid plans of process and technology can be sabotaged by culture.
A lot of times, it’s the really small things to that can derail the Scrum methodology.
3 tiny red flags that could mean you’re doing it all wrong
1. A daily email is sent about what happened at morning Stand Up
This is an innocent action. It feels good. Something happened at this meeting. We didn’t waste time. People’s actions are now in writing. Stuff is happening.
And sometimes you really do have to send out the email on some “Agile” projects. Because you know your product owner and team members are not 100% committed to using JIRA or whatever tool that provides transparency.
Yes, it can be annoying to track your time and sub tasks. This is the principle.
In Ken Blanchard’s management-psychology-slash-folk-story book “Gung Ho”, a new factory manager is shown the ancient secrets behind one department’s consistent success among a forest of failures.
One of these lessons is called “The Spirit of the Beaver”.
Each beaver can make their own decisions about how to achieve the common goal. Progress is transparent.
In the book the guru takes the new manager to the site of beavers building a dam. He asks: Does each beaver know how close the dam is to being completed? Do you see one beaver grabbing a stick that was placed by another beaver in order to put it in their own favorite spot? Do you see a dam manager beaver telling each beaver how to cut the dam trees?
If you’re sending out emails about what happened at daily Stand Up then maybe others can’t really see the dam. Maybe others need training on how to use the dam tools so everyone can gauge their own dam progress for the sprint’s dam goal? If you need to know what people did each day… then you should attend Stand Up. If you need to know if everything is on track then look at the damn Burndown. ;)
This a link to Ken Blanchard’s book “Gung Ho: How to turn on the people in any organization”
2. A chicken leads the daily Stand Up
The classic Agile parable about the chicken and the pig, aka, project managers versus developers
When the product owner/project manager guy says “I’m a chicken”, it’s like the greatest sigh of relief. Nothing can endear you more to your developer Jedi except for maybe silence.
And what’s the real difference between when a project manager or business sales person runs Scrum versus a technical lead? A technical lead can help if there’s trouble. A project manager can make sure you’re busy? It’s like the difference between American and British police in the words of Robin Williams.
In England, if you commit a crime, the police don’t have a gun and you don’t have a gun. If you commit a crime, the police will say “Stop, or I’ll say stop again.”
There’s a lot of statistics that could ruin this analogy, so instead let’s talk about NUMMI.
NUMMI was a name for a joint venture between GM and Toyota, which started a couple of years after the original GM plant in California was shut down.
At the old GM plan it was union worker versus boss. The bosses ordered that the assembly line must never stop — even for the heart attack of a worker. The workers kept the line going and freely used drugs and prostitution to keep their minds off of the soul sucking work. The result: a parking lot full of cars that could never be fixed and thousands of defective cars in the market.
How did Toyota change it? They gave autonomy to the workers. Much of the workers were the same drug using union workers from the old plant. With Toyota, employees were encouraged to stop the assembly line in order to fix defects. Managers were there to empower their employees and help augment their autonomy. Manager: “That’s an excellent idea for a new tool. I’ll go to engineering and have a prototype made in fifteen minutes.”
Check out this podcast that talks about the NUMMI plant in more detail. It will blow your mind.
3. You’ve never had the chance to vote on theme music at retrospective
When someone asks a question and silence follows, I’m often the guy that ends that silence with some oddball remark. In past Sprint Retrospectives when the question was asked, “What should we start doing?”, I would either respond with “Disco breaks” or “Theme music”. When people saw the Scrum Master write down my ridiculous suggestion, it signaled a green light of psychological safety. Others soon spoke up with valid suggestions. (And if they didn’t say anything, we’d have been doing disco breaks. Disco! Disco! Oooh! Ooooh!)
My very last Sprint retrospective on one project, I finally got enough votes for “Theme Music”. So I Googled “Star Wars Powerpoint animation”, downloaded the sample, plugged in an mp3 and changed the scrolling text to relate to the sprint and bingo!
Not the actual slide deck I used. I found some Star Wars fonts from cool-fonts.
In Charles Duhigg’s new book, “Smarter, Faster, Better”, he chronicles the habits that accompany highly effective teams. Psychological safety is one of them.
Duhigg shares how Google discovered this with their own people by measuring the norms adopted by successful groups. It was a surprise to those doing the analysis, who at first thought it had everything to do with the manager.
Some of these norms involved making sure everyone on the team had a turn to speak. Making sure workers weren’t afraid to report failures. Making sure workers weren’t afraid to try new things. Their manager would have their back when accidents happened.
Duhigg shared a story from the early days of Saturday Night Live, where one writer wrote a hilarious sketch that would never see the light of day because of network censorship. Even though everyone knew the sketch would be cut, Lorne Michaels had the script read at every table read for the next two days. Can you imagine the impact that had on the writer’s motivation and the teams’s faith in brave innovation?
This reason of psychological safety is why you should ask these questions in Sprint Retrospective this way.
What should we stop doing? What should we start doing? What should we continue doing?
instead of
What did we do good? How did we screw up?What are we going to do tomorrow night, Brain?
The former questions imply action. The latter questions imply favoritism, blame and Animaniacs.
I would also recommend setting a theme for all your avatar pictures in JIRA. We once chose, “non-speaking roles from the original Star Wars trilogy”. Or you could name your Sprints after (insert pop culture reference here).
Again, “Smarter, Better, Faster” is an awesome book. This is the link.
If your Scrum-ish implementation doesn’t allow for autonomy, transparency and psychological safety then you’re not ready for this jelly
Agile isn’t like Beetlejuice, you can’t just say the name three times and have one of the best comedies ever
More signs that you may be doing it wrong
I reached out to my good friend, author and Agile Jedi Knight Will Munn on collaborating about this article. Check out his blog for special advice when you use a techie as your Scrum master.
Here’s some more “shake-my-head please don’t do these” that Will Munn and I came up with.
- Burndown looks like a cliff on the last day of the sprint. Sprints are full with only one story — meaning points are way too high and stories should have been split.
- You’ve got a finger pointer. In ancient times right after the gods decreed “he who smelt it, dealt it” they also decreed “At stand-up, he who talks the most did the least.”
- There’s no dedicated product owner: every good team should know who is doing what and not who is sort of doing it.
- Checking stuff off isn’t fun. Do you feel guilty when you check stuff off because you feel your estimates are never accurate? Each story should be broken down into smaller sub-tasks. They should delineate the specific steps needed to accomplish the story — so that way you get to check stuff off frequently and with the seldom satisfaction and that you did it on time.
- The acceptance criteria is changed during the Sprint. Changing scope after developers have committed to the work is like listening to a presidential debate. It causes a lot of angry posts on Facebook.
He who talks the most is he whom has done the least. This is right next to “he who smelt it, dealt it” in the laws of the universe.