1.1.3 Agile Myths

To better understand what agile is, it may be helpful to understand what it is not. Agile is not a new approach, but it may be new to many project team members within state organizations. As with many concepts and approaches, misconceptions and myths are often times communicated and shared amongst new and even seasoned practitioners. Myths can be misleading when trying to understand what work might be involved and what situations are most appropriate for leveraging an agile approach. The following agile myths and explanations can help ensure a common, basic understanding when considering agile, and thus help level expectations for a project team or organization considering applying agile concepts.

Myth 1 – Agile Means “No Planning”

As with any approach, planning is a vital aspect that, if not adequately carried out, greatly diminishes the effectiveness of a successful implementation. Upfront project planning, or an overall plan, sets clear expectations on what the project intends to achieve. When expected outcomes are identified, a path can be mapped out with clear understanding of the technical scope, business goals, ownership, and checkpoints.  This advance planning doesn’t add extra project work. It moves the decision-making to the beginning of the project, which eliminates mid-project surprises and decreases the overall amount of work required.  Initial planning sets a firm foundation for a project, but things can change.  Long-term, detailed planning can be valuable but can also be wasteful depending on the circumstances. The more costs you incur in planning, the more you leave yourself exposed to inefficiency and waste. It is important to strike a balance between upfront planning and executing in a continuous cycle. 

While upfront planning is critical, it is still just the first step along the path to success.  No amount of initial planning will deliver a finished product. Project surprises are inevitable and can come through changes in business needs or priorities; project issues, risks, or resources; and even changes in available technology. The flexibility of continuous agile planning and executing can turn these unexpected occurrences into positive outcomes. It can be the difference between unproductive, stressed teams and highly efficient, cohesive teams. Product ownership must remain consistent throughout the project to coordinate delivery and support with technical teams by owning the tactical planning along with the scrum master and other stakeholders.

Myth 2 – Agile Means “No Governance”

Within an agile approach, the team members working on the project have autonomy over decisions about how to meet the needs of the user. However, most state organizations will find it difficult to allow project teams complete autonomy due to reporting and/or other governance requirements. As a result, organizations transitioning to agile may need to modify their governance practices. This includes incorporating clearly defined parameters within which the project team is free to make decisions and a clearly defined, fast-moving governance process to make decisions that are outside the team’s purview.

To create an environment that supports team autonomy, the organization should establish a governance process that meets regularly; can accommodate ad hoc meetings; make decisions quickly; and is comprised of members with appropriate knowledge of the project, business, and users. Defining lightweight, fast moving, and effective project governance is incredibly important for agile project success. The key is to establish a process that is appropriately specific, but not overly prescriptive.

Myth 3 – There is No Documentation with Agile

The adaptive and iterative nature of agile places less emphasis on the need for documentation compared to waterfall, but that does not mean that no documentation is required during the project execution iterative cycles. Elements of the project continuously evolve as additional information becomes available and user needs are defined.

As shown in Figure 1-1, a traditional approach results in detailed documentation at the end of each phase. Following an agile approach does mean less documentation compared to a traditional waterfall approach, but documentation is needed nonetheless. In agile, an appropriate level of documentation will be an output of each iteration.

Figure 1-1 contrasts the development of documentation in a traditional waterfall approach versus an adaptive agile approach.

Developing adequately detailed documentation for agile is a necessity to:

• Meet the needs of project Stakeholders.
• Document decisions made.
• Support communication with external groups – including Stakeholders outside the project team or for team members that cannot collocate.
• Support the use, operation, and maintenance of the system.
• Capture lessons learned for continuous improvement and to benefit future projects.
• Report project status and performance metrics.

Whether your approach is agile or waterfall, the documentation that you develop should serve a purpose and not be created only because it was required in efforts undertaken in the past. The effective management of a project should have value-driven documentation that supports the project team’s communication with Stakeholders, and enables the business to use the product effectively, and the technical team to support and maintain it. When considering what documentation looks like in your project, think about the value of the document or if it is needed, what information needs to be captured, when it needs to be captured, with whom it needs to be shared, and how that documentation might help the team improve.

Myth 4 – Agile Practices are New

The practices of agile have been around for the greater part of the last century. In the 1930’s, physicist Walter Shewhart began improving products and processes through iterative cycles. This practice was later modified by W. Edwards Deming to become the Plan-Do-Study-Act (PDSA), also known as Plan-Do-Check-Act (PDCA), cycle for continuous improvement and quality management. Up through the 1980’s, the United States military, NASA, IBM, Honda, Toyota, Canon, and others continued to experiment with and evolve concepts and practices we recognize as agile. These ideas led to the publication of the Agile Manifesto in 2001 and identification of the common values and principles for improving the approach to system development projects. Currently, several varieties of agile-based methodologies are used in these efforts, including Scrum, Extreme Programming (XP), and in some cases, Kanban.

Myth 5 – Agile Only Works with Small Projects

