Exploring trends and developments
in project management today
Waterfall v Agile: How Should I Approach My Software Development Project?
Software development projects are usually approached using one of two methods, Waterfall or Agile. Both have pros and cons and each have their exponents who espouse the value of their chosen approach. In this article, I look at both methods and try to understand which is best and under what circumstances answering the question, "How should I approach my software development project?"
The waterfall method has been around since the 1970s and remains in common use. It says you should follow a distinct set of steps through the life cycle of your project. The steps are usually similar to this:
- Requirements Analysis
The reason it is called the waterfall method is that each stage follows from the previous one when it has been completed, cascading down like a waterfall. Like a waterfall it flows down and never up. This method is often seen as "safer."
The Waterfall method works well with commercial arrangements where contracts are signed and money is paid. However, when working for internal customers it's more difficult to be hard-nosed about last-minute changes when it's people in your own organisation asking who often have backing from senior management.
|Detailed documentation.||Slow start.|
|Agreed and signed off requirements.||Fixed requirements difficult to change.|
|Can be delivered using developers with a lower skill set.||No customer visibility of software until the development has been completed.|
|Reduced number of defects through thorough design planning.||Lack of flexibility making it difficult to change direction.|
|Defined start and end point for each phase, allowing progress to be easily measured.||Customers often unclear about their requirements initially.|
The Agile method refers to an iterative approach to projects, where requirements and solutions evolve through collaboration among customers and development teams. The term was coined in 2001 when the "Agile Manifesto" was put together.
If your manager is worried about you making mistakes in front of customers, this method may not be for you. The Agile method means that you create deliverables early and refine them through several iterations with the customer. However, you may find that some stakeholders view this negatively.
During a recent project to deliver a video homepage for a customer's website, the first iteration was close to the example provided by the design agency. Testing this iteration threw up some items that needed attention, most trivial in terms of development effort needed to fix them.
My manager saw this as having failed to deliver the customers' requirements and an embarrassment for the team. My view was that our delivery was 90 per cent right and the final 10 per cent would only take a few days of development effort. This first iteration allowed us to understand fully the customer requirements and for the customer to be clear about their expectations.
After being suitably rebuked I was left with no doubt of my managers feelings. I wasn't to allow this to happen again, and all future work should have a fully agreed and signed off specification before a single-line of code is written.
Interestingly enough, the customer was happy with the Agile approach as it enabled them to see work in progress and comment on it during development.
So does the Agile method lead to a faster delivery? That's debatable. Just because you start coding early doesn't necessarily mean you'll finish sooner. However, it does ensure the final deliverable meets the customers' needs, mainly because they provide useful input throughout the development phase.
|Quick start, incremental releases and regular customer reviews and feedback.||Can be misinterpreted as unplanned or undisciplined.|
|Evolution of requirements over time.||Needs a high-quality, customer facing development team.|
|Ability to respond to change quickly.||Needs a high-level of customer involvement.|
|Less rework, achieved through continual testing and customer involvement.||Lack of long-term detailed plans.|
|Real-time communication among the development team and customer.||Produces a lower level of documentation.|
So which method is best, Waterfall or Agile?
The method you use depends on several factors, some of which are:
- Type of work: is there a clearly defined outcome? Website development is creative and therefore lends itself to the Agile method. Transactional system development, where there is a clearly defined outcome, is better suited to the Waterfall method.
- Type of customer: are they willing to work in an iterative way, do they have enough time to review and comment on regular iterations?
- View of your manager: does he or she favour one method over the other. How adaptable is he or she?
- View of IT within the organisation: is IT seen as a valued partner or a necessary evil? If the latter then use the Waterfall method.
- Internal or external customer: is your customer internal or external? The Waterfall method works well with external customers where you can hold them to a signed contract, as opposed to internal customers who can force you into changes by gaining the backing of senior management.
It's important as project manager to select the method that best satisfies your customers' needs. The problem comes when there's a difference of opinion. In these cases choose the method that will deliver the best result, and manage anyone who disagrees.
In the end both methods can deliver your project. It's all about managing the expectations of your customer and delivering a quality product. Let's face it, once you reach journey's end, nobody worries how you got there.
How to Introduce Agile Project Management to Your Organisation
Introducing Agile concepts to a business environment plagued by traditional approaches (Waterfall) can be a political nightmare. It's important to show your business that you're trying to solve their problems, rather than just evangelising Agile. Here are a five short strategies to help alleviate the pain and make your migration into Agile project management as smooth as possible.
How Agile Practices Reduce Requirements Risks
Every software project carries some risk, but many of these risks can be mitigated. That's true of problems related to product requirements - problems that are often cited as one of highest risks for any type of software project. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry.
Project Management the Agile Way
Agile project management has a lot to offer legal case management. Imagine you could continually wring out the inefficiencies in your law practice. Picture having the luxury to step back from the trees and see the forest. It may sound crazy, and, in the case of removing every single efficiency, perhaps pie in the sky. But you can get close, and it takes a lot less effort and time than you think if you embrace something we software folks call a "Sprint."
Introduction to Scrum
Scrum is one of the simplest "Agile" methodologies and is also proven to be highly effective for both software development and more general product development. Scrum is often used in financial product development. Scrum works very well in its own right and is also an excellent first step if you want to introduce Agile concepts into your organisation since it is simple and focuses on high-level project management.
The POST method is a great way to give clarity at the beginning of a meeting.
- Purpose: What is the purpose of the meeting?
- Objective: What are you trying to achieve in the meeting, what does success look like?
- Structure: What is the structure of the meeting we are having?
- Timing: How much time is allocated to the meeting?
21 Ways to Excel at Project Management
The popular project management eBook fully updated and available as a website.