To understand Agile better, it may be helpful to dispel some of the myths that surround the methodology. In an age of misinformation many of the Agile concepts and approaches are incorrectly communicated and shared with new and old practitioners alike. By addressing some of these myths we may be able to understand what works and what situations are the most appropriate for adopting an Agile approach. The following myths and explanations may help with understanding the Agile framework and assist practitioners with levelling the expectations from project stakeholders and their own project teams.
Myth 1 – No need to plan!
Planning is central to the success of any project and for those using the Agile approach it is just as important. With Agile the way we plan is different. In a more traditional project, the majority of the planning is upfront and ongoing monitoring is measured against that baseline. In an Agile project the planning activity is spread out across the project. High level planning will still be required at the start of the project. However, planning continues throughout the project as new information becomes available.
This means the project can start quickly and is not hampered by the time-consuming planning process at the early stages of the project. The approach is more dynamic as it responds and makes ongoing adjustments based on new information as it becomes available. Theses project updates can come through changes in business needs, project issues, risks or even advancement in certain technology.
Project teams anticipate change and therefore are more adaptable to easily and efficiently make changes and streamline plans as new information emerges.
Myth 2 – No Governance Required!
There is a certain level of autonomy when it comes to running Agile projects. However, there will be some level of reporting and governance required. If a project team is transitioning from more traditional frameworks there will still need to be some level of governance practice. This may include clearly defined parameters in which the team can operate. These parameters should not be made at the expense of one of the advantages of the Agile approach which is fast moving efficient decisions.
Ideally the approach will create an environment where project staff have some level of autonomy in which effective decision making can be made in a timely fashion. The organisation should establish a governance process that meets regularly, is comfortable with ad hoc meetings, can make decisions quickly and is comprised of staff members that has the appropriate knowledge of the project and it’s stakeholders.
The balance will be in finding a level of governance that is appropriately specific but not overly prescriptive.
Myth 3 – No Documentation Needed!
The nature of Agile with its flexibility and iterative practices places less importance on documentation compared to the Waterfall approach. This does not mean that there is no documentation. Rather as the project evolves and additional information becomes available there will be an element of collating this and reflecting on it when the project closes.
Having some level of documentation is necessary for the following reasons:
- It satisfies the needs of project stakeholders
- It provides a trail of evidence in relation to decisions that were made.
- Supports the use, operation and maintenance of the system
- Capture lessons learned for continuous improvement
- Reports the project’s status and performance metrics.
The amount and detail of documentation should be designed to serve a purpose and shouldn’t be created only because that is what has been done in the past. Effective management of a project should have in place value driven documentation that supports the project team and it’s level of communication with stakeholders. It should enable the organisation to use the product effectively and provide a level of guidance to the technical team on how to use and maintain it.
When considering what type of documentation to include, consideration should be given to the value of the document and whether it is actually needed. Further considerations include when it needs to be captured, with whom it needs to be shared, and who that documentation can help improve the team to deliver better projects in the future.
Myth 4 – Agile Practices are New
The Agile framework has been in use for almost one hundred years. The physicist Walter Shewhart began improving products and processes on the 1930s. This was later modified by the Management guru W. Edwards Deming who introduced the Plan-Do-Check-Act cycle for continuous improvement and quality management.
Through the 1970s Agile concepts continued to develop with the Lean philosophy that was introduces in the Toyota factories. Through the 1980s the United State military, NASA, IBM, Honda and Canon continued to experiment with concepts and practices that we now recognise as Agile.
The Agile concept was solidified when 17 software programmers met in Snowbird, Utah. This led to the publication of the Agile Manifesto in 2001.
There are many Agile methodologies in place, and they continue to grow. The most recognizable frameworks are Scrum, Kanban and Extreme Programming
Myth 5 – Agile only Works with Small Projects
One of the advantages of Agile is to be able to break down large projects into more manageable work packages. An Agile development team may consist of small cross-functional groups that will collaborate across the large project. This means that there are multiple teams that that can be organised and focused on specific components of a system’s functionality or it’s technical architecture.
For large or complex projects teams will continuously integrate and develop components on a daily basis. These teams will check in and test newly developed code against the larger solution within a production like environment. This integration must take place often in order to detect and resolve errors as quickly as possible, with the ultimate goal being able to deploy at any given time.
If project teams delay integration until just prior to release then they may not ba bale to perform adequate testing, address defects and prepare the infrastructure.
Agile teams should ensure that they have the right level of automated build and test tools, and the appropriate processes in place to support continuous integration in all projects from small to large.