An agile development team consists of small, cross-functional groups that collaborate throughout the development process. This approach can be equally effective on small projects and larger efforts to develop complex systems since agile teams typically “divide and conquer.” For larger projects, this means that multiple teams can be organized and focus on separate components of system functionality and/or technical architecture.

For agile projects of all sizes, but especially for the large and complex, continuous integration of developed components on a daily if not more frequent basis is a critical success factor– more specifically, project teams need to check in and test newly developed code against the larger solution within a production-like environment. In an agile project with typically short development iterations, parallel development efforts, and frequent delivery of functionality, project teams must integrate their work often to detect and resolve errors as quickly as possible, with the ultimate goal of being able to deploy at any time. If project teams delay the integration to just-prior-to-release, they will likely run out of time to adequately perform testing, address defects, and prepare the infrastructure. Agile teams should ensure that they have the right automated build and test tools, and the appropriate processes in place to support continuous integration.

Myth 6 – Agile = Scrum

Scrum is a popular development methodology that is iterative and adaptive; however, Scrum and agile are not the same thing. Scrum is a framework for developing and managing work, while agile is an approach that follows a common set of values and principles that many methodologies fall under. Agile projects do not have to adopt any particular development methodology. Organizations must assess each development methodology to identify which is best suited for the environment. It is important to understand that the different development methodologies all focus on understanding and meeting the users’ needs in a flexible and iterative way.

Furthermore, for organizations that are not ready to adopt agile as a development methodology, some agile practices can and should be leveraged to complement a waterfall approach. This includes those that pertain to the culture and environment of an organization (e.g., collocating teams, having access to business owners), or to project planning (e.g., deploying the project over several releases instead of one release at the end). Agile development methodologies have a greater chance of successfully achieving the desired outcomes when adopted in its entirety; this incremental adoption of agile organizational and planning practices can help lay the foundation for a later adoption of an agile development methodology.

As shown in Figure 1-2, Scrum is just one of many methodologies based on agile values and principles. Other methodologies include Scaled Agile, Extreme Programming, and Kanban.

Figure 1-2 depicts the different development methodologies that are collected under the umbrella of agile.

Myth 7 – Implementing Agile is Easy

Change is hard. Transitioning an organization that is more accustomed to a traditional waterfall approach to an agile approach is not an exception to this rule. A significant number of state organizations will not have practices and procedures that are geared towards those of an adaptive approach and will likely need to focus on adapting the project team’s project management and system development processes to the unique characteristics of the organization, project, and people.

To achieve the full benefits, project teams must not only learn the best practices of agile; it is also important to understand the specific circumstances of the organization’s culture and the project. To start, the project team should assess the organization’s readiness and whether the selected project is the right fit for agile (see Section 6 – Transitioning to Agile for more details). Important areas to evaluate include the organization’s existing governance structure and project management processes to see if they align or can accommodate the adaptive values and principles of agile, and the level of management buy-in to both support and be an agent for change. It is important to invest the time, resources, and effort to establish the culture, expectations, and infrastructure to support the implementation of an adaptive methodology. Learning how to work in an agile way requires practice, commitment, clear and timely governance, and learning by doing. For those with little or no experience, consider leveraging an agile approach for a smaller effort to demonstrate success and the team’s proficiency before moving on to something bigger.

Myth 8 – Pure Agile is the Answer

Employing agile practices will not be the solution to all project management and IT development issues encountered with a traditional approach, as agile may not meet the varying needs of the organization. Doing anything new within an organization often introduces elements of additional project risk. In this kind of environment, the implementation of agile practices and principles should be done pragmatically and take into consideration the real-world environment in which the project is managed and the system is developed.

To realize benefits associated with an adaptive methodology without an overhaul of the current environment, organizations can moderate the degree of change. In particular, a project that takes place in a government context will likely be more successful if it integrates adaptive and user centered practices into its traditional waterfall approach. This could be due to rules, regulations, or the organizational structures and cultural expectations that are heavily based on traditional waterfall processes. For small changes, organizations can consider incorporating the following practices to be more adaptive:

• Conduct and communicate lessons learned frequently and not just at the end of the project. Adopting this practice will support the continuous improvement process discussed earlier.
• Have short (15 minute) daily stand-up meetings to provide a venue for project team members to communicate roadblocks they are experiencing, and for management to help resolve.
• Manage each project team member’s work-in-progress. Set clear and realistic expectations for what work can be accomplished in a given period to not over-allocate resources. This requires the team to prioritize its work and accomplish the most critical tasks first.

For organizations that are ready for bigger change, see “Selecting the Right Approach” for additional details.

Myth 9 – Agile is Undisciplined

Agile project management and system development practices are not only demanding of the project team, but they also require the support and a shared commitment for success by the leaders of the organization. The continuous integration and test-driven development of agile requires skill, coordination, collaboration, and discipline from the entire project team. Successful agile teams consistently deliver quality product increments that demonstrate working functionality in short time frames to provide value and benefit to the organization. To achieve this level of delivery, the leaders of the organization must delegate authority to the team to enable them to make decisions rapidly; this requires a high degree of developer and team discipline.