Agile Waterfall

18 April 2014


No method, either Waterfall or Scrum, is perfect. Each has its own pros and cons. Complete transformation from Waterfall to Agile is very difficult, as it involves a drastic change of mind-set and culture on the part of the individuals involved.

It is easier to apply minute changes rather than huge ones, so I am proposing a middle path, one where instead of drastic moves we are looking at small changes that nonetheless lead toward Agile. Whatever problems are in Waterfall can be effectively resolved by applying Scrum partially.
  1. Increase the team's interaction with the client/customer so they can understand the requirements clearly.
  2. Ask the customer for priorities while gathering requirements, and focus only on those requirements to elicit more details.
  3. You can form multiple teams with developers and QA, and distribute these prioritized requirements across these teams, who can convert them into appropriate user stories.
  4. Involve team members in identifying the tasks and estimate the efforts required to complete the prioritized user stories to arrive at the scheduled date of delivery.
  5. Negotiate with the customer on the scheduled date of delivery; if it is very long, then you can go for further prioritization to ensure that the customer is happy.
  6. Deliver the working software to the customer for their review/acceptance on the correct delivery date.
  7. You can plan for team meetings immediately after delivery, so you and the team can engage in retrospection that can lead to ongoing improvements.
  8. Repeat steps 2 through 8.



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1.7 (3 ratings)

Comments

Zach Bonaker, CSP,CSM,CSPO, 4/18/2014 11:52:10 AM
Some great points are made here - and I think this is a rather juicy topic to discuss! I'll add a few comments and thoughts from my perspective:

1. I've had both success and failure in adopting a "slow, small change" approach to Agile transformation. In some cases, this approach has led to a comfort zone that the organization never escaped from... there was never a desire to reach "Scrum" because things were "good enough."

That's actually something I love about the "big bang" transition... it exposes bottlenecks, issues, flaws, etc. instantly and creates an easy way to prioritize where effort should be directed.

2. I don't agree with your comment: "Whatever problems are in waterfall can be effectively resolved by applying Scrum partially." In fact, I think this is a dangerous precedent. I don't have experience or empiric data to suggest that "partial Scrum" is better than "complete waterfall."

3. For step #3, I am a concerned over the idea of writing user stories from requirements. You run a great risk of misunderstanding the value/story by trying to translate a story from something that isn't the "core" of what a user story represents.

Not to say I disagree with your approach, just that it has many interesting aspects to discuss and consider!
Carlos Monroy Nieblas, CSM, 4/19/2014 4:35:16 PM
Proposing an organizational change is always a challenge as it requires adaptation and sometimes swim against the tide of established habits that will require commitment for all the team members. I’ve been witness of experiments in different organizations trying to modify the work methodology and in some cases they were not successful due the lack of knowledge of the skills of the team members, incorrect or inexistant communication (when the goal and objectives are not known by the team makes it unlikely that they will be achieved), and continuous evaluation of the success or failure on the implementation of those changes.

The article’s proposal to consider Scrum as a Holy Grail that can solve all the troubles (even when it is partially implemented) is a dangerous misconception that can set expectations that may not be achieved.
Charlie Pfeiffer, CSP,CSM,CSPO, 4/21/2014 5:33:05 PM
My immediate response to this is, "There are no shortcuts".

Many Waterfall organizations have strict controls for ALL requirements to be documented AND signed off by stakeholders/management before development can begin. In these organizations there is no way to piece together prioritized items for development while requirements are being documented.

Another issue I see is the client/customer is not only being left out of the process, but they are being "hidden" from the process. One of the most valuable aspects of Agile is the transparency it provides the customers. Keeping them in the dark is not transparent.

I know it is not easy to adopt organizational change, but in the end the entire organization has to support the conversion to Agile, or it will fail. Introducing "workarounds" to the Agile process only delays the inevitable, which is either the organization will be behind the change, or they won't. Again, there are no shortcuts.

That said, I do like the idea of trying to find ways for organizations to adopt Agile in a "phased" approach. I would just prefer to make sure all departments are involved to make sure they buy-in to the processes, and understand the benefits they will gain from the changes.

You must Login or Signup to comment.