The CDT states: “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 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. However, as opposed to conducting extensive planning upfront, agile spreads this planning activity (e.g., what specific functionality will be delivered when) more evenly throughout the project life cycle. High-level planning is completed at the beginning of an agile project and is continuously elaborated upon throughout the project as new information becomes available. This continuous planning allows a project to start much quicker and to be more nimble to make ongoing adjustments in strategy as new information becomes available. This can come through changes in business needs or priorities; project issues, risks, or resources; and even changes in available technology. It also provides the project team with the ability to more easily and efficiently adapt to changes and optimize plans as new information emerges.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. Elements of the project continuously evolve as additional information becomes available and user needs are defined. 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. 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.
Myth 4: Agile Practices are New
The practices of agile have been around for the greater part of the last century. In the 1930s, 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 1980s, 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.Scrum is just one of many methodologies that come under the umbrella of agile values and principles. Other methodologies include Scaled Agile, Extreme Programming, and Kanban.
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.
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.This story was originally published on Techwire.
