Skip to main content

Tag: Waterfall


Agifalling – verb

  1. A description of a hybrid waterfall/Agile project in the throes of failing. “Oh no, we’re agifalling,” or “I’ve agifallen and I can’t get up.”

Many of you may have encountered what’s become known as a ‘hybrid’ project. It combines waterfall and Agile techniques to deliver software. The principle of combining the two approaches seems to have evolved from dissatisfaction with both techniques: waterfall is perceived as too rigid and Agile is perceived as not rigid enough. Although many people have had success with combining the two practices, a merely bad project with either technique can turn into a disaster when waterfall and Agile are combined without sufficient understanding or caution. If delivery is late using waterfall, delivery will completely fail on a bad hybrid project. If developers find it hard to code from traditional requirement specifications, they’ll be completely confused on a bad hybrid project. If the customer balked at the costs of doing waterfall, they’re in for a nasty surprise on a bad hybrid project.

So how does a bad hybrid project start and what does it look like? Bad hybrid projects usually begin with a poor grasp of both waterfall and Agile, and to add insult to injury, the waterfall components are included because no one trusts anyone enough to let the teams manage themselves, and Agile gets adopted because someone read a blog that said Agile would make developers code faster.
The project is consequently split into different practices depending on your role. The developers get the most Agile work. This usually involves two weeks of sprints and daily stand-ups but there’s no product owner and zero contact with the customer. The project manager’s job doesn’t change – they move around the tasks on their Gantt chart until they have everything in sequential order in much the same way as they did with waterfall, only it’s relabelled “Agile” (or “iterative”).

And what becomes of the BA? The BA is caught in the middle between delivering requirements on a waterfall-type schedule while trying to keep up with an Agile development team. In an effort to cover the bases, a BA is usually faced with producing more documentation than they would have delivered on a waterfall project.

A bad hybrid project can result in a BA writing use cases and then extrapolating user stories from the use cases for the developers. Or, distrustful of user stories (not to mention Kanban boards) and thinking use cases are too hard, the project decides that all of their requirement elicitation woes will be cured by producing extremely detailed screen prototypes that take weeks to produce (not to mention 10 to 30 pages of documentation per screen) but contain zero business context.

Although most BAs understand that the job is all about communicating the requirements in a way that allows the requirements to be understood, BAs on hybrid projects can find that they can’t keep up with delivering requirements in a way that will keep pace with a sprint. Usually a BA on these types of projects is pushed to “just make a start” without any idea of the overall features required. This is based on the assumption that Agile will help the overall goals and features naturally make themselves known as an outcome of the process. If the team has been tasked with delivering hi-fi screen prototypes as their sole source of requirements then the opposite is true. As super-detailed prototypes are developed and people are sidetracked by fonts and radio buttons, the overall design and purpose of the application seems to become more obscure.

The ensuing pressure and panic to define requirements using nothing but screen prototypes coupled with trying to keep pace with the development team usually results in a project that is in a constant state of anxiety. Keeping to schedule somehow turns into doing whatever the customer wants without question, even if what the customer wants is a very bad idea, because it’s far easier just to say yes to everything and shove the wants down the line. Any problems are pushed to the development team, which ends up with an ever-increasing product backlog and sprints that never get out of testing.

Without the additional Agile practices of regularly reflecting on the work done to date and adjusting the approach as needed, all that happens is everyone wearily traipses off to the daily stand-up so they can be harangued by the project manager about why the schedule is slipping.

What can you do if you’re a BA on a bad hybrid project?

Firstly, it’s going to depend on where you are on the project. If it’s already agifalling and the developers are drowning in sprints that never seem to deliver then it may already be too late. You can try suggesting to the project manager that it’s time to limit the requests from the customer and prioritise the product backlog. It’s also probably time to get an idea of the overall feature set to help sort out the backlog. This won’t make you popular since people cling to the notion that Agile is about accepting any and all changes at any stage, but there’s no way you’re ever going to end at the rate you’re going.

You could try talking to the project manager about Agile being a collaboration between the customer and the development team, which means that it would be desirable if the customer could be on site with the developers and the business analyst(s) for a number of hours per week to allow direct and unhindered communication. And if that’s not possible, at least arrange regular conference calls and/or Skype sessions. You can also look at going back to the prototypes giving the development team the most trouble and ensure that you do a quick user story or state a business goal for each screen, showing how the various screens relate to each other. This will at least give the developers some context.

