Maximize the function of your teams
The Modern Agile philosophy created by the folks at Industrial Logic is one of the most exciting ideas I’ve encountered in a while. Moving beyond the pre-canned “You must do X to be Agile” mindset that I’ve seen becoming more and more prevalent.
Now, scaling the concepts of agility beyond just the engineering teams to address problems that I have increasingly become aware of through my consulting practice. Modern Agile’s four principles fit together well and resonate with me. These principles are the following:
- Make People Awesome
- Make Safety a Prerequisite
- Experiment & Learn Rapidly
- Delivery Value Continuously
As a consultant, I work a lot with people who self-identify as “testers” or “QA.” As a practice director, I lead a practice of even more people who identify themselves in the same way. My thoughts turned to how people in these roles could begin to apply the Modern Agile principles to their daily work. Here’s what I came up with:
Make People Awesome
First, for those who haven’t seen discussion elsewhere, I want to address an aspect of this principle. I’ve seen some people interpret the word “make” as “force” or something similar. I’ve also observed concerns about the actor being the one defining what “awesome” should mean rather than the person being enabled. Having talked to some of the people involved in the creation of Modern Agile, I don’t believe this was their original intent. Since the concerns have been raised, several people have been exploring alternative phrasings to avoid these connotations. This phrase is more akin to “Help enable everyone we interact with to feel as if they have superpowers to achieve the things they want to achieve in ways they might not even have thought possible.” It’s adding value, its servant leadership, it’s helping make the world a better place for everyone.
From that standpoint, some of the more common QA activities tie directly into this goal. Working with the broader team to ensure we’re building the right features, that we’re enabling useful actions for our users, and reviewing documents and plans as early as possible. All of these approaches can help teams focus their efforts on tasks that add value while avoiding rework or going down rabbit holes. More modern concepts like coaching the whole team on quality mindsets and testing activities also help turbo-charge our teams to deliver high quality software faster.
For a tester, there are two main classes of people we can make awesome: the people in our companies and those who use or are impacted by our products. Many of the things we can do to give our coworkers and team members superpowers must apply equally to all of our members such as: fully participating, raising thoughts, building off others’ ideas, and understanding the goals and needs of our broader organizations; all can make a huge difference. We can also tune our testing activities by reporting information that is relevant and timely while filtering out the noise. This can go a long way towards helping our team prioritize and more efficiently handle problems. By ordering our own tasks and smartly applying automation to tighten feedback loops, we can reduce switching costs and queues that introduce delays into our process.
Making our users better can be tricky. As testers, we’re taught to “think like our users” and act as they do or would. While we may be able to identify some actions or thoughts our users could take, we could never fully think or act like our users —we are not them. Often we’re not even in the target pool of potential users. Our customers are the ones who will judge the quality of our product; in fact, they are the only ones who can actually do so! While there may be value in our context in trying to think like our users, we can work with our teams to break big features down into small chunks that we think will add value then rapidly build these small chunks and include instrumentation and monitoring to identify how much our users actually use those features. We can later work with our teams to remove the functionality that isn’t used (improving our team by reducing the technical debt of maintaining code that isn’t needed) and amplifying the value from the features that are used.
Make Safety a Prerequisite
Psychological safety is a critical component for high-performance teams. After studying internal teams at Google, researchers in Google’s People Operations department concluded that psychological safety “was far and away the most important of the five dynamics [that lead to teams being effective] we found”. Joshua Kerievsky (founder and CEO of Industrial Logic) tells the story of how Paul O’Neill turned around Alcoa. He focused on worker safety but chose not to call it a priority, because priorities change frequently. He didn’t want safety to be subject to change; O’Neill made it a prerequisite, allowing workers to fix problems as they encountered them.
A big way that we can foster safety on our teams is by addressing the traditionally combative nature between QA and development. While much of the industry has improved over the course of my career, I still regularly hear testers talk about their roles in ways that could easily undermine feelings of safety on the team. Our role, to draw from Alan Page and Brent Jensen’s Modern Testing Principles, is to “accelerate the achievement of shippable quality.” Part of this acceleration includes working to be seen as a valuable member of the team and not as a roadblock. That doesn’t mean that we lighten the testing we do in an effort to make it easier but rather that we work with the team in ways that builds trust in order to all be working towards the same goal. Activities like: leading the team in discussing how a code change will be tested during planning to help uncover edge cases and code paths that might otherwise be missed, coaching our developers in test writing to help them create better unit tests and automation, and using team retrospectives to discuss how to create additional test coverage so that bugs that do slip past the various checks and tests into production get caught next time all can go a long way towards building trust.
Automation can also add significant amounts of safety, whether it’s created by testers or by developers. Scripts can serve as change detectors that raise unexpected failures (much like unit tests are supposed to do) that make it safer to make changes to the code. We can use automation to cover more variants of tests than we could perform by hand, providing us with better coverage. We can use automation to tighten feedback loops by getting results more quickly. If designed correctly, automation can give us a set of modular components to rapidly test prototype features.
Experiment and Learn Rapidly
Both elements are critical to success; teams need to try new things in order to keep improving. I’ve often seen teams decide to try something, but not structure their experiments in any way that anyone can learn anything from the results. This results in blanket statements like “<Things we tried> doesn’t work” and the wholesale abandonment of concepts rather than the opportunity to tweak and improve our situations.
- Both encouraging our teams to experiment with new ideas and enabling our teams to learn from those experiments largely take paths that apply to all team members, and not just those of us in QA.
- Getting exposure to new ideas through blogs, meetups, books, and videos.
- Discussing the new ideas with teammates. Working to structure the context that the team works in to make it safe to try new things.
- Maintaining a “let’s try it” attitude.
These things all help the team to be open to trying new things, and any team member should be able to do these things.
Our testing and risk awareness skills can be handy as well. Our awareness of how things can go wrong can help us address some of the unseen pitfalls that could lead to an experiment failing with unintended consequences. Test cases have been compared to experiments before and the things that traditionally have led to good test case design also can lead to good experiment design.
Each test case has a hypothesis (the expected result) and it has methods to determine whether our hypothesis is correct (the test steps and verification points). The same skills can help our teams try experiments that actually teach us something. We can work with our teams to define things like what we believe will occur in our experiment (“we think technique X will provide value Y to us”) and what sorts of things will show us. Show that we actually achieved those goals, along with other crucial factors like what sorts of things should we be looking for as indicators that our hypothesis was wrong enough that we should abort the experiment before serious damage occurs.
Deliver Value Continuously
The last principle of Modern Agile is to Deliver Value Continuously. This ties most closely back to Modern Testing’s mission to “accelerate the achievement of shippable quality.” Are these places where testing activities are introducing queues and bottlenecks into the process? What about handoffs, the traditional back and forth between QA and developers introduce queues (how often do you immediately test a bug fix the instant the developer creates it?). These queues, combined with the switching costs on each side as we resume the task, can significantly increase the time it takes a team to release. Maybe we can rearrange our tasks to tighten up those feedback loops.
In some ways, this is the hardest principle about which to give specific advice. The things that the team values will vary from team-to-team and even day-to-day within a team. At the same time, Jerry Weinberg has defined quality as “Value to some person.” If we believe that we already have skills in identifying quality and we accept Jerry’s definition, we should then have the skills to identify what the value is to the people with whom we interact.
