Busting 4 Myths about Agile Project Management

Outside of IT development circles, Agile project management, since its founding by software developers in the 1990s, has created a good deal of skepticism and confusion versus the more tried and tested Waterfall method of project delivery.   Founded in 1970, the main idea behind Waterfall was to have a formalized development process which “trickled down” through a series of solid, linear phases – Development; Test; Acceptance and Production – with set parameters, thorough documentation and in-depth risk management for each stage.

As a methodology, Agile came about because it simply took too long for many projects to reach fruition. There were no feedback cycles from stakeholders allowing for pivots or input on the project progression.  In some cases, the delivery time lag was so bad, an organization may have re-charted its strategic direction in the average time required to take the project to completion (three years plus).

To help counter these situations, Agile project management is clearly a growth area but what are the myths and misconceptions? What questions should curious, potentially slightly skeptical PMs be asking about this methodology and its applicability for their organization before taking the plunge?

Agile is only for IT companies

From a cultural perspective, Agile allows companies to maintain their innovativeness and ability to explore new ideas in a safe environment. It’s not a straightforward, hierarchical project management process in the traditional sense and a very different way of working. There is definitely a certain type of company culture or project requirement that lends itself to Agile project management, but it is not exclusively for IT companies or software teams.  Some of our clients are using an agile approach outside of the software development environment within a business context for instance, with R&D and marketing teams developing new products. Companies may also use it when implementing new software, working in cross functional teams with the software vendor and end user organization.

A Project Manager using the Agile approach is known as a Scrum Leader, which in itself suggests a non-linear management model. It’s all about the team and collaborative communication, it is extremely iterative and ideally team members are co-located (with everyone working in the same room). Daily stand-up meetings are held where each team member gets to share concerns and most importantly, resolve blocked work. At the end of the sprint (short term project phase) the team does a value presentation to demonstrate what was achieved and learned. The process is then repeated for each sprint and tightly coordinated with other project stakeholders, to remain in sync with the strategic goals. If this approach could be implemented in your organization for a particular project requirement, there’s no reason why Agile wouldn’t work well.

Agile is only suited for short projects

This misconception arises from the shorter delivery times enabled by Agile. These allow for the continuous delivery of cycles within a two to three-week period (the sprint) whereas with Waterfall, it may take one to two years to go from requirement to implementation.

Agile can still deliver on larger and longer projects, but it means having more overlapping continuous cycles, with the same emphasis on potentially changing customer needs. In fact, the Agile Manifesto, (written by its founders) states how customer requirements are welcomed even late in the development process, as this will help towards gaining a competitive advantage. Bringing in the voice of the customer or consumer early on helps to define the value realized more quickly. Conversely, this is difficult with a Waterfall project, because it involves closing off one area of the project before moving onto the next.

There is no project documentation with Agile

This is a common misconception and often arises through a misunderstanding of the Agile Manifesto.  This states that having a working system is valued higher than having documentation and required beforehand, which leads some people to believe that as a lower priority item, documentation is unnecessary. Ultimately, documentation is driven by client need, without an overlap of information or resulting in wasted efforts (i.e. because the system/product isn’t yet completed or approved).

So, according to the Agile approach, documentation is a necessity, but it should be kept to a minimum, follow the core agile principles of iterative communication and PMs should always be on the lookout for the best method of communicating to stakeholders.  As a Scrum Master or Leader, your role would include coaching team members that the definition of ‘done’ includes providing documentation for the support team and a project is not officially ‘done done’, until you have ticked off this box, meaning that the whole story within a sprint can be accepted.

It’s a matter of choosing one methodology over the other. Agile vs Waterfall

Perhaps the best thing about Agile is that it’s extremely flexible. There is no need for an either/or in Project Management and clear benefits can be seen from taking a hybrid approach and using both methodologies. This best of all worlds approach is known as a ‘Wagile’ approach, because it merges the linear discipline of Waterfall with the iterative flexibility of Agile. Whereas the Waterfall approach provides high level control, estimation and linear project control, Agile runs at higher levels providing innovativeness, stakeholder insights, reactiveness and rapid adaptation to unforeseen events.

The Wagile trend has been growing for some time and we expect to see the continued integration of Waterfall and Agile methods. There will always be a need to control the complexity and cost of projects, but at the same time, there will also be a need for a simple, intuitive and activity based solution that is flexible enough to capture the new ideas and continuous improvement that are so characteristic of an Agile environment.

This way, the Project Management Office (PMO) and executive teams can maintain visibility of the key deliverables as outlined within the waterfall approach, whilst at the same time, project team members working at a grassroots level have an opportunity to collaborate and innovate.