Susanne Madsen Intl. Developing Project Leaders
  • Home
  • Services
    • Workshops
    • Speaking
    • Coaching
    • Stress management
    • Master Class Series
    • Testimonials
  • Bio
  • Books
  • Blog
  • Resources
  • Videos
  • Contact
  • Library

Agile or Waterfall? 8 Tips to Help You Decide

3/4/2013

14 Comments

 
Picture
Image courtesy of Allitas.com
If you are running a software project, one of the questions you are likely to come across is which development methodology to use. Some like to stick to a traditional waterfall approach whereas others are keen advocates of an agile methodology. In reality many projects end up somewhere in between; with a methodology that is neither extremely agile nor extremely rigid.

Compared  to waterfall, these “middle-of-the-road”methodologies can seem flexible as they allow for changes to take place from iteration to iteration. Compared to agile, however, they are likely to appear rigid and far less  collaborative.

When deciding on the right development methodology for your project, think about how much flexibility it should contain and which aspects you can employ from different types of approaches to best suit your needs. Examine the size of your project, the make-up of your team, the organizational culture and what you want to achieve. Then piece together the methodology to your specific needs. Even if your organization advocates a certain approach, there will often be opportunities for you to improve it and adapt it to your specific project.
To help you decide which approach is best suited in your situation, take into consideration the below aspects. The questions will help you decide how flexible your methodology needs to be on a scale from very flexible (agile) on the one hand, to very rigid (waterfall) on the other. 
 
1. How clear are the project’s objectives and requirements? 
On some projects, the clients know exactly what they are looking to achieve and what the success criteria of the project are. On other projects, it can be difficult to pinpoint what the project needs to achieve or what the requirements are. When the requirements are difficult to define, or likely to change significantly, you need an approach which is relatively experimental and flexible; an approach which allows you to speedily demonstrate and prototype ideas to the customer and incorporate changing requirements.

2. How clear and well-defined is the solution?
 
You may find yourself in a situation where the desired outcome of the project is clear, but where the solution for achieving that outcome is not. When the team is faced with difficult and risky choices around technology, design and  implementation, your software development methodology needs to be flexible enough to cater for this and iterate through various stages of prototyping, development and roll-out.

3. How easy or difficult is it to access the end users? 
Are the users, domain experts and product owners likely to be available to provide feedback and help test deliverables at short notice, or do you anticipate that they could be difficult to get hold of? Would it be easier to engage them for a pre-planned test cycle where lots of deliverables can be tested at once? The more constraints there are around your user’s availability, the more rigid your methodology should be.

4. What is the size of the project? 
Is your project on the larger side or is it reasonably small and lean? The larger the project, the more difficult it might be to incorporate lots of changes at short notice and refocus the team in a different direction. Small tight-knitted teams which work closely with the customer and end users are more flexible and better geared to quickly incorporate changes. 
 
5. How  dispersed is the project team? 
Do you have several project teams situated in different geographic locations or is the team more homogenous and located together? When the team is geographically spread out it can be difficult to quickly coordinate new work and adapt to changing priorities. Teams which sit together, and even share the same room, are much better placed to working in an agile environment with changing priorities. 
 
6. What is the team’s and stakeholder’s experience with these  methodologies?
Are your team and stakeholders already accustomed to working with a specific methodology? If so, bear in mind that it takes time to change a team’s working practices. If your project is time critical, be wary of making too many drastic adjustments to the existing methodology as it may jeopardize the timescales and success of your project. 

7. What are  the project’s success criteria? 
Which is more important for your sponsor and client? Having a relatively firm estimate and schedule which must be adhered to, or ensuring that the end deliverables add value and match the user’s needs and expectations? Is your client ready to embrace a more flexible and quality-conscious approach at the expense of fixed costs and schedules? 

8. How much value would incremental feature driven development add? 
Does the project lend itself to being delivered in an incremental way and would this add real value to the stakeholders? Must the products and features be delivered at once in order to provide tangible benefits or would it be a real advantage to deliver them gradually?    
 
 
If you liked this post, you may also like:
Top Tips for Gathering Requirements
Initiating and Planning your Project
Risk management is how adults manage projects!
10 guidelines for estimating project effort  

14 Comments
Vin D'Amico link
3/4/2013 12:34:22

You make good points. The one pitfall that I see is what I'd call the degree of certainty. The business may claim that they are clear about what they want and when they want it. In reality, things change. People leave. New people are hired. Competitors do the unexpected. What appeared to be clear and simple several weeks ago might be muddy and complex today.

