Agile is a term that generates heated debates within the project management and software development communities. This is because not everyone really understands what Agile is, and many people use the term very loosely and mix it up with project management methodologies and frameworks. Additionally, Agile, like other practices before it, became a buzzword and a cool term that many want to claim they do and want to add it to their presentations and lingo. This article attempts to clear up some of this confusion. First, let’s start with some key definitions.
What is Agile?
Agile is a set of values and principles as defined by the “Manifesto for Software Development,” which emphasizes responding to change over following a plan, delivering smaller increments of working software within a shorter timescale, and actively involving the customer in the development cycle and project team. Agile did not define a specific way for applying these principles in practice.
Before Agile, Waterfall was the dominant approach used in software development projects until the 1990s were some organizations and teams started adopting other frameworks such as Extreme Programming (XP), Scrum, and Kanban that are more closely aligned with Agile principles.
Waterfall refers to the software development life cycle model used for implementing software engineering projects, which follows a sequential process and includes separate phases where the output of one phase serves as input to the next phase. In practice, there can be some overlap between one phase and another, as well as some iteration within a phase and across phases. Basically, following a waterfall approach means that more time is spent up-front on detailed planning, analysis, and design before starting to build the product.
So, where does the confusion come from?
Mixing up Agile with project management methodologies. Many people use the term Agile and Agile frameworks such as Scrum and Kanban loosely and interchangeably and refer to them as project management methodologies. These are frameworks for building products and developing software rather than managing projects. Project management is much broader than Scrum and Kanban and involves all aspects starting from project initiation to rolling out the final product, as well as other deliverables. Project management includes not only defining and managing the process and people involved or needed to deliver the product but also other areas such as project schedule, budget management, legal and contract management, communication, risk management, stakeholder management, and business change management. Scrum or Kanban, if chosen, would be part of the overall project management cycle.
Starting Agile from the bottom up. Many organizations get introduced to Agile by attempting to use it for a specific project without overarching support or adoption of the Agile principles across the organization. This does not work well because adopting Agile should start at the top, i.e., at the organization level. Effective application of Agile principles starts with educating everyone involved, especially the executive management team, about what Agile really is and understanding the related benefits and potential risks; as well as rolling it out throughout the organization in a well-planned and graceful manner. Some key concepts must be understood and accepted by the organization as a whole. For example, using an Agile framework where the business users have the benefit of defining requirements throughout the project and where a detailed design is defined during build means that it is not possible to commit to scope up-front beyond smaller iterations. The organization should be able to prioritize needs effectively and accept rolling out the final product in smaller increments. Also, the organization needs to embrace the idea of following an iterative, incremental approach, self-organizing teams, and active engagement of business users and sponsors in the development process throughout the project.
Many shades of Agile. As a result of the demand for a commitment to scope, not many organizations apply pure Agile frameworks where dedicated capacity (e.g., a team of four people) is allocated or works through a backlog of prioritized business needs. Further, products are not always delivered in increments based on capacity or throughout the project, based on a predefined scope. Instead, most organizations end up following hybrid approaches that apply some elements of an Agile framework (e.g., Scrum), such as using sprints, working through a product backlog and defining requirements and design during the build, and at the same time try to commit to predefined scope and a timeline. Leveraging a hybrid approach is fine and can work as long as this is done within a broader well-defined methodology, and everyone is clear and aligned on the approach, expectations, benefits, and associated risks. In many cases, teams basically go through the motions and ceremonies related to Agile frameworks, but they are not truly practicing Agile principles or following Agile frameworks properly.
In summary, Agile is being used by many as a buzzword and the solution to all problems. Additionally, everyone wants to claim or advertise that they use Agile even though they do not fully understand what it is and is not. This not only results in confusion and unnecessary heated debates but also gives Agile a bad name. Agile starts with educating everyone involved and having full clarity on the project delivery methodology and whether it includes any elements of Agile, as well as ensuring that it is adopted by the organization as a whole properly.
Similar Content:
-
Comparing agile frameworks
-
Agile estimation: Feature and story sizing scales
-
A starter’s guide to agile project management
-
4 Key similarities between Kanban and “The 4 disciplines of execution”
