Myths & Misconceptions about Agile

Many organizations and teams across industries and throughout the world are using Agile methodology to get the advantages of faster product delivery, shortened feedback loop, and increased collaboration between teams. This doesn’t mean, however, that the move from traditional to agile project management is an easy one. As with any new approach and methodology, there are hurdles in adoption — a prevalent one being the need to overcome a number of myths and misconceptions about what an agile approach involves.

Such common myths and misconceptions, five of which are addressed below, arise as a result of a lack of adequate understanding of the agile method.

1. Agile can’t work with other models

It is a common myth that the practices included as part of the agile methodology can’t work together with other plan-driven process models such as the waterfall model. This myth is incorrect. The agile method, despite allowing more flexibility, incorporates aspects of more traditional models into its structure. The agile method’s multiple, shorter — yet complete — product development cycles consist of the same stages as more traditional process models. As such, agile practices are more than compatible with traditional processes. One manner in which agile could be combined with a more plan-driven model, such as the waterfall model, is to utilize the agile method’s sprints within the waterfall model’s linear structure; divide the analysis, strategy, and design — pre-deployment — stages of the waterfall model into tasks which are prioritized and approached with sprints as in the agile method, and initiate work towards each subsequent stage prior to completion of the previous stage. Essentially, it is up to the project manager’s discretion as to whether or not certain agile practices are combined with those of other methods, and if so, what aspects are combined.

2. Requires no documentation

One of the agile manifestos states “working software over comprehensive documentation,” which is quite often misunderstood, leading to another prevalent myth that agile project teams don’t create or use any documentation. This is far from the truth, as documentation is as necessary of agile project teams as it is of project teams utilizing another method. Documentation is integral to each stage of the agile method’s cycles, for each cycle is intended to test out a product and improve it accordingly; documentation of what went well and what needs improvement in each cycle is crucial to altering the product and, thereby, launching the subsequent cycle to further test and enhance the product.

3. Specific to Software Development

Another common misconception is that agile is specific to software development. This myth is also incorrect. Agile Project Management started with software development essentially, but over the years it has evolved into a well defined methodology that can easily be applied to other types of projects that have a high potential for continuation and change, and shorter feedback cycles. It is commonly used in a range of industries, from technology to financial services, and is prevalent in start-ups and businesses launching new services or products. The stages of agile project management — analysis of the situation, design, implementation, verification, deployment, and maintenance — contribute to the ability to incorporate the agile method into projects beyond software development, as the stages are general enough to fit into any project; this, coupled with the ability to make quick changes to a project under the agile method lends the method to be particularly useful in any project regarding a market sensitive product, that requires much feedback, or is subject to continuous change over its lifecycle.

4. Projects don’t require planning

A very common myth is that agile projects do not require any planning. Despite its increased flexibility compared to other methods, this myth is completely wrong. It is true that agile is not a plan-driven development process, and nor does it have WBS and/or Gantt charts. However, in Agile, we have various planning points in terms of formalized ceremonies, such as PBR and PO, and Dev Sprint Planning ceremonies which address the team’s project goals and priorities. The ceremonies consist of the product owner ensuring stories have enough details to convey to the team what needs to be delivered, and the team and PO establishing the priority tasks, which are attended to in a planned order of “plan, build, and run.” The laying out of goals and priorities assists in providing a framework of stages to work with, and from this emerges a plan of project tasks to tackle, and the order in which they are to be tackled.

5. Agile eliminates the role of management

It is commonly believed that, due to the flexibility of the agile method in comparison to plan-driven models, agile eliminates order and clearly defined roles. This is not the case. Agile consists of clearly defined roles for each person involved, and there is a manager, in the form of the Product Owner. The PO is responsible for overseeing the project, including the project’s goals and priorities, and leading the team towards achieving those goals. Aside from the PO, there is the role of Scrum Master, who is responsible for ensuring that the development teams are in optimal condition to completing the tasks within each sprint. Everyone else involved in agile product development compose the development teams, which are responsible for carrying out the tasks necessary to ultimately achieving the project’s goals. The development teams work with the PO to decide how many tasks they can take on in each sprint, and organize each sprint’s tasks in ways that optimize their accomplishment.