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.
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!
Wow, the title sounds quite bombastic, doesn’t it? And I sound quite full of myself, don’t I? Well…perhaps I am.
Nevertheless, I want to go on record with some simple and pragmatic advice for agile organizations and teams when they’re trying to sort out how architecture fits in agile contexts.
In no particular order, here are my guidelines:
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:
I’ve been doing more pairing lately. Much more. But, more specifically pair-coaching.
I’ve been pairing in my conference workshops and talks, quite a bit, with Mary Thorn on the agile quality and testing side of things. I’m also pairing with Josh Anderson on our Meta-cast and I’ve done a few presentations with him. Very enjoyable.
I’ve also been pairing more in my writing. For years, I’ve been a lone wolf writer. Nobody but myself saw my writing before it entered the light of day. Now, I’m learning the value of having reviewers and editors. Second opinions matter. A second set of eyes matter. Having a partner in your endeavors can be quite a bit of fun.
In my agile coaching and training journey, I spend a lot of time discussing a wide variety of topics. But certain themes form a Top 10 topics list everyone seems interested in.
One of those items is how to handle bugs. I get questions like:
Do you estimate bugs (planning poker – points)?
Are bugs equivalent to stories?
When do you file a bug while sprinting?
Do you count bugs as part of your velocity?
Can you deliver a story in a sprint with bugs still open?
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.
A few years back I was coaching a large group of Scrum teams at an email marketing SaaS firm. The group had been practicing Scrum for over four years and had become a high-performance agile organization. Most of my efforts focused on fine-tuning from the perspective of an external set of eyes. Working with this organization and its development teams was a privilege.
I remember the threatening email as if I had received it yesterday. I was in my home office on a Saturday when it showed up in my inbox, a message from one of the world’s leading scrum trainers and coaches. Basically, he threatened my certifications in the email unless I “ceased and desisted” talking about hardening sprints.