NOTE: The following is a guest post from Wayne Mulligan. If you want to submit your own guest post, click here for more information.
——–
The company I founded almost 4 years ago, TickerHound.com, was acquired last year.
When we were still an independent company we relied on various agile frameworks and techniques to rapidly build and improve upon our products.
We never had a big enough team to do it completely right (e.g. pair programming, etc.) but we made use of a number of techniques that helped us create a great experience for our users.
Our New Home
Well, that all changed when we became part of the Production team (this encompassed design and development for our web products) at our new home: TycoonU, a financial education provider.
This was a much larger company than ours but lacked any explicit processes for planning, deploying and improving on its products. The development schedule was typically determined ahead of time by the folks in the Marketing or Education departments. The Tech & Design departments were not empowered to make product level decisions without getting approval first.
When I first came on board, conversations like this one were fairly common:
Jack: So, we’re thinking of rolling out a new course website on October 1st.
Me: Ok, great, but you do realize it’s September 2nd?
Jack: Yeah, and we need it to have….[fill in laundry list of product requirements].
Me: Ok, how would you prioritize each of those?
Jack: What do you mean? We need them all.
Me: Ok, but given the tight timeline, it probably makes sense to work on the most important features now, add the rest to our “backlog” and roll them out after we launch.
Jack: Uhmmm…Backlog? We need them all…bye.
I’m obviously exaggerating here (and names have been changed to protect the innocent) but you can imagine how the next month would look.
We’d go nuts for 30 days and after that ONE BIG PUSH was over, we’d sit twiddling our thumbs for a while. And that wasn’t even the worst part.
The worst part was that the concept of rapid iteration and continuous deployment didn’t exist here. Our products would sit stagnant until someone else gave us direction – and the direction would usually come from inside the building, not our customers that were on the outside and actually using our products.
What To Do?
The company really seemed like it could benefit from employing some basic Agile principles – user stories, rigorous prioritization, product backlog, sprints, etc. However, as hard as we tried we were never able to institute a full agile (specifically, Scrum) process into the company. Priorities were constantly shifting. Marketing and the Educators ran the show and the Technology & Design team had very little influence in changing any of that.
So instead of throwing up my arms and just rolling with it — or getting into a protracted battle with the other departments — I hunkered down with our team and asked this question:
What are the primary benefits of an Agile approach to software development and how can we modify some of the existing frameworks to fit this organization?
First Principles
To answer the first part of the question, we turned to the 4 elements of the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Solution
We then looked at each of those principles individually and thought about how they could apply to our day-to-day. Here’s what we came up with:
1. Individuals and Interactions – Originally, when someone from Marketing or one of the Educators would come to us and ask for a new set of features, they’d typically talk about the specific functionality or implementation they wanted (e.g. “We need a forum on this website so our students can talk to one another”). We’d spec the project out and execute as fast as possible.
However, that isn’t what agile is about. Agile values the people the software is built FOR not who’s doing the building.
So we began to reframe the discussion around user goals.
Instead of asking about what functions they’d like in the forum, we’d ask questions like:
- Why do you think this would be valuable to your students?
- What do you hope they get out of the experience?
- What goals in the context of their financial education will this help accomplish?
That forced the person making the product/feature request to think about the issue a bit differently. It forced them to focus on the user and how the user would interact with the product. And best of all, it forced them to prioritize features and functions based on the value to the user!
We found that once we engaged people in other departments in this way, we could begin to propose solutions to the problem that were often simpler and more elegant than what they originally had in mind. This allowed for rapid turnaround times, higher satisfaction amongst our user-base and would get everyone thinking about how to prioritize our efforts in the same way.
Once we had a prioritized list of features, we basically had the makings of a product backlog on which future sprints on which could be based.
2. Working Software – One of the things my team prided themselves on, was even though we worked under tight, predetermined deadlines, we always had fairly polished deliverables. The code, HTML/CSS mark-up and even the source image files were all well organized and clean.
On our next big product launch, the team took a different approach. We began to relax a bit on the elegance of the code and the markup. We didn’t include time for refactoring in the development timeline. Instead, we focused on cranking out functional and usable software.
However, we kept a running list on what we wanted to improve upon later on. This in turn was added to the backlog and would more often than not, become the sole focus of our next sprint.
3. Customer Collaboration – This is perhaps what I think bothered me the most about our process. We wouldn’t methodically gather data and insights from the people we were building our products for.
I mean, we’d put out a survey or two once in a blue moon, but first the marketing guys would go through it, then the Educators and then maybe we’d get access to some distilled version of that data.
So I was ecstatic when we got approval to include a “customer feedback” feature across all of our sites. Now, we can get access to customer feedback in real time.
Not only that, but we found that people actually wanted to beta test our products for us before they came out. By showing the Marketing team that people were proactively volunteering to help us test and build our websites, we were able to put together a dedicated Test Group of our customers.
In exchange for early (and sometimes discounted access) to our products and courses, we would get early feedback from our users. Again, this was invaluable in not only prioritizing features, finding design and usability issues but also in constructing a meaningful product backlog to work off of after our launch was complete.
4. Responding to change – It’s funny, but the very act of following a framework, like Scrum, too religiously violates one of the core principles of Agile.
So maybe in my desire to impose “our way” of doing things upon our new company, I was being somewhat hypocritical.
Instead of trying to stick too closely to a plan or a framework, I should’ve rolled with the punches from the beginning.
And that’s the biggest lesson I learned here – you can reap all of the benefits of an agile product development approach without following the rules to the letter. It’s the spirit of the manifesto that counts and not the precise implementation.
The Results
Things have turned out better than I could’ve imagined!
We still operate on tight launch timelines, which tend to screw with our overall sprint cycles (e.g. you won’t see us on 3 week cycles throughout the year, we’ll break it into 5 weeks for a launch, back to 2 weeks for refactoring, then back to 3 week sprints until the next launch). But our products have improved dramatically.
Our customer retention rate went up by 15% in the first year.
Our relationship with the other departments has dramatically improved. We’re all speaking the same language now, which is the language of our customers. Prioritizing products and features has become a breeze, especially now that we have real customers providing us with feedback all the time.
And best of all, the entire team is much happier and satisfied with their work. We’re able to direct our own production efforts now and we’re also able to provide much more input into our user’s experience on our sites.
So my advice to anyone struggling with similar issues – don’t try to force something into your company that doesn’t quite fit. Every organization is unique and has circumstances beyond your control. Observe, adapt and most importantly, keep it about your customers and I believe that only good things will follow.
Wayne
—–
Wayne Mulligan founded TickerHound.com – a white label Q&A platform for investors that boasted NASDAQ as a client. TickerHound was acquired last year by Tycoon Publishing, an online educator for independent investors. At Tycoon, Wayne oversees a team of talented designers and developers who are trying to change how individuals manage their money. You can find more of Wayne’s thoughts on his blog: http://www.experienceblogger.com.