Skip to main content

I have coached many scrum teams over the years. On the whole, they are cute and adorable. They like to rally around a fun and unique team name like Scrummy Bears, Scrumbledores, Scrum and Coke, and Scrumdog Millionaire.

Do an internet search of ‘Scrum team names’ and you will be overwhelmed with creative ideas to the point where one would have to conclude that this team naming thing has become quite a cult phenomenon. Of course, team names have nothing to do with delivery performance and the production of high-worth value back to the customer, but that’s the easy part, right?

The nice thing about scrum, is how fast and trouble-free it is for a team to become high-performing and predictable. Here’s a short, partial list of what it generally takes:

  • A team needs to be the right size, like the size of pizza. Did someone say pizza? I LOVE pizza! Anyways, you don’t want to be too large, because who wants to be the one to take the last slice of pizza?
  • You need an experienced Scrum Master who is the voice and protector of the process, one who can hold a team’s hand through the rough waters of scrum. Teams, you need that, right? Fortunately, there’s no such thing as a bad or inexperienced scrum master; otherwise, why would they confidently be named ‘master?’
  • You need the right mixture of Product Owner engagement who is good at writing stories and communicating priorities, but not too overbearing and invasive to where the team is dis-allowed from discovering the ‘how’ to the ‘what.’ Probably not even worth mentioning; it’s a given, right?
  • Teams need to be together for a long period of time to get through Tuckman’s stages of group development – forming, storming, norming, and performing. Like a long time, but you’ll get there – won’t you? Of course you will.
  • If a team experiences a loss of a key person or two, you must revisit Tuckman’s order all over again. Just a minor setback.
  • Teams need to learn to be cross-functional, or T-Shaped, or E-Shaped, or pear-shaped – wait, I digress. Anyways, ya gotta be willing the share all your trade secrets and specialized skills so that someone else can take on the stories you used to work on to provide individual value. The nice thing is – it takes very little time and developers are known to naturally be open and to share. Remember, sharing is caring.
  • Teams need to manage their WIP. No one ever tells you why; it’s easy so just do it. It’s comforting to know that most teams don’t struggle with taking on and taking in too much simultaneous work, and if they do, a developer can test, and a tester can develop, right? In fact, let’s just agree to abolish that phrase, ‘Stop starting, start finishing.’ So annoying.
  • Teams need to have a nice, gradual burndown chart, where stories are completing throughout the entire length of the sprint. No ledge drop-off burndowns. No up-hill climb burndowns. Just nice little stair steps. Baby steps, people! This helps your scrum master sleep better at night.
  • Teams need to swarm on high-priority stories together. It’s important to exercise those childhood sandbox skills of sharing and collaboration so you can all celebrate completing a story together. Plus, it sticks it leadership when they want to pin that carryover on one person. Not going to happen – there’s no ‘i’ in team. Competition out, participation trophies in.
  • When writing stories, teams naturally memorize and exercise the story template, use I.N.V.E.S.T. and the 3 C’s as their guiding light, exercise SPIDR to split compound user stories. Heck, what am I doing? You all have already read and marked up Mike Cohn’s 250-page book on user stories. Moot point – you got this!
  • I’m so proud to see teams regularly and consistently writing clear acceptance criteria with CRUD and Gherken – carefully taking the extra time to redocument test cases to know when the story is done; or is that done, done? Or is that done, done, done? Well, you know what I’m talking about. Sheez!
  • Teams must master the alternative to estimating in units of time by utilizing the more accurate estimating tool of Fibonacci. It’s great, right? Takes out all the guess work, plus you get the added bonus of giving leadership a tangible sledge hammer to hit the pinky finger of teams who fail to meet that estimate at the end of a sprint. Nice! (Fist bump)
  • Team ceremonies – all 5 of them * 11hrs * 9 team members = 99hrs per sprint – are really awesome, especially in a remote setting, because they are always facilitated with high efficiency, and all the team members love getting together, away from execution, to sit in a room or on a call. Plus, there are enough of these meetings on the calendar that it becomes the new way of defining productivity: ‘Oh, I was slammed today; so many back-to-back meetings. I’m exhausted! Time to take an afternoon nap.’

Well, I could go on and on about the amazing, simple, and efficient light framework of scrum, but I’m writing a blog, not a novel. For those of you who don’t easily get sarcasm, this tongue-and-cheek approach is a bit snarky, but for anyone who’s been around agile teams for a while, it’s mostly true, if not all true. Scrum is largely an illusion, a slight-of-hand attempt to fool the audience into believing a false sense of reality, which is that scrum is a better way to develop and deliver incremental value.

Even if a team could get close to being high-performing and predictable, some variable inevitably changes the chemistry, and they get knocked off the hill, having to make that long winded climb back up. It’s a never-ending cycle of free-floating anxiety that companies have become so desensitized too, they just redefine and reinvent the win. And do you know who loses? Do you know what gets the short end of the stick? The customer. Because, achieving delivery speed, engineering excellence, and high-worth value to the customer is so unattainable, it no longer becomes the goal; no longer becomes the win. The win is redefined as a belly-button gaze at the process itself with a ridiculous, bloated focus on all the above-mentioned things, which in the end, have nothing to do with fast, efficient outcomes.

With Hummingbird Agile, we seek to pull people up and out of the muck and mire of ‘process,’ yank them away from the addictive bottle of busy work, and into a fresh return and re-calibration back to delivery speed, engineering excellence, and high-worth value. We don’t know if we have the answer, but we are on a quest to find it. But here’s the thing: is the industry too far gone? Is process rehabilitation even possible? Can ‘agility’ be saved? Honestly, I don’t know, and this billion-dollar training empire that is needed to make sense of all the complexity and confusion is not going to let go without a fight. But, we’re going to keep experimenting, deliberating, discussing, and educating. Will you?

Register for a workshop to hear more about how Hummingbird Agile delivery practices differ from scrum.

Schedule a Consultation

Get the Book

Attend a Workshop

Read our Blog

Leave a Reply