Agile development promotes the idea of self-directed teams and “servant-leadership,” which is a new paradigm for...
many IT managers. Well-known Agile speaker, writer and consultant Bob Galen will be facilitating a session at STAREAST 2012 titled, “A Test Leader’s Guide to Agile.” Galen shares his thoughts on Agile transition and how it’s affecting today’s leaders in this Q&A.
SSQ: Tell us more about the audience for your presentation, "Test Leader's Guide to Agile." Who will gain the most benefit?
Bob Galen: The presentation is focused towards mid-level testing and QA leaders who are encountering Agile transformation in their organizations and it explores the adjustments that are required for testing in those environments.
In my experience, it turns out that testing teams and leaders are often “left behind” in the training and guidance surrounding Agile transition—as Agile adoption is so development-centered. I developed this workshop to focus specifically towards the challenges encountered by testers and test management by “going Agile.”
SSQ: Can you tell us how Agile test leadership differs from test leadership in traditional environments?
Galen: It changes in many ways. I’d like to generalize the question though towards technical leadership across all disciplines. Moving towards Agile methods challenges all aspects of our traditional management and leadership approaches.
For example, instead of telling teams what to do, or micro-managing their activity via monitoring discrete, fine-grained metrics, or being the oracle of all key decision-making, you want to adopt a Servant Leader style within Agile teams.
The focus is on creating empowered self-directed teams that hold themselves accountable to building high quality products that drive value for their customers. In this model, traditional leadership adopts more of a coaching and supportive posture—fostering the growth and enablement of their teams.
SSQ: With the Agile movement towards more TDD and test automation, are fewer traditional test resources necessary?
Galen: Traditional tester-to-developer ratio targets get thrown out in Agile teams. In simple terms, you need to staff your teams with ALL the professional skills necessary for them to effectively deliver the work that is in their backlog.
It’s the management team’s responsibility to effectively staff the teams to get the job done. In my opinion, effective staffing includes testing professionals as an important part of the team. So, in the cases where test automation efforts create execution efficiency and time savings for the team, those savings should be focused towards improved testing and not cutting test professionals.
In other words, I suggest continuously investing in improved quality practices within your teams. I personally believe that the old-fashioned ROI based view towards automation and savings is archaic and invalid.
SSQ: With self-directed teams and the merging of development and test functions, is there less need for QA managers or managers in general in Agile environments? If so, might this cause resistance amongst managers for an Agile adoption?
Galen: I certainly think part of the resistance of front-line managers towards Agile adoption is driven by feelings that their roles and jobs are at-risk. And I do think Agile transformation places pressure on leaders to adjust their styles and approaches. If they do adjust, becoming more of a coach and leader, then I think they’ll be secure and find a place of influence within their evolving organizations.
The problem surfaces with those who resist evolving. In those cases, I do think their traditional roles are at-risk.
SSQ: Do you think Agile adoption is more often driven by management or by developers? What are the biggest reasons for resistance from either group?
Galen: I think the move to adopt Agile is driven equally by both groups—often for quite different reasons. From the development or team side, I think the methods are compelling simply as a better and more humane way to develop software. Many of the techniques are not new, for example, pair-programming or an emphasis on unit testing, so the packaging of useful techniques and approaches simply makes sense to developers and teams.
Often management views the methods initially as a silver bullet, focused on delivering more software, faster. And of course they can deliver more if you apply discipline and a quality focus within the team. But that is not the central focus. I think management is slowly gaining more enlightenment towards the value proposition of Agile beyond it being simply speed play.
Coming back to the notion of ‘resistance’ though, I think management teams do struggle with agility. In my experience, it’s truly hard for traditionally trained managers to empower and trust teams the way agility expects. Many give it a superficial effort, but fail to make the deep transition in their style because they largely feel threatened by letting go of ‘control.’
I read somewhere that the number one or two failure factors for Agile adoption is first-line management sabotaging the adoption—and that rings fairly true with my own experience. I’m not saying they’re directly malicious, but just so uncomfortable with the shift that truly transforming their style is really, really hard.
For comprehensive conference coverage, see our Software Testing Analysis and Review conference page.
Bob Galen is the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. The book addresses the gap in guidance towards effective Agile product management.