Any ambiguity at all favors using an agile approach just to be safe.

Thanks for sharing!

Reply
Susanne Madsen link
4/4/2013 01:18:32

Thank you for your comments Vin. I completely agree that we almost always have that degree of uncertainty on our projects - and whereas it may not justify a fully agile approach, it certainly advocates that some agile practices are implemented that allow a degree of iterative development.

Susanne

Reply
fashion designing in jaipur link
19/9/2013 03:28:23

Thanks for posting this information here.

Reply
Phil Van Sickel
5/4/2013 07:12:46

Requirements are never "Clear" They are always dependent upon the interpretation of the developer. And the understanding of the developer is never certain until they produce completed code. The focus of Agile is not for flexibility. Agile's primary focus is to provide rapid feedback so that errors in understanding can be corrected quickly. The flexibility comes from recognizing this fundamental issue and designing the project so that rapid feedback is throughout.

Reply
David Wright link
5/4/2013 12:57:40

"Which is more important for your sponsor and client? Having a relatively firm estimate and schedule which must be adhered to, or ensuring that the end deliverables add value and match the user’s needs and expectations?"

Most sponsors I have worked with say something like " I want my all my requirements met, which will inherently provide value to me; how much will it cost and when will it be completed? (and it better work, i.e be of good quality)"

I can't recall any sponsor at least not thinking they know what they need; even SCRUM projects start with a prioritized backlog. The issue is the proper use of techniques that move from statement of need to solution, and the first one is to elicit requirements from sponsors in a way that the sponsor understands, and that designers/developers can use, all in a timely manner. From that point, your methodology choice and project structure can be defined to best suit all the other factors you mention. You may still want to provide rapid feedback to confirm requirements as you go, test that architectures will work, etc.. You may do incremental development, to break big projects into smaller parts that can be delivered and used, and incorporate change as needed.

A smarter man than me once said "the hardest part about software development is deciding what software to develop." A short but intense period of requirements elicitation can address this issue, and set up any project for success.

Reply
Jim Pirrie
11/4/2013 09:26:37

Susanne, some very useful points and comments.

When delivering multi national IT architecture projects, there is a requirement to take a flexible and experimental approach which may indeed require a hybrid methodology approach.

In the first instance the adoption of a 'waterfall' methodology approach might provide the structured basis with which to engage with sponsors/stakeholders to secure the necessary funding to meet the delivery of benefits. As you are aware, in some cases these are required within very tight timescales to meet change management requirements.

When you are trying to rationalise a plethora of 'stove-pipe' software applications to deliver an IT architecture that promotes multi-national Information Management/Information Exploitation, the delays presented, such as the inability to reach agreement on Information Sharing/Security/Release, requires a flexible development approach which may require adoption of an alternate approach e.g. 'Agile' to enable 'quick fix' technical solutions. As an example there may be a requirement to deliver a 60% solution which in itself would be sufficient to move the project forward to meet delivery timelines.

As some have already intimated, Information Exchange Requirement Documents may intimate the sponsors desired end state, but the technical complexities required to deliver the benefit to the end users may indeed require a number of methodologies especially when you are trying to knit fog, (or in software terms - Clouds).

Reply
Bob Klehm link
16/4/2013 07:23:39

I have managed large, complex projects for several decades - both waterfall and agile. I have never followed a pure agile approach for 1 reason: co-location. The reason that agile works is that you have business and technical people working together over a fixed period of time to solve a specific problem. This level of focus and concentration yields great results. However, if you have a team, as I typically do, that is dispersed across multiple continents and timezones the intensity and focus breaks down. Even using the latest collaboration tools does not solve the time-shift problem. I am no longer an agile zealot but have resigned mysef to the middle ground of agilefall.

Reply
Dave Wedge link
19/4/2013 11:10:51

A much debated topic and whilst you make good points I dont think there are clear answers in many environments. Both methodologies are prone to failure. The complexity of organisations which are themselves reacting to external forces generally means that priorities and key resources are constantly shifting. Without stability and commitment it does not matter much which approach you are taking. Agile has a lot going for it in theory but having managed project teams in global environments I have seen little evidence that ultimately it is proving any more effective than waterfall.

Reply
Assaf Lavie link
21/4/2013 05:47:35

There's also a middle way - being agile but still planning forward. That's how we work. Our short-term goals are treated as sprints. We plan them at very high resolution so we have very reliable estimates regarding their schedules. We plan the long-term efforts in a "telescopic" way. Meaning the farther ahead we look, the lower the resolution in which we plan.

