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.
If you read my last blog, you might remember that I mentioned that some people thought that Agile had killed QA. Well, here we are again. In this blog, we are talking about the possible demise of another aspect of traditional testing. This time the aggressors are Machine Learning and Artificial Intelligence. The victim is manual testing. Will Machine Learning and AI replace manual testers? The short answer is no. The longer answer is heck, no! My money is on manual testers continuing to add value no matter what Machine Learning and AI bring to the table.
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.
Back in 1996 I took up golf. I was terrible at it. Like most people who take up a new hobby, I spent a good bit of time (and money) trying to improve.
I went to the driving range a couple times a week, I watched the Golf Channel to pick up tips and tricks (YouTube wasn’t the powerhouse of tutorials it is today), and I read a few books too. But the thing I found most helpful, was actually playing. When I was at my best, I practiced and played a round at least once per week. When I first started playing, I realized many of the more experienced players could easily recall how well (or poorly) they played every stroke in a round. At first, I thought they had better memories than me, but I quickly realized…
A common question for leadership is…
What keeps you up at night?
I hear it asked all the time. And the reactions run the gamut from thoughtful and deeply reflective to reactive and highly emotional. One of the common factors I nearly always hear is fear, uncertainty, and doubt. Which is why I wanted to share this article with leaders considering or engaging in a Digital Transformation. I’ll begin with three things that are often misconstrued and cause sleeplessness on the part of many leaders.
My friend and colleague, Shaun Bradshaw, and I were coaching recently at a client. We started to have a conversation about velocity, not directly driven by the clients’ context, but in general.
Shaun was focused on velocity as a relevant metric within agile teams to drive conversations between teams and upper management, and I was struggling to get there.
Part of his focus was to create visibility around the difference between average velocity and current sprint velocity. Furthermore, the teams and management would be able to see:
During QAI’s Quest conference last week we participated in a workshop aimed to help managers improve their test planning process. The workshop noted that there are several important areas to test planning including: identifying test objectives and scope, assessing and accounting for risks and contingencies, determining component/application priorities, and estimating the size/length of the test effort.
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.
My first piece of advice is this: DON’T DO IT!!!
Probably the worst possible setup for a team is spreading them around the country, world, or the universe and expecting them to behave and deliver like a close, cohesive team.
My second bit of advice for those of you that blame it on management and say you don’t have any say in the matter, is: wrong. You have lots of say in sustaining distributed teams or creating another strategy!