You may have heard about the agile framework or the scrum methodology in today’s technology driven world. But, what is Agile and what does it mean to apply the agile framework to projects? Should your team use it? What’s the right approach when using agile? I hope to answer all these questions and more throughout this blog series: Insights into Agile.
To develop a foundational understanding of the “Agile Framework,” we should start with a basic definition. Agile is a set of guidelines for how to manage a project in an incremental and iterative fashion, as opposed to the traditional, plan-driven approach (also commonly referred to as waterfall project management). Scrum is a version of agile that is typically used in the software development world (and where I have my agile expertise), but its principles can be applied to any teams working in an agile manner.
Waterfall project management focuses on a set, sequential path of work. For example, in a software development project that is structured based on a pre-defined plan, you might have different phases for requirements analysis, design, coding, testing, and deployment all taking place in a sequential manner. In Agile, we focus on slicing the project efforts in to smaller chunks, and completing all phases for a piece of functionality within a pre-defined time period called a sprint. At the end of each sprint, a deliverable of the project is presented, and the team works to plan the next sprint’s work. Waterfall keeps various roles more isolated, in that they become a part of the process when their phase is in process. In contrast, Agile keeps the same team involved from sprint 1 to the end of the project, working in parallel to deliver complete sections of the final product within each sprint.
There are many benefits that support the use of an agile approach for projects. The first and perhaps greatest benefit is that agile offers a flexibility in projects that waterfall management styles simply cannot offer. In waterfall project management, you plan for the entire project from day one to completion. You have a set roadmap of what will be done when and by whom to meet your timeline. With agile, you only plan the work for the next upcoming sprint (typically 2 weeks to 30 days of work, depending on the project size and complexity). This allows stakeholders to update the priority (and in turn, schedule) of work to be completed as the project continues. It also allows for requirements to change throughout the lifecycle of the project, something that is a big no-no with a plan-driven approach.
Agile focuses on delivering complete slices of a product within each sprint increment. This means that you don’t have to wait until the project is finished to begin reviewing and using its features! Within weeks you can begin to see what your product looks like. This allows for the project team and stakeholders to review portions of an overall project/product to ensure expectations are aligned between all involved. This process allows for risks to be addressed more quickly, and to course correct as needed earlier in the overall project timeline.
Finally, Agile allows for projects to be suspended when it makes the most sense. With plan-driven approaches, requirements are locked in at the very beginning of a project, and there is a defined set of deliverables that should be completed by project end. However, throughout the life of the project, the team may determine that some of the agreed upon tasks will not generate a great enough return on investment, but you’re stuck completing the unnecessary work to complete the project according to plan. With the flexibility of an agile approach, the project stops when the next highest priority work in the product backlog will not generate a great enough return on investment to justify the work. No more wasted time on fulfilling meaningless requirements with an agile approach. We’ll cover how to prioritize the product backlog in a future edition of the blog series.
Agile project management is best when used in projects that are unmanageable using defined processes – typically when requirements are uncertain and technology risks are present. Agile also works best when team collaboration is both possible and encouraged for the project at hand. When determining whether to use agile or plan-driven project management, consider if your requirements are well understood and the level of technology risk you may encounter. You may also want to consider if the benefits described above would increase the likelihood for a successful project over a plan-driven method. Is the team co-located/can they collaborate as needed to plan the project iteratively from sprint to sprint? The answers to these questions can help you determine if you should use agile or not.
The agile framework provides a structure of various roles, meetings, rules and artifacts, which will be covered in the blogs within this series. Each of these are simply recommendations, but the approach itself is flexible and is designed to be adjusted for what works best for each organization. Take them as guidelines rather than hard and fast rules that should always be followed.
