Guest Author: Jay Fox
Big week! The company I work for, The Deal (www.thedeal.com), launched a product that I have been working on for nearly a year that creates LinkedIn-like functionality for people in the deal-making space using our proprietary data.
Not only is this the biggest new product launch for the company in 5 years, but it represents our first effort in transitioning from waterfall to agile development process. I am extremely impressed with our development team in making this transition – and while we have a long ways to go – we are operating much more efficiently than before.
How the transition has worked to our benefit…
Pre-agile: Long, detailed (read: boring), spec docs taking months to write were handed over to dev, who would take months to write code, and then business side would only see the product when it was in test, right before the given launch date. This caused a lot of frustration for the business side when the envisioned product was not achieved, and even more frustration for the dev side when deadlines were missed.
Post-agile: No spec docs, just weekly product development meetings in which daily scrums between business and dev side were summed up and discussed. I used wireframes to communicate design intent, and people in the meeting could give real-time feedback.
Pre-agile: Virtual Chinese wall existed between dev and business side with communication only happening in formal setting once a week at company-wide meetings. Biz side usually think one thing while dev side thinks another. Usually we wouldn’t find out what the other side was thinking until it was too late and deadlines has passed…
Post-agile: Frequent communication with dev team both in weekly formal setting and in daily chats by the water cooler. Much more open atmosphere of tossing ideas back and forth about design, UI, UX, and dev challenges. Collaboration is the name of the game. I believe this is the sole reason the product that launches tomorrow is meeting its deadline.
Pre-agile: Clients only got involved once the product or feature "went live." Feedback then went into an endless ticket cycle that was never implemented.
Post-agile: Dev set up a client testing site that allowed us to "beta" the new product early on in the development cycle. I even showed clients mock-ups before the testing site was available. This helped define what features we needed to be "launch ready". Plus, even after we launch tomorrow, we will still iterate frequently based on feedback. No long ticket process.
Here’s a screenshot of the main tool:
A few things we are still working out…
- How can we be truly agile when a large part of our development is outsourced to a team in India? Going back and forth on tweaks following client input was difficult and often ended up in a game of telephone where what was communicated wasn’t what we ended up getting. This process ultimately didn’t affect the launch date but still wasn’t as smooth as I would have liked. Would appreciate folks sharing thoughts or similar experiences in the comments.
- I had a hard time getting client input throughout – pinning them down was tough and so iterating through input was not easy. Ultimately, we will launch the product, then get client input and decide if we’ve got an MVP or if we need to go back to the drawing board. I suppose this is a bastardized version of agile 🙂
- We were operating without a UX design team – it was really me, the project manager, and the developer, none of which have hard UX experience. Any thoughts? Again, please share in the comments.
Thanks & would love to hear what you think!
Guest Author Bio
Jay Fox has been involved in financial and legal industry product development for nearly 5 years and has recently assumed the role of product director at The Deal (www.thedeal.com). The Deal is a media company owned by The Street (of Jim Cramer fame) that reports on M&A, Private Equity, regulatory issues, and restructuring. Follow Jay on twitter @FoxNY1 or on LinkedIn at http://lnkd.in/c2we8c.
The Product Guy 
Hi Jay – thanks for the insight into the transition to Agile. A couple comments on the challenges you’re facing and how I’ve seen some success.
First, the challenge of distributed teams – it doesn’t really matter if they’re in India or across the country. Not being able to talk face-to-face makes it a challenge. This is where a tool can be a huge help. I would look for something that allows you to collaborate on your user stories, designs, mockups, etc., but then traps that collaboration to be used in context later on. It also helps you track decisions made and questions answered. There’s a lot of free products out there to use for this.
Getting customers to be a part of validation is always a lot harder than it should be. I have found that selling the value of their feedback works a lot better than trying to give them free stuff (not that that doesn’t help). I talk to my customers about how we have so much more TO DO than what we CAN DO and that I want to make sure we’re solving their biggest problems. Having your customer segmentation, user and buyer persona’s, and a good elevator pitch ready always helps. Make sure you’re talking to the right people for the stage of validation you’re in. At the end of the day, if they don’t participate in this round, you’ve built the relationships for next time.
Lastly, the UX debate. I personally think it’s extremely important to have UX integrated with product management. However, if that’s not possible, I would recommend bringing in a contractor or agency to help out. If that’s not possible, you should at least create a style guide to help make sure you’re staying consistent – again, use an agency for this if needed. UX/UI will be very dependent on what you’re building in (and what you’re building), but we all know that a crappy solution with a great UI and experience will often trump a great solution with a crappy UI. Obviously you want a great solution with a great experience.
LikeLike
Thank for the feedback, Jeremy! I am totally going to rip off the line about having more to do than we can do next time I’m with client and wanting to solve their biggest problems. I think that’s a great way to frame it.
Re: development, We use JIRA to track the work done in India but it’s mostly technical jargon I don’t understand 🙂 I suppose I can and should push to make it a more transparent conversation.
Re: UX, I love thinking about this and working on it but would surely get a lot out of someone who does it professionally. I think your comment about a good UI with a minimal solution trumping a good solution with a bad UI may be true in the consumer world, but I’m not so sure for enterprise. I’ve seen so many shitty UIs that people pay a but load of money for because they have valuable information. I think enterprise solutions are trending towards improved UIs but it’s never been a focus. Not that it shouldn’t be 🙂
LikeLike