Balance Between Agile and Waterfall Software Development

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

# 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.

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

# Challenges

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. 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. 

Original Source : Shannon Lewis - Via Panoptic Development