PhD Graduate and result-oriented Director with 25 years experience with involvement in all levels of Business Strategy, Sales and Marketing, Managing Project and Product Development. Aside of managing a company, he is also the best corporate trainer and public speaker in seminar and conference.
Busting the Most Pervasive Agile Myths!
Many people, especially the authors of the manifesto, believe that agility will become even more important as a result of the acknowledged need to adapt to change. Bennekum and Van Hunt even make the case that agile thinking is essential for success in the 21st century!
What is Agile?
At its core, agility refers to the capacity to innovate and adapt to change in the business and technical domains with speed and flexibility (Henderson-Sellers & Serour, 2005; Highsmith & Cockburn, 2001). Other aspects of agility are also examined, such as lightness or leanness (having few formal processes), as well as related ideas like nimbleness, quickness, dexterity, suppleness, or alertness (Cockburn, 2007). (Erickson et al., 2005). Essentially, these concepts advocate a "light" methodology that encourages maneuverability and quick responses (Cockburn, 2007).
Agile is best suited for iterative and incremental projects. It’s a process where demands and solutions develop through cooperative work between self-organizing, cross-functional teams and their customers. It was initially developed for software development as a response to the shortcomings of the Waterfall method, whose processes did not meet the demands of the fiercely competitive and ever-changing era.
Busting the Most Pervasive Agile Myths!
Myth #1: Agile is primarily used for software development projects
The principles outlined in the Agile Manifesto for Software Development are most likely the foundation of this myth. Only 3 of these principles specifically relate to software development; the remaining 9 are general and can be applied to almost any project. Most Agile principles can be used in almost any situation, whether it be at work, home, or in our communities.
A five-day, comprehensive Agile training course that was supposed to take six months to develop was created in just 60 days, providing evidence that this myth is untrue. Six individuals worked on the project at the outset to create a 12-module course. The training deck had more than 550 slides after the first few weeks, many of which were unnecessary. It became clear that our small team of three needed to rethink its strategy as the majority of team members were drawn back into other projects and support dropped. We used Scrum techniques to shorten the project's six-month duration to 60 days and reduce the training deck's number of slides from more than 550 to just 350.
Myth #2: Agile = Scrum
Scrum is an iterative and adaptive development methodology, but Scrum and agile are not the same. While agile is an approach that adheres to a common set of values and principles that many methodologies fall under, scrum is a framework for creating and managing work. Agile projects aren't required to use a specific development methodology. Each development methodology must be evaluated by organizations to determine which is best for the situation. It's critical to realize that all development methodologies place equal emphasis on identifying and adapting to users' needs in an iterative and flexible manner.
Additionally, some agile practices can and ought to be used to supplement a waterfall approach in organizations that are not yet prepared to adopt agile as a development methodology. This includes those that have to do with an organization's culture and environment (such as collaborating teams, having access to business owners, or project planning) (e.g., deploying the project over several releases instead of one release at the end). Adopting agile organizational and planning practices gradually can help lay the groundwork for a later adoption of an agile development methodology. Agile development methodologies have a higher chance of success when adopted in their entirety.
Myth #3: Agile methods have no documentation
Although less documentation is required when using an agile approach than when using a traditional waterfall approach, documentation is still required. Each iteration in agile will result in a suitable level of documentation. Each iteration in agile will result in a suitable level of documentation. Agile documentation development is essential to:
• Satisfy the needs of project stakeholders.
• Record your decisions.
• Facilitate communication with outside parties, such as project team stakeholders or team members who are unable to collaborate.
• Assist with system use, management, and upkeep.
• Record lessons learned for future projects and continuous improvement.
• Provide performance metrics and project status updates.
Myth #4: Agile Only Works with Small Projects
Small, cross-functional teams that work together on projects together make up an agile development team. Since agile teams typically "divide and conquer," both small projects and larger efforts to develop complex systems can benefit from this strategy. This enables the organization of multiple teams to concentrate on various system functionality and/or technical architecture components for larger projects.
Continuous integration of developed components on a daily, if not more frequent, basis is a critical success factor for agile projects of all sizes, but especially for the large and complex. More specifically, project teams need to check in and test newly developed code against the larger solution in a production-like environment. Project teams in agile projects must frequently integrate their work in order to identify and correct errors as quickly as possible with the ultimate goal of being able to deploy at any time. Agile projects typically have short development iterations, parallel development efforts, and frequent functionality delivery.
Myth #5: Agile Means “No Governance”
The team members working on the project have autonomy over decisions regarding how to meet the needs of the user under an agile methodology. However, due to reporting and/or other governance requirements, the majority of state organizations will find it challenging to grant project teams complete autonomy. Organizations making the switch to agile may therefore need to change their governance procedures. This entails including clearly stated constraints on the project team's decision-making authority as well as a transparent, quick governance process for decisions that fall outside the team's purview.
Conclusion
Being adaptable has become crucial in the modern world. Agile is used to help organizations respond to the opportunities and challenges that the modern business environment presents on a constant basis. The capacity to adjust and react to change is known as agility. Agile businesses see change as an opportunity rather than a danger. Agile is intended to be quicker, lighter, and more efficient than any other method in order to develop and support businesses without creating chaos.
Reference:
Carlson, D. (2017). Debunking Agile Myths. CrossTalk.
Hochmüller, E. & Mittermeir, R. T. (2008). Agile Process Myths. APSO'08, May 10, 2008, Leipzig,
Germany.
News Staff, & T. (2021, April 23). 9 Myths About Agile. GovTech. https://www.govtech.com/products/9-myths-about-agile.html
Share This On :