Blog

When using the waterfall methodology to manage projects, each phase (Planning, Analysis, Design, Development, Testing, Deployment) must be fully completed before the next can begin. Everyone can call these phases something different, but essentially it’s when progress is seen as flowing steadily downwards. This has worked for so long and continues to work for some, but why not try something new? Agile, perhaps? It’s been around for a while, but lately, it’s the methodology of choice and it's gaining momentum. Agile is a time-boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end of the engagement.

So, how does it work?

• The customer is fully engaged throughout the project and is called the "Product Owner."  The Product Owner is responsible for declaring which items are the most important to the business and prioritizes the list by putting the higher priority items first.
• The Development Team is responsible for selecting the amount of work they feel they can implement within a sprint (usually 2-4 weeks). The team “pulls” work from the Product Backlog and moves the items to the Sprint Backlog. The customer must approve the list prior to starting development.
• Each of the work items in the sprint backlog must be detailed enough to include the tasks required to complete the user story, an identified owner, and an identified peer reviewer. 

• Every day at the same time (usually first thing in the morning), the Scrum Master, Developers, and Product Owner spend a total of 15 minutes inspecting their progress toward the sprint goal, the planned work for the current day, and any roadblocks they face. The Scrum Master assists the team in meeting their sprint goals by facilitating all communication and coordination across the teams. Topics that require additional attention may be discussed by whoever is interested in every team member has reported. 

• At the end of the sprint, the Development Team will present their completed user stories and discuss items not completed. The team presents to the Product Owner for acceptance, but other stakeholders may also attend. This is usually in the form of a live demo. The team should plan a few hours for this meeting at the end of each sprint. 

• Each sprint ends with a sprint retrospective. At this meeting, the team discusses the process, tools, and interactions and identifies ways to improve the process for future sprints. This usually occurs on the last day of the sprint and can last up to one hour.

At first, I didn’t think this could work. I kept asking the same questions over and over in my head. How could we run a project any differently? Will the customer really commit to being so involved with the project? Who wants to participate in a daily project call when it’s pulling teeth to get a weekly status call going?  Heck, would the project team even find value in having daily scrum calls? Can we rely on the project team to work in sprints? Let’s be real here, no one likes change. All of my doubts were coming from a place of comfort in using the standard SDLC methodology. Deep down, I knew I’d have to get on board. Sometimes change is necessary, but the shift in mindset is the part that can be really tough to grasp.

Now, I have to expect change throughout the project and respond accordingly while adapting our processes and practices as necessary. Once you begin to wrap your head around this concept of running projects, it actually starts to make sense. This method makes it ok to change scope. I mean, what? Yup, that’s right. There is an opportunity to constantly refine and reprioritize the overall product backlog. New or changed backlog items can be planned for the next iteration, providing the opportunity to introduce changes within a few weeks. This is a customer’s dream come true. Not to mention a dream for the project manager who is trying to stay on schedule and within budget.

In the end, we really need to understand the pros and cons of each to determine which method is best.

Waterfall Approach

Pros

• Client knows what to expect at the beginning of the project.
• Minimal client involvement since once requirements are signed off, team can just run with the next phases.
• Better time management for project team members because they aren’t involved in every phase so helps with resource management.

Cons

• Relies heavily on initial project requirements which increases risk
• Once one phase of the project is completed, can’t go back to make changes
• Changes in scope usually has a negative impact on budget and schedule
• Doesn’t allow flexibility for scope changes

Agile Approach

Pros

• Allows for change in scope with minimal impact to project (more flexibility).
• Increases customer engagement and satisfaction because iterations allow for immediate feedback.
• Increases transparency because team meets daily to discuss status and roadblocks.
• Increase in quality assurance because defects/bugs can be caught early.

Cons

• Could lead to lack of documentation.
• Heavily involvement is necessary for the customer and if the customer cannot devote someone to this project full time, this can lead to poor results and slow down the progression of the project.

If you’re on the edge of deciding whether this is the next best thing, definitely take some time to consider the positives that can come out of running projects agile.  Not only will it benefit your company, but your customer as well. In the next article in this series, I’ll talk about my actual experience with managing a project using the Scrum methodology; so, stay tuned!