In the IT/software development industry, a project and its level of success is only as good as its planning phase. We have always put a lot of emphasis on the planning phase of our projects; it’s the 'Method' in MethodFactory. There is something to those clichés about planning, like, “measure twice, cut once;” “plan the work and work the plan;” and “ready, aim, fire.” We’ve heard so many stories of clients who were missing the upfront planning and the consensus needed at the beginning of a project, instead taking a ready, fire, aim approach - losing a lot of time and money circling back to fix a project or start it over from scratch because it was too broken. We know firsthand that if we “begin with the end in mind,” and follow the appropriate planning steps supported by sound documentation, we will get to the defined end goal on-time, on-spec, and within budget.
Applying Waterfall Planning to Agile
When it comes to planning, our philosophy is that whether you employ the traditional Waterfall, or rapidly growing Agile approach to software development, planning still reigns supreme in terms of priorities.
Waterfall is the traditional and more conservative method characterized by its blueprint-like preplanning, including comprehensive analysis, distinct goal setting, and thorough documentation. It is defined as linear, sequential and predictable. In contrast,Agile is an iterative, incremental approach in which the project progresses through a series of 2-4 week “sprints,” focusing more on the hands-on development and less on the analysis and documentation prior to getting there.
Over the years, we have worked in the traditional Waterfall method. Now, we are doing more and more Agile-based projects for mature systems, building on top of existing systems, as well as employing it in new development. With our acquired knowledge and lessons learned, we have discovered that applying the planning discipline/structure of Waterfall to the sprints of Agile is extremely beneficial and sometimes necessary. While both methods are explicitly different, in either case, we want to know where we’re going without having to guess along the way, even and especially in the sprint environment of Agile. The planning up front allows us to gauge the project in progress; informing us if we need to make incremental adjustments on our way to our destination.
Our Planning Strategy
A big piece of our envisioning and planning phase is the Business Requirements Document (BRD), born out of a series of interviews and information gathering workshops at the onset of the project. This document paints a high-level/macro picture of where we want to end up. It frames the project by calling out functional elements (for example: it is going to be B2B, eCommerce with a content management system and will include 20 templates, a dealer locator, shopping cart, etc.) The information gathered for this document is enough to deliver a preliminary development estimate and set the project in motion.
From there, we create the Functional Design Spec (FDS); detailed documentation of all functionality contained in the BRD. The FDS gives specific details and illustrated prototypes of varying degrees (where the definition of the dealer locator might be one page in the BRD, it could be a three page description in the FDS, and includes a prototype). Finally, we deliver a Technical Design Spec (TDS), which spells out the technology we’re going to use to deliver, and supports what is defined in the previous two documents. It contains the technical particulars, hardware and hosting environments. These three documents allow for strategic development based on thorough information gathering and planning; whether in Agile sprints or the traditional Waterfall method.
The Importance of Prototypes
The prototypes (typically included in the Functional Design Spec) serve as a visual illustration of the features and functionality described in the document. Even more useful is the use of working ASP.NET prototypes. These are active wireframes that you can actually use by clicking through a site or interface to experience the results firsthand. The click-through path and IA follows a script and gives investors/stakeholders an opportunity to make necessary adjustments before it goes into the development phase, as it makes the development process smoother and less likely to get derailed. We include working prototypes and active wire frames in our planning, because it can save time and money in the long run and help promote the defined experience and outcomes.
MethodFactory’s commitment to strong planning has enabled us to deliver quality work, on-time, within budget and per spec, consistently over the years - no matter the client or the industry. An investment in planning, whether with us or on your own, is what sets the stage for a successful project and a greater return on your investment.