Developing the Subscription Update to the Axure Customer Portal

I figured that the recent visual and UX design update to the Axure customer portal would be a good opportunity to take you behind the scenes at Axure to look at the life cycle of a similar project: our previous portal update, which went live this past April and coincided with the Axure RP 8 release. This particular update focused on adding tools for purchasing, renewing, canceling, and assigning subscription licenses of Axure RP.

We’ve been refining how we build software here at Axure since 2002, and by this point the process is pretty streamlined. But we don’t adhere to any particular espoused philosophy of process management; we aren’t a strict Scrum Agile shop, and we don’t make use of a Kanban board. Our approach is informal by design, which makes it hard to encapsulate in a pithy five-point list or what have you. But what I can do instead is describe it by example.

(This article is adapted from a portion of a talk I gave in September 2016 at UC San Diego, organized by the extremely nice people over at San Diego Experience Design. I’ll be sharing more from the talk, which was about Axure’s software design and development methodology, here on the blog over the next couple of months.)

Rachel, one of our product managers, ran the subscription update project, and she worked with Kevin, one of our developers. Victor—our CEO and our head of product management—was also involved because he was responsible for the change from the business side. The idea was to make subscription licenses, which were new to Axure RP 8, manageable via the existing license management portal. We needed this change for its own sake, but we also needed it a little ahead of the Axure RP 8 release so that we could test activating Axure RP with subscription licenses.

The scope was limited for this update; we knew what we wanted to accomplish, and we also had a set of things we wanted to avoid. At the time, we were planning for a comprehensive visual refresh of both Axure Share and the customer portal. The plan was (and still is) to unify those two properties so that they shared the same design language. We didn’t have the new design patterns in April, so Rachel was instead prototyping using the then-current Axure Share assets so that we could begin to bring the two properties together in anticipation of the later visual and UX refresh.

We tend to start the process of developing a new feature pretty informally. The first prototype won’t be very “deep”—just two or three screens. Victor will give feedback and clarify. Rachel will find some conflicts as she’s incorporating the requirements and will present some possible resolutions, and Victor will weigh in. There wasn’t much competitive analysis on this particular project, but in this case there was a fair amount of comparative analysis, where we looked at how other software products of all kinds have implemented subscription mechanisms.

Development can begin as early as when the main scenarios have been addressed in the spec (i.e., the prototype). If the prototype gets to that point and the developer is still wrapping up another project, Rachel will continue to flesh out the spec, and it’ll be more complete by the time development starts. Either way is fine.

In the case of this particular project, once Kevin had wrapped up his previous development work and had come on board, communication was a lot of chat, via Slack, and a lot of face-to-face. Kevin had the RP file to work from and would generally ask questions via Slack first, some detailed, intended to stay on chat, and some short, followed by: “hey, can I come over?” (Rachel’s desk happens to be next to mine, so I can confirm that Kevin was coming over a lot for a couple of weeks there. Which was nice for me, because I like Kevin.)

Because they built it, Rachel and Kevin are now the resident experts on the set of features included in this portal update—which at Axure means they’re the point people for any bugs that come up. They’ll switch back to the portal project and prioritize it when a bug needs fixing. This can put them behind on current projects, which isn’t ideal, but it’s a concession that we make in order to preserve our culture of work and ultimately boost the quality of our final product.

If we were doing strict Scrum Agile development, the Scrum Master might get concerned about the distraction of a portal bug fix and potentially push for Kevin to return to his current project. And poor Kevin would have to stand up the next day and admit that he didn’t get anything done on the current project because he was fixing the portal.

Kevin takes deadlines very seriously, which is great. But if he were made to stand up and account for time spent on live fixes every day, it could be a recipe for anxiety and sleepless nights. Now, you might argue that that’s a personal issue on Kevin’s part, but we’ve found that happy, relaxed developers write better code, and so we prioritize that over sticking to a daily or weekly schedule.

The imposition of Scrum Agile on a team is, let’s face it, a drastic measure. It’s a step to be taken when your team has demonstrated a clear, compelling need for it. The subject of what constitutes a good reason for implementing Scrum Agile is beyond the scope of this article, but for now we’re happy to concede that good reasons do exist.

In situations where a strict process management framework is called for, to avoid implementing one is to doom your team to inefficiency. But to impose one for its own sake, absent a compelling reason, is just as misguided. Ultimately, we’ve decided that a formal Scrum Agile approach—or any other formal approach to managing our software development life cycle—is unnecessary for the way we work today.