I have recently been embracing the change from traditional waterfall product development to an Agile framework. In the past, I have been wary of Agile, especially for enterprise products, but as I gained a better understanding of the Agile principles, I started liking it more. There are still caveats for using Agile methods and success of Agile process depends heavily on the staff managing the framework, but I am starting to see why Agile development is so appealing.
From a Product Management perspective, one of the most appealing aspects of Agile is how requirements documentation works. For many years, I spent a ridiculous amount of time creating requirements docs (primarily MRDs, but also some PRDs and TDDs). The reason for this is that MRDs have a broad audience. The same MRD that Developers and QA Engineers use to build their functional requirements also has to be read, understood, and digested by folks from the Sales, Support, Pro-Serv, and Marketing.
That means MRDs are chock full of data which can include some or all of the following topics:
- Business Case
- Revenue Model
- Competitive Analysis
- Market Analysis
- Feature Descriptions
- Feature Design
- Staffing Requirements
- and the kitchen sink
All of this data makes for a large and cumbersome document, both to create and to absorb. On more than one occassion, I have had to chase down folks who insisted on getting a copy of the MRD (and who promised to provide feedback), only to find that they had not even read it 3 weeks after I sent it to them (and sent out multiple reminders).
Ugh. A lot of work with little or no benefit.
What I like about Agile development is that most of the extra “fluff” is moved out of the requirements process. It’s usually still there in the release cycle, but it’s someplace else, like a hallway conversation with your CEO, or a presentation to the exec team, joining the Sales/Support team’s weekly staff call, or an on-going discussion with your manager. Those are the folks that care about the fluff part of requirements docs.
When you work with the Dev team, for the most part, they don’t care about the specifics around revenue, competitor analysis, or anything else not directly related to helping them write the code. That’s not to say they don’t care at all. Revenue should be very important to ALL employees, but as information that Developers need to do their jobs, those things just don’t add much value.
So, instead of a 30-page MRD, I like the 5-10 page release specs doc. I focus on what is in the release and what it should do. I usually add a bit about what problem it solves or how it would be useful so that the Dev team can use that information to better understand the requirement, but not much more than that.
To be honest, the short-n-sweet option doesn’t always work out as well as I would hope. It still requires having some lengthy discussions with Developers to iron out issues, but I’d have to do that with the big MRD, too, so why not save time and not write it, and then focus on getting the software built and into the hands of testers and users?
Less work for the Product Manager, which means more time to get out into the field, spend time with customers and partners, and listen to folks explain how I can help them with my product. Everybody wins!