If It Ain’t Broke, Don’t Fix It?

Agile Benefits

24 March 2014


If it ain't broke, don't fix it -- when Waterfall is working, then why Agile? Well, change is the only constant. If we don't embrace change, then we are outdated. This is applicable to any business/organization or individual. So why wait till something breaks, when one can be proactive and look for things that make life easier?

Waterfall technology is a trusted friend for project managers. A seasoned project manager can be so well versed in the life cycle that even in his sleep, he can tell the status of his project(s). Waterfall is a traditional software development process that comes with a standard set of phases during which projects are executed. The life cycle contains Requirements, Design, Development, Testing, and Release phases, and there is a solid "exit gate" between each phase. The process is very linear.

Agile is based on iterative development. It focuses more on delivering business value functionalities (user stories) in logical chunks, using "sprints."

Waterfall:
fig-1.jpg

Agile:
fig-2.jpg

Let's see how some key activities are dealt in Waterfall versus Agile.

Waterfall Agile
Scope/business requirements are finalized at the beginning of the project. User stories and epics are prioritized in the product backlog; business value functionalities are chunked into small and independent user stories. Entire scope is detailed in the product log as epics/user stories.
All requirements are documented at project level based on the identified scope at one go. Detailed requirements are done based on the user stories that are included in the current sprint. Instead of working on all requirements at the project level, they are captured at the sprint level for further prioritization and implementation.
There are strict phase exits when moving from one phase to the next phase. Each sprint covers requirements, development, and testing activities for the identified user stories within a sprint.
Less flexibility to change agreed/signed-off scope. Only prioritized user stories will go into a particular sprint(s). Entire team (product owner, ScrumMaster, and team) will discuss the business value and decide which one can go into next sprint. In case of any changes, product backlog will be reprioritized accordingly.

Also note: User stories picked up in the current sprint are as good as "locked" -- these cannot be changed in the middle of the sprint.
Any new changes that were not part of the initial project scope are treated as change requests; any new effort is considered/treated as "scope creep." No change request process is required; any new functionality/items will be added to the product backlog and reviewed for prioritization. There is flexibility in shuffling the user stories between sprints. In case business has a critical item to go, then earlier planned user stories will be reviewed again to make the hot item take precedence.
Additional planning/source onboarding is done in case of significant new changes. Teams will prioritize the user stories and take them into a particular sprint based on the team's velocity. In case new changes are identified during a sprint, they are added back into product backlog for reprioritization.
Once scope is frozen, the team will work on the items for years (depending upon the project duration). Even if business priorities change, in the interim, the project team still continues working on initially agreed-upon scope. User stories will move up and down in the product backlog based on the business value. Items that were on top in the backlog 3 months ago may move down, giving place to another prioritized user story.
Planning takes place for the whole project at the beginning Sprint-level planning; plan for user stories with immediate business value to go in the sprint
All key resources may not be available while capturing detailed requirements at project level. For example, developers and QA team members may not be involved during requirements elicitation/FSD documentation time (tech lead is available). If any requirement is missed, then they are brought up during core development or the testing phases. Sometimes, these may end up as change requests/scope creep (missed requirements). Each sprint has key resources involved: product owner (business), BA, dev and QA teams. Sprint planning, user story prioritization, and estimation are done as a team.
Not all team members are onboarded at the beginning of the project. For example, during the requirements documentation phase, typically developers and/or QA testers are not onboarded; even peer groups are brought into the picture as needed in the middle of the project. Key "sprint team" is onboarded for the selected user stories: BA, dev, and testers; team is intact throughout the sprint duration. Team participates in all discussions related to the identified sprint and is made accountable for the deliverables.
If the project is lengthy, there's a chance of resources leaving the project and new team coming into picture. Additional effort is needed to KT/onboard new team members at the project level and/or at the phase level. Dedicated sprint team is identified and continued throughout the sprint. In case of any resource replacements, this will be taken care in future sprints (but not in the middle of the current sprint).
Long wait period for the production releases for business to use the expected functionality; duration may be a challenge for business. If functionality is expected by business in 3 months, technically, it may take more than 6 months for production release (considering the process involved). Small, packageable, independent user stories will be released in production. Faster delivery only of user stories with identified business value.
Loads of documentation is created across various phases. Although customization is done on some projects, all in all, too much documentation is produced. Tailored documentation, customized only for the sprint; documentation will be considered as one of the deliverables in a sprint, if required, after thorough discussion.
It's challenging to identify which phase will end up as an issue impacting the entire project release. Sometimes this may result in project abandonment or cancelation. Success or failure is defined at the sprint level; in case of any failures in the current sprint, impacts are known immediately. Successful completion of planned sprint(s) is an indication of delivery of identified user stories.
As you track the risks, if any unexpected showstopper risk is identified at the tail end of the project (close to the release), then it puts the entire release at risk. User stories/functionality delivered in small sprints; in case of any showstopper, future sprints will be planned after the mitigation is discussed. In case of a risk in the middle of the sprint, necessary decisions will be taken by the sprint team, based on project needs, in consultation with the product owner (business).
Business process change or priority change may impact projects to deliver "assumed" benefits quickly/at an expected rate of speed. Business priority is considered in the product backlog, and user stories are delivered in the order of priority.


Remember, be it an IT group in a service-oriented company or an IT-dominated product development company, everyone's focus is to deliver faster to compete with competitors. Trying the Agile method to deliver projects much faster -- with proper planning -- will give you a boost as an individual and as a company, to survive longer in the field.

Don't wait next time until something breaks. Proactiveness -- not reactiveness -- is the new mantra!


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: 0 (0 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.