In the last blog, we made the case that everyone on the agile team owns quality and provided some ideas on how team dynamics can help build quality into the product. In today’s post, we will discuss some additional ideas on how your software QA teams can work together and ensure quality is on the forefront of everyone’s mind when building a product.
Once upon a time, in the land of Waterfall, the business analysts wrote the requirements, the developers coded the requirements and the Testers tested the requirements. Each of these people sat in his/her ivory tower, um, silo and did that which they had always done since the beginning of time. Quality was thought to be synonymous with testing, and therefore was considered to exist solely in the Tester’s realm.
Are you an experienced tester who has recently joined an agile team? Maybe you have testing experience but until now it has only been on traditional waterfall projects. Are you going through the motions with this new way of doing things but don’t feel like you’re completely invested? Do you even feel like you’re adding value to your team?
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:
After 20 years in quality assurance, I’m still surprised to hear about companies that don’t have formal QA processes. Even more surprising are the companies that say having a QA function is not necessary. Maybe they are a newer tech company with a tiny, tight-knit development team and the software complexity hasn’t reached a level where defects reach a critical mass or perhaps the company doesn’t support a formal process even though it’s happening in some manner. For me, it is akin to saying breathing is not necessary.
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.
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.
Once upon a time, in a far-away land, there was a QA analyst who wanted to please both her manager and her agile team. Pleasing both seemed mutually exclusive at times. This QA analyst consulted at a client organization that thought it had implemented agile, but the result was more Scrummerfall than true agile. Often, the requests received from the manager seemed in direct conflict with the analyst’s commitments to her agile team. The analyst felt the requests not only slowed her down, but also didn’t provide much value.