Once again, I have the pleasure of welcoming October. Soon it will be cooler and more colorful here in North Carolina. The holidays are coming, and many of my neighbors have already decorated for Halloween. I have been pondering what sort of ghoulish surprise I could cook up this year, and decided to go with one of my favorite creatures… ZOMBIES! Nothing says horror like a good old zombie movie (or TV show), and nothing brings misery to the otherwise happy-go-lucky people that I work with than Zombie Scrum.
When I first received my ScrumMaster certification, I regularly asked the senior ScrumMasters I worked with what I was supposed to do, besides facilitate Scrum events, enforce Scrum rules, and remove impediments. I tried to be a good ScrumMaster and worked with multiple teams, so I stayed busy, but I had heard that great ScrumMasters could only handle one team at a time. I didn’t understand what could take up that much time. As time progressed, I spent more time reviewing and reflecting on what the Scrum Guide says, and what that looks like in the real world.
I love Halloween. Science may say that autumn starts September 20-something (depending on the year), but in North Carolina the temperatures don’t really get cool until around Halloween, along with the leaves changing and the total Fall experience. I am also a sucker for cheap candy and crazy costumes. When I was young, I loved dressing up and pretending I was someone else for the day. In our modern world, people don’t need to wait for Halloween to wear costumes.
There has been much controversy over whether hardening sprints are necessary or not. See our agile experts discuss the pros & cons of hardening sprints, and learn why a co-founder of agile once threatened to revoke Bob Galen’s agile badge.
Many agile leaders assume that agile is a speed play, and believe that going agile will allow them to get five times more of their software development efforts completed. But that’s not really the case.
Agile Experts, Bob Galen and Shaun Bradshaw, discuss why Scrummerfall behaviors can be risky and can potentially set up sprints for the entire team to fail.
I spent eighteen years testing before I ever worked with agile. When I suddenly found myself transitioning to an agile team after all that time, I thought, How hard can it be? I’d always had a strong work ethic and the ability to handle multiple priorities well. Agile would be no problem, right?
My work ethic and multitasking abilities flew out the window initially when I was thrust into my first agile environment. I thought I knew what “fast paced” meant, but I wasn’t prepared for the hamster wheel moving at the speed of light.
A seasoned director of software development was championing agile adoption at her company. It was a moderately scaled initiative, including around 100 developers, testers, project managers, BAs and the functional management surrounding them. They received some initial agile training, seemed to be energized and aligned with the methods, and were set loose to start sprinting.
I was at a conference not long ago speaking on and sharing various agile topics. After one of my presentations, a young man stopped me to ask a few questions. We struck up a nice conversation that eventually discussing sprint dynamics within Scrum teams. I mentioned that I usually coach teams toward declaring their sprints a success…or (pause for meaningful effect) …a failure.
I do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s). He was visibly upset with my view. He said they (he worked at a well-known Atlanta company) had never failed a sprint. Never! They could not, nor would not, use that WORD in their culture.