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.