This, incidentally, is made possible by the tool we use to manage our projects, which just so happens to be our main product :) Gigantt: http://www.gigantt.com

We really see it as a bridge between traditional approaches to PM and the agile movement. Lots of organizations could certainly benefit from adopting agile principles of PM, but they don't always succeed in doing so because of the existing weight of "how things are done here". Some managers will resist this sort of change towards agile because they'll expect to still have Gantt charts. Often this is very justifiable - they might be committed to all kinds of deliverables to 3rd parties, or what have you. That's why combining the two approaches - hi-res for short-term cycles and lo-res for long-term planning - could be just what these sort of organizations need.

Reply
Cert IV Training and Assessment link
21/4/2013 21:49:43

Hi Susanne,
You've made some awesome comments. I have students who continually use Agile as a first preference. I'll have to pass this onto them!

Reply
Susanne Madsen link
24/4/2013 01:51:42

Thank you everyone for your comments. They are awesome! A couple of highlights for me:

"The focus of Agile is not for flexibility but to provide rapid feedback so that errors in understanding can be corrected quickly" (Phil Van Sickel)

"I have never followed a pure agile approach for 1 reason: co-location. I am no longer an agile zealot but have resigned mysef to the middle ground of agilefall." (Bob Klehm)

"Both methodologies are prone to failure. Without stability and commitment it does not matter much which approach you are taking." (David Wedge)

"Combining the two approaches - hi-res for short-term cycles and lo-res for long-term planning - could be just what these sort of organizations need." (Assaf Lavie)

Reply
Ralf Finchett link
25/4/2013 07:25:36

A great and simple approach Susanne. For me, Agile is much more than a Delivery Methodology, as it can deliver greater buy in from the end user into embedding the solution, and avoiding then 'launch and leave' risk.

Failing that, I have seen Waterfall with zero governance or change control, and it was nicknamed Watergile!! :-)

Reply
SmoothStack link
23/7/2019 07:36:29

Agile provides a framework with which teams can maintain focus on rapidly delivering working software and providing true business value, even in environments where the technical and functional assets and landscape may vary or change routinely. We can say that Agile allows development teams to provide maximum business value through the delivery of truly valuable, working software that meets the business needs. How do we know that the software truly meets the business needs? Because all of the stakeholders are involved and quality and scope verification take place in short, iterative cycles. Deviations from the true purpose of a feature or piece of functionality can be identified quickly and corrected in an agile manner.

Reply
ganesh link
13/2/2021 05:50:39

Great stuff! It’s really remarkable piece of writing in favour of all the internet users; they will get advantage from this I am certain.

Reply

Your comment will be posted after it is approved.


Leave a Reply.

    Categories

    All
    Agile
    Authenticity
    Building Relationships
    Coaching
    Communication
    Delegation
    Estimation
    Feedback
    Handling Conflict
    Innovation
    Iron Triangle
    Limiting Factor
    My Story
    Perception Of Failure
    Planning
    Podcasts
    Positive Attitude
    Proactive Project Management
    Progress Reporting
    Project Costs
    Project Failure
    Project Initiation
    Project Leadership
    Project Management Mistakes
    Recruitment
    Requirements
    Resistance To Change
    Risk Management
    Self Esteem
    Stakeholder Management
    Stress Management
    Team Motivation
    Time Management
    Trust
    Vision And Mission

    Picture

    Susanne Madsen

    Susanne is a project leadership coach and the author of The Power of Project Leadership (now in 2nd edition). Read more..

    Picture

    Download FREE PM RESOURCES

    Picture
    Picture
    Picture
    Picture
    Picture

    Archives

    April 2022
    March 2022
    December 2021
    November 2021
    October 2021
    July 2021
    May 2021
    April 2021
    February 2021
    January 2021
    November 2020
    September 2020
    June 2020
    March 2020
    February 2020
    December 2019
    October 2019
    June 2019
    May 2019
    March 2019
    February 2019
    December 2018
    November 2018
    October 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    September 2015
    August 2015
    July 2015
    June 2015
    May 2015
    April 2015
    March 2015
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    January 2014
    December 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011
    October 2011
    September 2011
    August 2011
    July 2011
    June 2011
    May 2011
    April 2011
    February 2011

    View my profile on LinkedIn

    RSS Feed

Susanne Madsen International - Developing Project Leaders