Agile Adoption is Everyone's Job: An Interview With Jerry Stubbs
An interview with Agile adoption expert Jerry Stubbs, where he shares advice for working with distributed teams and c-levels to make Agile work.
Join the DZone community and get the full member experience.Join For Free
A few weeks ago I spoke with Jerry Stubbs, the Associate Director and Head of Agile at SQS. Jerry had a lot to share about Agile adoption and the benefits of Agile.
DZone: Could you tell us about SQS?
Jerry Stubbs: So figures-wise we have about 4,000 employees and last year’s revenue was about 270,000,000 Euros, just to give you a ballpark. We’ve organized ourselves such that we can work with various different industries such as banking, finance, insurance, aero, retail, and auto. Underneath that we have a number of service offerings, so internally it’s divided into functional testing, load testing, automation, and performance. Agile, although it’s a little different in terms of makeup and flavor, is in essence a service offering in parallel with those.
DZ: Can you tell me more about that service?
JS: Within our Agile space, and this is something we’ve put some time trying to put together, we find that almost always the first thing clients want to better understand is “where they are” and “where they could be.” And that kind of delta, that gap, is something we can offer by way of a capability assessment. So what we do is look to see where we think their Agile strengths are, and we can chart that so they get a better feel for exactly where they are. Then we look at their culture, environment, and where we think they could be, then explore the ways in which we can narrow that gap. Other services we offer include how we help them make that transition with guys we have here on site.
Then we work a bit around Agile tooling, which isn’t a focus of the Agile work we do, but often when we work with clients who have already set themselves up with a bunch of tools that help them with what they’re used to doing, they try to leverage those tools into an Agile space, usually not to good effect. We look at how to better integrate the tools they’ve got, so they have a better Agile leaning, or suggest that they scrap those tools in favor of ones that are more oriented to Agile. It’s a relatively thin service offering. We’re usually helping them with how to get them to a better place, especially around the culture, and the changes they need to make within the organization itself. We offer an Agile delivery service as well so we can augment their teams with Agile-experienced people, and we obviously run a bunch of training too, which we can run on-site or off-site, and it helps close the gap between where they are and where they’d like to be.
DZ: You mentioned companies with existing tools being poor to move into Agile. What kind of tools are poor choices and why are they poor choices?
JS: A lot of tools they might typically be involved with from a waterfall perspective come from a process-oriented starting point, so they underpin a waterfall, sequential process. So they would have repositories for requirements, traceability of requirements against test cases, they would form repositories around those test cases, and they support that waterfall workflow quite well. But we’re looking to adapt and change what we’re doing and how we’re doing it through collaboration. Especially the in testing, where we’re not looking at the above GUI type stuff that system testers would be looking at in a waterfall environment. We are more focused on under-the-GUI integration and even unit testing areas. So the tools they’ve typically got in play are not typically the ones that best enable them to make that journey.
DZ: I was reading your article "Have We Lost the Art of Agile" and you mentioned properties of Agile that have been lost in realities of everyday business. What are some main principles that companies need to get back to for the good of everyone?
JS: In a waterfall environment, we lock down the process and allow quality to flow. In an Agile environment we lock down the quality and allow the scope to flow, and this works very well especially within the teams themselves, who completely get that. At some level within an organization that doesn’t really get it, there will be a question: “Yeah, I understand this is all great, but when are you going to deliver it?” There’s still an element of “I want to lock the scope so I know what I’m getting and how much it’s going to cost me.” So that is a fundamental disjoint between the clear principles of Agile, which say “we’re allowing scope to flow” as opposed to the waterfall where we’re promising to deliver something and, by the way, fail. We need to get the principles of Agile seeped into the whole organization, not just the development arena. Part of my job is to secure that thinking at the C-level and with the guys who are actually doing it. Getting that buy-in across the entire business really gets everyone moving forward along the same line. But for as long as there’s that disconnect where the CFO says “Here’s your 500K, now when am I going to get it?” to me always suggests there’s that discontinuity in the breaks, so we need to make sure everyone’s in line.
DZ: What’s the best way for a company to enact this cultural change for the whole organization?
JS: We’ve all seen organizations try the top-down approach when there comes an edict: “we feel that Agile is the direction we want to move in, so go do it.” And we’ve seen that fail, because you need that buy-in and it peters out early on. More often than that I’ve seen organizations where the development teams says “There’s got to be a better way, I know about Agile, let’s try it,” and you end up with pockets of agility within organizations who are doing the best job they can. The fact is they don’t have the support or environment to do a really excellent job, and pockets of agility don’t tend to scale very well. I’ve seen a number of organizations that just hit this ceiling and it’s doesn’t get any better. So the best approach is obviously the two-fold one. We have the developers that are bought-in and talk to the c-levels to communicate the culture change that needs to happen. And some of those culture changes are massive, especially in terms of ways organizations are siloed.
For example, we know that a lot of organizations tend to separate the business people from IT and ops, and we tend to talk to directors and SVPs of those silos. One of the fundamental things we have to do is break those down and lessen the command/control scheme that a lot of organizations spend a lot of time building up and putting in place. So I’m speaking with the C-levels and trying to dismantle that from the inside whilst bringing the guys up to speed with how to be able to do this on a procedural level with the developers themselves. It’s a real challenge. Unless it’s done together then it’s less likely to be successful.
DZ: Are there any good tactics to get more technical and business people to communicate with each other to make sure they have the same goals in mind?
JS: There are lots of messages that we can reinforce. This is easier with physical pieces like scrum rooms adorned with things like the progress they’re making and the values they hold. We’ve got the Agile manifesto on the wall. That helps reinforce the message to everyone working in that room and working past that room, it’s a constant reminder of what we value and a way of doing things. The most important thing is “nothing succeeds like success.”
So as we’re developing software more quickly and it’s better quality and we’re getting that feedback from customers that says “This is really great stuff.” Celebrating that message creates this “virtuous circle,” where people begin to realize that the changes they’re making and the behavior they’re now adopting really is making a difference to customer satisfaction, which is what drives us. So having those metrics in place and being able to understand that tangibly help us reinforce the fact that what we’re doing is good, and how we can make it even better. We have that opportunity to adapt to what we do based on the information we’ve got.
Fundamentally I think the big difference between the Agile approach of now and the waterfall approach of yesterday is around the feedback loop. So in Agile we have that baked in through retrospectives and the metrics I mentioned. The problem with waterfall is that there’s this cascading mechanism that ignores feedback that could influence tomorrow, and that’s a big blocker when you’re trying to drive customer satisfaction.
DZ: So a huge part is getting positive reinforcement from members of the team to enforce the message that this is the right way.
JS: Yes, and I think you need the right people in place in order to do that. The kind of people who respond well to that positive feedback are looking to improve their product even more, and they are thirsty for knowing even better techniques. So they’ve got to be motivated to improve what they’re doing so the next iteration will be even better. That is part of the collaborative approach that most agilists would take. They would be very anxious to speak to other sprint teams to see what they’re doing and how they’re doing it. When we’ve been on customer sites, and working with clients where they’re trying to improve their processes as a whole, getting these teams together generates such a buzz, and they are keen to figure out how to improve what others are doing, and that’s a huge part of this virtuous circle as well.
DZ: In your experience, have you seen companies get on this path for a while and then fall off as they feel the pressures of deadlines? What kind of steps can keep a company on track?
JS: There are two things that tend to happen, and both of them are cross-checked by these same metrics. When all hell breaks loose, you get the message “Yeah I get it but I still need this done tomorrow.” And then that starts breaking down the fundamental principles I’ve been speaking about. Shipping software quickly like that results in the poorest customer satisfaction. Was the delivery successful? No, you got it out the door but the customer wasn’t satisfied, so I think that quick feedback tells us “let’s go back to the way we should be doing it, and let’s not have people in a position to force an exit on a project because we have a deadline that’s been artificially generated.”
The other thing is complacency. Organizations that have been running Agile for a long time I’ve seen have tended to say, “We know each other so well that we don’t need retrospectives, and we don’t need to do these meetings because we talk so much anyway.” Now I found that without having that dedicated slot to clear out your thinking and present what could improve, a lot of stuff is unsaid. Quite quickly those opportunities for improvement are lost, and it becomes difficult, especially with the team that tacitly agreed to this, to resurrect it. Because if you were then to say, “I think we need a retrospective,” someone will ask, “Why? What’s wrong?” So you need to resurrect it and stick with it. And the new ideas that come out of it are fantastic! So complacency is an enemy, and reverting to type undermines these kinds of transformations.
DZ: For some bigger companies, transitioning to more Agile methodologies can be difficult just due to the sheer size. Is there anything that’s just plain unrealistic to implement?
JS: “Big bang” methods hurt, because there’s so much to do and so much that could potentially go wrong that there’s a risk that Agile gets titled as being the reason this failed, rather than it’s implementation. So Agile gets a bad time because of the attempts to implement it. With large organizations, we focus on the c-levels to start with to get their buy-in, and then look to see where in their organization would benefit most from going Agile. With support from the c-levels we can start to grow Agile form those small pockets, and look for opportunities to radiate just how successful that group has been. And then we get that degree of infection, it goes viral, and lots of people want to know about it. It’s not just bottom up because we went to the c-levels first. So that tends to be the approach I take with large multinationals. There are plenty of challenges, not the least of which is the partial reorganization of their current structure. There are other challenges about distributed working sites and how we can get those to work well in an Agile environment, but none of those are insurmountable. As I said before, continuously reinforcing those successes helps very much with the establishing of Agile in large organizations.
DZ: You mentioned distributed teams, what’s a good way to manage them and get their buy-in?
JS: A lot of organizations I find that ware used to waterfall have offshored various functions. So testing is done in Texas and development is done in Bangalore, and that may have worked well for them in a waterfall environment, but in an Agile environment where we’re focused on the whole team, attempting to separate out functions within that team is very unlikely to work. My solution, which is less than perfect, is to partition the teams so there’s a whole sprint team in Bangalore, a whole sprint team in Texas, and they get to work with the same Product Owner and can collaborate with each other on their site and there’s less fracturing than if the whole team itself is torn apart by geography.
So you separate into whole sprint teams rather than tear the team itself apart. Some of this is difficult to do, and some of those teams are fractured, and in that case I fully suggest utilizing technologies like web conferencing so that with a little bit of time zone adjusting its possible for teams to look like they’re working in the same room. Then you’ve probably got the best compromise, and the cost benefits are huge, and outweigh the cost of implementing the technology.
I think the next steps for Agile are that we’ve spent a lot of effort breaking barriers between business and IT, and now we need to include operations. They’ve always sat to the right of what we’re doing, but through DevOps and new techniques that extend into that space, we should be even more inclusive of the whole development and deployment activity, which we haven’t quite done on that scale, so the next challenge is to explore DevOps.
Opinions expressed by DZone contributors are their own.