If the idea of running a hybrid project is being discussed but has yet to start then you may have an opportunity to help the project manager avoid the problems that will rapidly appear. This will depend on how comfortable the project manager is with trying new techniques. However, if a hybrid project is pitched from the perspective of making their lives easier, a BA may be able to offer tips and tricks on how to keep the requirements process running in a way that actually focuses on delivering value for the customer (identifying business goals/needs, etc.) while tracking with the developers fortnightly sprint cycle. The project manager may be deeply uncomfortable with most Agile techniques (except for the ones that purportedly make developers code faster) but it may be an opportunity for a BA to design a sneaky template and wedge in a user story or two anyway. No one ever said that a user story had to be on a sticky note.

For example, you could add a small paragraph at the top of the screen prototype (if you’ve been forced down that path) that outlines the goal and how the customer envisions using the screen from a business perspective.

If you’re going down the path of writing use cases first and then extrapolating user stories from the use cases, you can definitely save time by factoring in the user stories at the start. Make them part of the use case as an additional section. This is a little sacrilegious but you’re on a bad hybrid project so any thoughts of using best practice or standard techniques have already gone out the window. Do whatever you can to save everyone time further down the track.

My final thoughts on the hybrid project is that they’ve emerged as yet another ICT attempt to find the silver bullet that will make the extremely hard software development stuff happen as if by a miracle. All of the techniques, whether plan driven or change driven, tend to be successful with the right team of people, the right attitude and a huge dose of pragmatism.

A bad project is a bad project no matter what technique, practice or methodology is used. But that’s a different article.

Don’t forget to leave your comments below.

Agile Misconceptions: What Agile is Not


Over the course of my career in software development, I have had the fortune of working in a wide variety of companies employing radically different approaches to the software development life-cycle (SDLC). Some strictly stuck to traditional Water Fall. Others called themselves “agile” but never actually bothered to adopt any agile framework, and were thus a blend of Water Fall and Agile—and all too often, not a successful blend either. Another strictly adopted a true agile methodology and decided that there was no need for a PMO since, as they put it, “we’re SCRUM.” Other companies used the same Scrum methodology but saw the value of having a PMO as well.

As I have closely followed discussions on Project Times (and other blog sites), I have noticed some discussions around Project Management methodologies that are fine in theory, but often seem divorced from real-world applications. You can often find arguments prefaced by statements such as “good project managers do X,” or “the PMBOK methods require Y,” or even “any experienced Scrum Master knows…”

After working in so many different environments, the most important lesson I learned was that a dash of humility goes a long way. In other words, no matter what framework is employed, most companies will adapt the theoretical suggestions of the framework to make it work for their needs. Project Managers who suffer from what I call “theoretical myopia” may fail to see the value in the adaptations the company has chosen. A strict enforcement of a theoretical framework, without regard to results, is sometimes just as harmful as not enforcing any framework or process at all.

Target audience

There are several types of readers for whom this article is intended. Some readers may currently work in Water Fall environments and may not have any experience with agile. Others may work in companies that claim to be agile, but really are not. And a few others may work in true agile environments that strictly follow the guidelines provided by whoever trained them in that framework, and don’t realize that there are “many ways to skin a cat.”

Let’s answer the question: “What is agile?”

The simplest explanation is that it is an approach to development based on iterative and incremental development. It is characterized by “adaptive planning,” “evolutionary development and delivery,” “time-boxed” iterations that result in incremental releases of functional product, and must provide rapid and flexible response to changes and discovery.

What exactly does this mean in the real world? One must remember that in the traditional “Water Fall” approach, the project flows through a series of steps or gates, and does not progress to the next step until the current one is complete. As an example, Requirements Gathering only begins once the Project Charter and Statement of Work (SOW) have been approved and signed off. Development begins only once the full set of requirements for the entire solution are gathered and approved by all stakeholders. A testing phase begins when the entire platform is developed. Because the development phase can last for many months, even years, before code is released, Project Managers may struggle to differentiate accurately between perceived progress (often reported as developers’ guesses of “percent complete”) and actual progress. This, in turn, results in unpleasant surprises when the delivery date looms two weeks away and the developers unexpectedly report that they still have eight weeks of work to perform!

What is the unsurprising response from senior management and the client? “Why didn’t we know we were behind schedule earlier?”

As a concrete example, let’s look at a real-world application, first for a Water Fall approach.

Think about developing a Web page, especially one designed to handle flight reservations. In a Water Fall approach, many weeks would be spent gathering comprehensive requirements for the entire page and every field on the page. This would include not just a list of fields but all the validation rules for every data point. Development would not begin until this comprehensive document was completed and then agreed upon by stakeholders.

Once the requirements were gathered and approved, development begins. The entire page (or even the entire website with all functionality) would then be created and tested. The page or site would then be released to the customer. This same process might be performed not only for the initial home page, but for every subsequent page in the site.

