This is part one of a three part series, where I explore the fundamental shift in adopting an agile development methodology and explain how to analyze and measure success.
Like most start-ups, Roambi started its product development roadmap with a small group of incredibly talented people and a great idea. In the early days, traditional product development process seemed unnecessary and a great hindrance to getting product out. After all, each person was not given a single set of tasks that fit neatly into a perfectly carved skillset. No, like most start-ups, everyone was a CEO. Everyone had skin in the game and every detail of every decision, whether it be architectural or product design, was debated and refined by a small group of stakeholders. Awe, the glory days!
Fast forward just months and Roambi had grown leaps and bounds into an adolescent software development organization. This is where traditional development process and practices begin to take hold. Pulling from our own mixed experiences and our product’s obvious fit into the enterprise on-premise software world, we began to formalize a waterfall approach.
DISCLAIMER: Although I am an agile evangelist I am not one of those individuals that will belittle what waterfall can provide. In fact, I am a strong believer in an organization exploring any and all development methodologies that work best for their product/s and bring value to their customers.
Waterfall was familiar and fit neatly into our predicted release schedule. We had many long-term initiatives to work on, while also keeping our focus true to the overall success of our customers using Roambi in an enterprise environment. At this point in time we were planning for one major release a year, and service packs every quarter, of course with the occasional hot-fix to address high-priority items. We had adopted a well known bug tracking tool, JIRA and had a formal process around PRD’s (Product Requirements Document), TRD’s (Technical Requirements Document), design specifications and test plans.
Roambi’s growth was exponential in almost every aspect, which was also true when it came to development, product and QA resources. The process scaled nicely but the obvious drawbacks were knowledge transfer and overall visibility. Teams began to organically form and silo around technology and skill-sets. We had teams for iOS, Java, Ruby, Flex, etc. Although this strategy worked for our release cycle and continued to bring value to our customers, there was almost always a huge barrier when it came to integration and a true “cross-functional” collaboration. This ultimately ended up costing us precious time in getting our product to market as quickly as possible.
The Tectonic Shift
We had built and and delivered the most innovative, user-centric and fully comprehensive mobile analytics solution on the market. We had become the “standard” in data visualization on mobile devices and had happy customers all over the world. Our customers were using Roambi on a daily basis to solve real-world problems. But this wasn’t the time to rest on our laurels. A cloud offering had always been part of our strategy and in fact, we had already launched a freemium cloud version called Roambi Lite in 2009, later followed by Roambi Pro in 2010. It was time to adjust our focus and to bring the same level of enterprise functionality to a larger audience willing to embrace a cloud deployment strategy. Of course, this type of shift put our entire development methodology into question. It wasn’t just time to change the way we delivered software, it was time to fundamentally change the way we thought about building and delivering software all-together.
I’m sure I don’t need to tell those of you that have been through this type of transformation but for the rest of you, trust me, this is no easy task. It was obvious to us that a transformation was required to meet the expectations of delivering cloud software, but the “how” and “what” was still open to interpretation. An agile approach was an obvious fit but not without much deliberation over specific details and a complete understanding of what “agile” would mean at Roambi.
Agile is a funny thing, sometimes even scary, for a company that has already adopted a different development methodology. Sometimes, even the word “agile” comes with a certain amount of baggage. Even though at Roambi we were very open and willing to investigate a different approach, with that, you also have to be mindful of what other’s experiences are or have been. These are a few examples of what we heard when investigating an agile approach.
- “Agile was created by developers and product managers, who secretly set out a plan to overthrow the executive staff and take control of every strategic product decision without repercussion…muuwwahahahaha (evil laugh).”
- “Agile isn’t really any different from what we already doing. So, you call a milestone a sprint and you ship product when it’s ready? Easy…done! We’re already agile and didn’t even know it! (pats self on back)”
- “Agile is a lightweight framework for getting things done. A template, for delivering value to customers in a more predictable way, while being “agile” enough to adapt to a changing roadmap on a quicker interval than a traditional waterfall approach.”
Alas, after many weeks of heated debate, whiteboards caked with powdery marker dust and empty bottles of fine southern California micro-brews, we decided it was time to move forward and roll-out a new agile development methodology. We set forth a plan of attack, making sure to involve all stakeholders and finely tune a process that worked best for us.
There were many discussions and meetings set up to elaborate on the exact details of an agile approach. We discussed everything from which tools we would use to what specific agile methodology we would adopt to a daily sprint timeline and cloud deployment strategy. When you’re making a change this big that truly affects the entire company, you have to get it right. You also have to be flexible enough to change the process and adapt to real-world needs within your organization. We knew this process would create a voice for everyone involved and that’s great! That’s exactly what we wanted but we needed a framework in place to take that feedback and fine-tune our process even more.
In the end, we decided to adopt scrum and update our installation of JIRA to take full advantage of JIRA Agile, formerly “Greenhopper”. We formed 8 specific scrum teams, organized by product component and related feature sets. We trained our product managers to write user stories instead of PRDs and full blown specifications. We educated our QA staff to be informed and engaged at the beginning of a sprint instead of right before a release. We formalized roles and responsibilities within each team and gave an equal voice to everyone that participated. The initial feedback was amazing! In fact, I recall a specific team retrospective where a team member said, “Wow, I can really see how this process sets a framework to be constantly tweaked and improved, allowing us to get better and better every sprint!” An overall acceptance of what we were doing and why, coupled with the right set of tools for analyzing and tracking success was the clear way to achieve our goals.
Don’t get me wrong, there was plenty of confusion to start, even chaotic at times but the majority of that was simply getting used to something different. It was much like riding a bike without training wheels for the first time. You start slow and a bit wobbly but once you get the hang of it, you’re doing things you never thought possible, all with a newfound sense of freedom and maturity.
This is part 1 of a 3 part series. In the next post I’ll get into specific details about how we execute from sprint-to-sprint, backlog and roadmap management and maintaining focus.
Justin Cox is a Senior Product Manager at Roambi. Along with his product management responsibilities on the Roambi platform team, he’s also the resident agile evangelist and JIRA expert. Justin has more than 10 years experience and has co-authored multiple patents in data visualization.