Can We Strike a Balance Between Agile and Waterfall Software Development?

Posted on January 18th, 2013 by Shannon Lewis

Quality, Functionality and Time

These three words were drilled into my head as a green Product Manager. I was told you could have two of the three in a product release, but one always had to be “sacrificed.” Because I worked for a product company that announced release dates well in advance, time was usually fixed. So either quality or functionality was put on the cutting block. Luckily, I was working for a quality-conscious company at the time, so it was usually functionality that dropped. As a Product Manager, I was at the end of the “bullwhip” on that, always having to explain why a feature didn’t make it into a release. This approach just didn’t seem right to me. In a 6-12 month development cycle, priorities change over time, so sometimes what we built didn’t meet expectations down the road.

Along came agile development and a “no-wine-before-it's-time” development philosophy. Was this a perfect world where we could have quality, functionality and time? In a sense, yes, but not exactly.

“Time” is usually less of a factor in agile environments, because you keep iterating until the team feels the product is ready to be released. Having the product in a “testable state” at any time helps to reduce the time pressure. In an agile world, you wouldn’t announce a release date of a product months ahead of time. Instead, you’d be more likely to announce weeks ahead of time.

Hybrid Approach

When starting our company, Mike and I had to figure out what felt right for us. Since we’re a consulting company, we develop software for other organizations, rather than release our own products. This presents several challenges:
  1. Budget is usually fixed at project outset, and funding is often available only during the current fiscal year.
  2. We need to manage both our own team and the stakeholders of the client team on a day-to-day basis.
  3. We aren’t always familiar with our clients’ organizational structure and culture at project outset, so unpredictable delays and challenges usually come up.

We never had a major discussion about the merits of waterfall vs. agile, but fortunately, we were both of the same mindset and adopted a hybrid approach to development.

Panoptic Development Development Process

We implemented parts from each that felt right to us:
  • Some upfront planning, like building design wireframes and user stories
  • Short one- or two-week development iterations
  • Application always in a state that can be tested
  • Constant evaluation of features and project goals


As a Project Manager, I struggle with some aspects of the hybrid approach, such as:
  • Educating clients - Many of our clients have never been through a software development process before. To mitigate this, we have included information about our hybrid process in all our proposals, and we always set expectations early in the project. Weekly client meetings also help.
  • No detailed product requirements document - As a “traditionally” trained product manager of the 90’s, I am used to very detailed project requirements documents, approved by all project stakeholders. This is just not practical in our line of work, as the client’s high-level idea of what they want and what they actually need often changes. As the client actually sees the project unfold, priorities change, functionality is tweaked, budgets change, and so on. We try to strike a compromise by having requirements mirror the complexity of the project, but we always maintain the dialogue to adjust as needed.
  • The need for a rapid testing/feedback cycle - Clients often have difficulty keeping up with agile development’s rapid iteration and testing/feedback cycle. This can put the project at risk, since the longer we go without feedback, the harder it is to recover if we aren’t developing what the client expects. We sometimes mitigate this by slowing development velocity down, so client testing can catch up.
  • The desire for an exact launch date - Many clients who want an exact launch date once a contract is signed. This is probably what I struggle with the most. It is very difficult to give an accurate launch date at the start of a project because:
    • Client projects are very fluid with changes in requirements
    • Its difficult to determine the client’s ability to adhere to testing/feedback schedules. Because we develop in rapid interactions, clients are not always able to “keep up” with testing and feedback. This can cause delays in the project.
    • Sometimes a client’s internal processes, such as security audits or internal review boards, delay progress and its difficult to determine the impact of this early on in the project.

There is no perfect world. The waterfall approach has issues, the agile approach has issues, and our hybrid approach has issues. Tweet: There is no perfect world: the waterfall approach has issues, the agile approach has issues. Every organization has to determine what approach works best for their culture, their clients and their employees. For us, the hybrid approach works well, and takes some pressure off the “quality, functionality and time” dilemma.

To learn more about our development process, download our ebook Soup to Nuts: Taking an Application Idea to Reality or check out our video series Demystifying the Software Development Process.



subscribe   RSS Feed
subscribe   Newsletter Signup


Published: Jan. 18, 2013

Author: Shannon Lewis


Next: LA RubyConf Presentation: Python for Ruby Programmers

Previous: We would like to give a great big Panoptic Welcome to Chris Bloom.


#agile, application balance budget budgets consulting design development, development,Project fixed form from idea Management, of project proposals risk security software team video waterfall #waterfall,#ProjectManagement,#consulting wireframes work working

Featured Articles

Comments powered by Disqus
Start a Project
We're an experienced team, we love what we do, and it shows.

A successful application is the outcome of a well-conceived, iterative, and rapidly-executed plan.