Category Archives: Agile

A Point of View on Agile Vs Waterfall – Richard Cure

Hello everyone, Richard here with another blog! In this post I’d like to talk about the changing landscape in the IT industry regarding the way development is done, which means looking at agile and waterfall as methodologies to run a development project. I’d also like to share my experiences of exploring agile on the projects I’ve worked on so far.

Firstly, the concept of agile revolves around small, cross functional teams – by cross functional I mean participants with different skills and expertise e.g. Project Management, Development, IT Architecture, Integration, Business Analysis etc.

In agile, the individuals in these teams trust and support each other and closely work together, sharing the responsibility to release increments of a product e.g. software. The team splits the delivery of the product into regular “sprints” of work normally 2 weeks in length, in which the product is refined and iterated on, with an emphasis on continuous development and testing.

This is in stark contrast to a waterfall approach to development which involves normally one release of the product at the very end of development which is tested thoroughly afterwards.

Waterfall development is a less “chaotic” approach and follows the traditional software development lifecycle of Requirements – Design – Development – Implementation – Test – Deployment – Maintenance. It generally involves these stages organised sequentially in the form of a project, which is how the IT industry has generally used for many years until recent times.

Working agile has some benefits – in my opinion, here are the 3 key benefits of agile:

  • Business and technology partner better – instead of working in isolated teams with minimal interaction, teams attempt to achieve shared understanding through:
  • Daily “standups”, where each member summarises what they did, what they are doing today, and if they are facing any blockers to progressing. These short meetings are normally time-boxed to 15 minutes max.
  • Regular “demos”, where working products are demonstrated to stakeholders and progress is reviewed.
  • Regular “retrospectives”, where team members look at how they worked during the previous sprint and come up with a short list of things to improve upon for the next one.

The effect of these 3 practices ensure the whole team – including business-oriented stakeholders and technical-oriented stakeholders – is aware of what is going on and how they can improve for the next iteration. Clients or sponsor users are also often involved throughout, allowing them to influence the development of the product earlier or direct the team to “course correct” if they don’t like a feature or the way the product is going.

  • The business value of working agile is in the visibility and flexibility of the agile processes:
  • Teams can adapt to change quicker and face less hurdles during changing business or technical requirements
  • Teams feel more empowered to get things done (therefore get things done quicker):
  • The iterative nature of agile development means the team is forced to deliver in smaller increments each sprint, and can lead to defects/errors in the product being spotted much earlier, giving developers more time to fix them.

Working waterfall also has its benefits – in my opinion, here are the 3 key benefits of waterfall:

  • The project is more predictable and controlled:
    There are clearly defined stages with hard deadlines for team members to adhere to, which is appealing to those in charge of delivery of products as they can be more sure when to expect the completion of a product
  • Tends to be documented more thoroughly:
    This is a benefit to newer team members who can get up to speed by reading existing documentation, although some may argue that the code itself is a form of documentation.
  • Less room for scope creep
    In waterfall, the client usually only sees the end product once at the end of the project, meaning they have little influence in between requirements and deployment to introduce change to the original project scope, whereas in agile the client can sometimes demand dramatic change during key points in development which can throw up risks and issues during key stages in development.

Personally, I think the industry is seeing agile as a potential way forward and especially in IBM there is definite movement towards adopting agile as a new way of working, but it’s not without its challenges and problems and it won’t happen overnight to completely change. And in reality, some projects aren’t suited to an agile project management method.

For example, one of the problems we’re facing right now are that we haven’t been able to change our infrastructure to sufficiently accommodate an agile environment – in fact we have just “migrated”, or switched over, to our client’s development and test systems meaning we have lost some control of the systems we are using.

DevOps, another hot topic (which deserves its own blog post) works hand in hand with agile techniques, and requires close control of development and test systems so this may be difficult for us to explore DevOps going forward.

Culture has been a difficult barrier to get over – some colleagues have been working waterfall for decades and are hesitant to accept work not completely finished.

Thirdly, our client contracts are not agile based – meaning ideally the client would pay for each release rather than for the finished product. This is not the case although we have been exploring agile practices through the development stage using things like sprints I talked about earlier, but also in the context of a project following the waterfall method, leading to a weird hybrid of “Agile-fall”. I guess perhaps this isn’t the best way to go about it – I think it does need to be one or the other.

However it’s still an interesting and valuable experience to work agile and maybe one day in the future this will become the norm for development in general.

Thanks for reading!

Richard Cure.

Advertisements