Agility is Mutual Respect

(This article is adapted from a talk I gave in September 2016 at UC San Diego, organized by San Diego Experience Design. I shared another portion of the talk last month.)

Does Axure practice Agile software development? The short answer: yes and no. For the long answer, read on.

We definitely wouldn’t qualify as a strict Scrum Agile shop. And we aren’t Lean, in the formal sense of that term. (Though we do feel pretty lean, to me, in the informal sense.) We don’t do stand-up meetings; our formal development meetings are once per two weeks, not daily. We don’t do formal pair programming. We don’t do formal sprints.

So what do we do that’s Agile? Lots and lots of face-to-face conversations among and between the development and product teams. There’s a lot of trust between teams, and we actively foster that. Trust is the best thing we’ve found for positively impacting motivation. And motivation, in turn, is the parameter of our work environment which we’ve found correlates best with productivity and quality of output. So we invest however we can in maintaining ourselves as a highly motivated group of people.

We very much welcome changing requirements. We’re always on the lookout to make sure the solutions we’re coming up with are solving the problems they’re intended to solve—and if they aren’t, we adjust. Even late in the cycle, during our (quite lengthy) beta periods, we’re careful to maintain enough flexibility to evaluate changes.

We practice continuous delivery (ready to release a current version of the software at any time), though not continuous deployment (releasing every day via an automated system). We do deploy incremental builds sometimes, within our larger framework of major releases. We do a lot more of that toward the front end of a release and less as the release matures. And we’ve actually been working to reduce the number of incremental releases per cycle, for a number of reasons.

To elaborate: over time we’ve gone from shorter betas, earlier releases, rapid updating and bug fixing, to longer betas, later general releases, and fewer but more substantive post-release updates. We’ve also begun to release our higher-risk builds via a release candidates channel. So the RC is now for the people who want to be on the latest and greatest with every bug fix, and the general release builds are the super-stable ones that big companies can be sure will be safe to install and standardize on.

When the dev team deploys, there’s a certain amount of overhead to each new build. So there are benefits internally and externally from releasing better builds less often. With fewer builds going live, we can now dedicate less time to the overhead of managing releases. We’ve decided that this leads to us releasing higher-quality software overall.

So: are we Agile? Yes and no. And that’s okay.

Agility is context-dependent. By contrast, the various prescribed Agile and Agile-like frameworks—just as with any set of best-fit guidelines—are context-independent.

• Scrum
• Lean
• Kanban
• XP (Extreme Programming)
• DSDM (Dynamic System Development Model)
• Crystal Methods
• SAFe (Scaled Agile Framework)
• DAD (Disciplined Agile Development)
• Spiral

And by context-independent, I mean that each of these frameworks was devised to apply broadly to a wide range of software projects. They’re like off-the-rack suit jackets: they fit some of us quite well and many of us fairly well, but a bit of tailoring—or an entirely bespoke alternative—will almost always cut a better figure.

Of course these frameworks do have value, even to those of us who aren’t strict adherents: they’re sets of good ideas, from which successful teams pick and choose.

And yes, the way we do it at Axure, there are some waterfall model practices mixed in there as well. I know that may be heresy to say out loud in 2016, but stay with me.

We talk to customers all the time about this. Axure RP is used by lots of teams who describe themselves as Agile to some degree, but the Axure RP work may not actually happen in the sprints; it happens in the pre-sprints. Pre-sprint planning, or pre-project planning. Sprint Zero. Sprint Ahead. Or they’ll call it “backlog grooming”, but in the end it’s quite a lot like the traditional waterfall practices of product requirements planning and design.

And these customers generally aren’t doing two-week sprints or cycles. Much more typical for our customers are six-week or even six-month cycles. Some of the customers we speak to are anxious about Agile. They’re perpetually trying to transition to a “pure” Agile approach, but never getting there. Other teams are comfortable with, and prefer, their six-month cycles. They’re accomplishing good work, the team’s spirits are good, and two-week sprints just sound like needless strife and chaos to them. And at least it’s not the two-year cycles they used to have. It’s relatively agile.

At Axure, we build software, but we’re different from many of our customers in that our software is used to build other software. So we’ve got two perspectives on process management methodology: from running our own process, and also from talking to customers about how we fit into their processes.

When it comes to our own process, we don’t speak in Agile terminology much at the office. You’ll only overhear someone at Axure HQ speaking in terms of “sprints” if they’re on the phone with a customer who practices Agile. Each team develops a process that’s best for them. In our case, we’ve been building Axure RP since 2002, so we’ve learned a lot over the years about what works best for us.

The principles of the Agile Manifesto boil down to communication and accountability. Everything else follows.

You could call what we do “loose agile”. It’s highly iterative. There are regular check-ins, though they generally aren’t scheduled. We rely on the esprit de corps and motivation of the team, the idea that everybody on the team wants the work done. So we try to keep team spirit as high as we can, and we open up communication among and between teams as much as we can, and then allow the process to happen as organically as possible within that framework.

You could summarize by saying that it’s a culture of mutual respect. If the dev team says they need time to re-architect something, the product team believes them. And vice versa if the product team needs time to rethink, to change a requirement.

Now, this may sound like a dodge. What does mutual respect have to do with choosing Scrum vs. Lean? Here’s the connection: if you look at the principles of the Agile Manifesto, they essentially boil down to communication and accountability. Everything else follows.

Simplicity, for example. If the team is communicating freely and everyone feels accountable for the end product, there’s a minimum of wasted effort. You don’t have people accidentally working on the wrong thing, or intentionally not producing because they aren’t motivated, or not sure what to work on because they’re scared to ask.

Continuous delivery is about keeping your sights on project goals and staying on track and keeping motivation up. Two-year software projects are inherently depressing—or emotionally challenging, at the very least. Sustainability is explicitly also about motivation. And motivation, we’ve found, is primarily affected by communication and accountability. So it seems to all come back to these.

CULTURE OF RESPECT ⇒ COMMUNICATION AND ACCOUNTABILITY ⇒ AGILITY

And for us, the culture of respect gives us both of these. It’s what allows us to effectively communicate amongst and between teams. Respect is also what leads to each team member feeling accountable for the end product. And respect leads to trust, with all of the benefits I mentioned earlier. And so mutual respect amongst our team members is what allows us to be agile, in the original spirit of the Agile manifesto. (In one author’s humble opinion!)

The prescribed Agile frameworks are designed to be more flexible than the prevailing software development practices that came before them. What we’re doing is arguably even more flexible. Lighter and looser. I say this while also acknowledging that our teams are fairly small as compared to a lot of organizations. The average tenure of an Axure employee is quite long, turnover is very low, and managers of teams have generally personally hired all of their reports. And we have about one product manager for every three developers. So we have lots of advantages that allow us to get away with being loose and informal.

We’re well aware of the perils of growing our headcount; we’ve seen many different scenarios play out on our customers’ teams. So some day it may be different, and then we’ll have to adapt. But the culture of respect will continue to be a constant, as best as we can manage it.