In many cases, the very first time the customer saw the direction the team had gone is when the page, or entire site even, is unveiled for the first time in a customer demo. This is when many customers balk in frustration because the released product did not accurately represent what they thought they had described. A crisis ensues because the client is very unhappy that functionality is unsatisfactory. From the development company’s perspective, changes to the design and implementation are quite difficult and very expensive.

I will make the comparison by examining the Agile framework I know best, which is Scrum. In Agile development, high-level ‘requirements’ are gathered during the project estimation phase, often when the project charter (or SOW) is being written. This information is gathered in “user stories” (or other equivalent) that describe how the major components are expected to behave, in terms of user experience. “As a customer, I want to be able to book a flight from one destination to another, for a range of dates.” Additional functionality may be captured in other stories, such as “Flight Cancellation,” “Reservation changes,” or “Choosing seating.”

Experienced teams are able to size the anticipated work by a measurement of complexity, rather than guessing how long it will take as a measure of time. Once work begins, refinement of requirements and behavior often occur with direct client involvement while development is underway, in an iterative process.

The Scrum approach breaks up the whole page into discreet areas of functionality and plans to work on each piece. The “Flight Reservation” page is broken into “Select an origination Airport,” “Select a Destination Airport,” “Select a range of origination dates,” “Indicate seating preferences,” etc. These become the User Stories, which are given acceptance criteria. The stories are then sized by complexity, tasked (with estimated hours for each small task), and planned out across short iterations. The stories and iteration plans are reviewed with direct client input. As development progresses, the customer sees the result every couple of weeks as each iteration (or “Sprint”) is completed. The customer then approves the output, or suggests changes that, being found early in the process, require minor “tweaks” instead of large architectural changes.

The frequency of these “demos” helps the customer participate in constant revision and modification, so each delivered piece of product is much more likely to satisfy the customer’s needs. Rework and associated cost is thus reduced. Client satisfaction is increased.

The benefits to Agile are quite simple to comprehend. The agile development cycle is designed to provide valuable functionality that accurately represents customer wishes on frequent deliveries, contrasting with the Water Fall approach, which often leaves customers waiting for long periods of time before they see the first benefit from their investments.

What agile is not

An Agile team is flexible, agile, and adaptable. The Agile team proactively elicits and documents the desired function with direct and frequent client involvement. It also frequently reviews the developed product with the client to verify that functionality meets client wishes. The talented development team is encouraged to meet those needs creatively. The project manager (Scrum Master) vigilantly monitors a daily “burn down chart” that allows the team to change direction swiftly in order to get the development back on track, in the case where circumstances have caused deviation from the plan or to quickly react to new information received.

Having laid out this basic understanding of what Agile is, and contrasting it with Water Fall, it is important to reiterate that the core concept of Agile is not a lack of process or a “watering down” of documentation! In my experience, this misunderstanding has been propagated by some managers who believe that Agile frameworks translate to nothing more than a loosening of control and reduction of analysis and planning. Improper implementation of an ill-defined concept of “Agile” can result in even graver problems arising. It has been my experience that “the cure was worse than the disease” in those cases.

I will dive into specific problematic areas in subsequent articles.

Don’t forget to leave your comments below.

Preventing a Trip Over the Waterfall When Introducing Agile Methods

BATimes_Feature_June7While I have reviewed some practices to consider when changing methodologies from traditional waterfall approaches to agile ones in Avoiding Speed Bumps when Adopting Agile Practices the input from a participant at one of the roundtable discussions at this year’s ProjectWorld Toronto inspired a few more.

The attendee indicated that his organization had embraced agile methods on a specific technology project but the issues and cost overruns they experienced stymied further attempts to adopt agile practices. 

Further discussion of the specifics of this case study yielded some more lessons.

  1. Start simple and expand complexity progressively (also known as “success begets success”) – in most organizations where agile methods have “stuck”. A pilot was done using a small (though highly visible) project that satisfied the 3 C’s of agile – collocation, collaboration & (open) communication.
  2. Leverage coaching assistance – It is very hard to manage your first agile project while simultaneously coaching the overall project organization (customer, stakeholders & team) through this process and philosophy change. If you happen to be the sole agile evangelist within your company, it may be worth justifying the costs of an outside coach to focus on the change aspects.
  3. Trust is mandatory – As with any other strategic change, commitment to the change means more than just focusing on the expected benefits while giving lip service to the costs. As I previously wrote in Trust – a critical success factor for successful agile projects, a lack of trust between key roles on agile projects can sometimes result in worse outcomes than on traditionally managed ones.
  4. Identify “appropriate usage” criteria for agile methods – Not all projects lend themselves to the use of agile approaches (just as not all projects can be successfully managed using waterfall approaches). Developing checklists or similar tools to help project managers decide whether a purely agile, a purely waterfall or a hybrid approach is best suited to their specific projects will help to reduce “square peg in round hole” situations.
  5. Don’t get hung up on specific methodologies – unless the nature of your projects exactly fits a particular agile methodology, it is better to focus on adopting (and adapting) principles rather than to blindly follow an off-the-shelf set of implementation practices. Fanaticism towards any specific agile “religion” is hardly likely to reward you with converts.

Through committed executive sponsorship, appropriate staffing and a “walk before you run” implementation approach, you can reduce the likelihood that an agile initiative will go over the waterfall!

Don’t forget to leave your comments below.

Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. ( which produces and implements Eclipse Project Portfolio Management software and professional services. Kiron has worked for over twelve years in the project management domain with a focus on technology and change management. He has setup and managed Project Management Offices (PMO) and has provided PPM consulting services to clients across multiple industries. Kiron served as a volunteer director on the Board of the Lakeshore Chapter of the Project Management Institute (PMI) for six years and remains an active member of PMI. Kiron has published articles on PPM and project management in multiple industry journals and has delivered presentations within the PPM/PM domain at multiple conferences and through regular webinars for Solution Q and the PMI Healthcare SIG.

For more of Kiron’s views on change management, please visit his blog at or contact him directly at [email protected].


You might be on an Agile/Waterfall Project, if:

mark-agile-waterfallThe purpose of this brief article is to laugh.  Laugh about how we as business analysts approach our work.  Whether you are a proponent of agile, waterfall, or some hybrid solution development life cycle (SDLC), I hope this article makes you laugh.  Remember laughter is the best medicine.

Agile:  If____, you may be on an agile project

  • If someone on your team actually offers you assistance, you may be on an agile project
  • If you’ve developed requirements and software at the same time, you may be on an agile project
  • If “waterfall” means taking a shower, you may be on an agile project
  • If you’ve had conversations with stakeholders who don’t know what they want, you may be on an agile project
  • If fun means not having to refactor code, you may be on an agile project
  • If you measure progress in story points, you may be on an agile project
  • If you share office space with team members, you may be on an agile project
  • If you play poker just to estimate work, you may be on an agile project
  • If you correct your team mates code at the same time he writes it, you may be on an agile project
  • If the work pace of your team never changes and you only work on one thing at a time, you may be on an agile project
  • If you have not worked overtime in the last year, you may be on an agile project
  • If you actually implemented something in 30 days, you may be on an agile project
  • If you stand during meetings, you may be on an agile project
  • If you actually understand these jokes, and share them with all your friends, you definitely are on an agile project

Waterfall:  If_________, you may be on a waterfall project

  • If your project sponsor dies prior to delivering the product, you may be on a waterfall project
  • If you are thinking of forging your sponsor’s signature on the 27th version of the business requirements document, you may be on a waterfall project
  • If you have worked on one project for the last ten years, you may be on a waterfall project
  • If you have a private office, you may be on a waterfall project
  • If you have a well written business requirements document that no one wants to read, you may be on a waterfall project
  • If testing is a phase in the way distant future, you may be on a waterfall project
  • If you have not met with your customer in the last week, you may be on a waterfall project
  • If 24 hours has passed and no one has asked you for a work status, you may be on a waterfall project
  • If you think a project will go according to your work plan, you may be on a waterfall project
  • If you have been working with the same people for the last twenty years, you may be on a waterfall project
  • If you think work attrition is caused by retirement, you may be on a waterfall project
  • If you have created documentation or know where it is, you may be on a waterfall project
  • If you hear the word agile and it reminds you that you are getting on in years, you may be on a waterfall project
  • If you actually understand these jokes, and share them with all your friends, you definitely are on a waterfall project

Final Comment

The style of the previous statements of course is borrowed from Jeff Foxworthy, the popular comedian and TV quiz show host.  I’m a big fan of his work and I just couldn’t resist writing this article.  As you read the agile and waterfall statements, I am sure you came up your own.  I invite you to submit them as comments for everyone’s enjoyment.  Let’s all laugh a little at ourselves. Or maybe cry!

Don’t forget to leave your comments below

Mark.A Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University.  He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance.  He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business.  Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).  Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

Scrum vs. Waterfall Round 2; The Fight Continues

scrumvswaterfall1Last month we began our “fight” by exploring two estimating techniques that are often used on both Scrum and Waterfall projects (view here). The first was relative sizing (one kind of analogous estimating) and the second Delphi (called Planning Poker in Scrum). Scrum won both rounds (barely) because, although both techniques can be used on both types of projects, their usage in Scrum seems easier to understand, learn, and apply. I don’t know about you, but when I hear the terms Analogous and Delphi I think academics and hard work. When I hear about tee-shirt sizes and planning poker, I think fun.

This month, inspired by a debate on Agile vs. Waterfall, presented by the Phoenix chapter of IIBA, I want to compare Waterfall to Scrum in a variety of different ways. As I listened to the two sides during the debate, I was amazed at the number of the similarities, as well as the importance of the subtle differences. This month’s blog will explore both the similarities and differences.

Before I begin, I want to stress the point that neither one is a methodology. Neither is prescriptive. Waterfall is an approach. Scrum is a framework, part of the myriad Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigor, although we acknowledge that both approaches have been implemented in a wide variety of ways. For the discussion below, we’ll assume the appropriate level of rigor for the project at hand.


There are many ways in which these two approaches are similar. Both:

  1. Have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
  2. Stress the importance of communications.
  3. Allow for more or less rigor, as appropriate.
  4. Find communications easier when the teams are co-located.
  5. Both face more challenges with virtual teams.
  6. Have processes to manage the scope.
  7. Estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.


Many of the differences lie in how these processes are implanted. To understand the vast differences in implementation, we need to understand that many organizations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organizations use hybrids or “best of breed” implementations. With that in mind, let’s examine some differences between Waterfall and Agile.

Intricate, large projects. On large, intricate projects with many business and technical interfaces and impacts, with a variety of cross-functional SMEs or with many compliance regulations, there are advantages to the Waterfall approach. While these projects can also be implemented using Scrum, it is harder when there are project dependencies.

  • Coding and testing. On the large projects I managed, we were always touching programs and test data that other teams needed and vice versa. It seems to me that following a detailed plan places less stress on all the teams. Even when slippage occurs or the team completes programs earlier than anticipated, following the plan and communicating variances in a more formal and proactive way is helpful to all the teams involved. Again, it can be done using Scrum or other processes, but I have found that following a plan is a stress-reliever.
  • Incorporating changes. Again, when there are approved changes and there are significant project dependencies, it can be helpful to change the plan, so that a schedule for completing these changes can be determined and communicated to everyone impacted by the change. This is particularly true when the approved changes have significant impacts and can cause changes not only to work completed by the team, but by work already completed and tested by other teams.

The winner: Waterfall!

Defining requirements when they are highly volatile. Waterfall projects have approval points, often called toll or stage gates. When requirements are unstable, business analysis can seem to take forever and the sponsor may get frustrated with what appears to be analysis paralysis. I once had a sponsor tell me that he had never seen analysis take so long, but was surprised and delighted that the project get done so quickly once we had the requirements. Thoroughness in requirements definitely paid off. However, there was significant frustration as the churn was happening.

Scrum projects have the wherewithal to handle this kind of churn better in my opinion. User stories that are pretty well understood are closer to the top of the product backlog and are ready for inclusion in upcoming sprint(s) than “epics” that are less understood.

The winner: Scrum!

Managing scope and changes. On Waterfall projects, schedule, cost, and scope baselines are established (as well as others). These become project constraints. When changes are approved and prioritized by the Business, the sponsor, often upon the recommendation of the project manager, needs to decide which of the baselines will change. I have talked to many Scrum proponents who argue that Agile projects expect change, but Waterfall projects do not. This assertion is simply not true. I have yet to be on or hear of a Waterfall project that did not expect changes. Having said that, modifying the schedule, particularly when it involves changing dependencies, can be cumbersome and frustrating.

I think managing scope on Scrum projects is easier in many respects, most of which relate to the fact that having small sprints helps the framework accommodate changes with far less pain. In addition, I have seen more consistency in the way changes are requested, approved, and prioritized on Scrum projects.

The winner: Scrum!

I could go on with this comparison, but my little blog is turning into a full-fledged article, so I’ll simply list out areas where I think Waterfall wins and address them in more detail in future blogs.

Waterfall Wins in these Areas:

  • Effectively using the role of the BA to define requirements completely, using a variety of elicitation and modeling techniques. Although Scrum is catching up, it still lags behind.
  • Defining the business need and business case. Most of the visioning I have seen on Scrum projects has tended to be superficial. Again, this may be due to the way I have seen it implemented.
  • Getting from the “as-is” to the “to-be.” Ensuring that the solution in general and software in particular supports business processes or if not, that the business is ready for the change with such things as new processes, training, the required sales, marketing and support resources, etc.

Of course Scrum wins in some other areas, too. More later!

Don’t forget to leave your comments below