The changing business landscape
The world is dynamic, meaning that change is inevitable. Industries force businesses to keep up with these changes. No matter how long your project takes to realise, many aspects of your environment will be subject to change. Throughout your project, many changes can occur in your customers, industry, competition or even your team(s). Adopting agile methodologies means cultivating a flexible outlook that adapts to dynamic sectors. It’s called “Agile” because of its ability to accommodate change. Agile methods emphasise partitioning work into iterations, with each iteration delivering a minimal viable product (MVP) or enhancements of said product. The MVP helps the customers experience your product. Despite the changing environment your business is subjected to, the only measure of progress in such contexts is the delivery of the MVP or functionality your customers are expected (or should) use. Agile methodologies are intended to help your team minimise production loss and avoid developing unwanted aspects of your product (or features).
Agile Project Management
Agile project management uses interactive methodologies to plan and steer (or guide) projects. Inspired by agile software development, agile projects complete their work in many small pieces spread over a given period. These are called iterations. Iterations happen in a predictable, cyclic pattern with defined start and end dates (usually two weeks). In agile software development, an iteration implies a software development lifecycle whereby the result is presented to stakeholders and project team members to receive feedback on the use and application of the functionality. The outcome of the iteration is critiqued, and feedback is acquired to determine the next steps in realising the big picture. Validating the iteration’s result is critical in agile software development to confirm or debunk initial assumptions of the developed software.
Agile project management enormously benefits from early insights acquired during the feedback process and issues during the project. Simply put, responding to change could mean the life and death of projects: how will the recently acquired insights affect resources and the budget? When is the expected timeline for the project’s realisation? Can we do the project with the insights we’ve acquired since the previous iteration?
Agile Project Management vs Waterfall
Before explaining agile project management, let’s talk about what it isn’t. There are variable project management life cycle process models such as linear, incremental, iterative, adaptive, and extreme (Wysocki, 2014). The project conditions typically determine what process model makes sense. The traditional waterfall project management style applies the linear process model of project management. Waterfall project management styles depend on a plan-driven approach and are resistant to change—they come with heavy documentation and expectations, rigid mockups, requirements that have been so thoroughly (or not) reviewed, and plans so strictly organised that changing even the most minor aspect of it can cause a cascading effect of unpredictability. Incremental project management process models are similar to linear models: the only difference is requirements and project scope are delivered incrementally rather than all together before the start of the project.
Agile project management uses a change-driven approach. Change is fundamental and encouraged in agile project management approaches—after all, it would be nice to know early if changes in the work will result in unexpected consequences. A business wouldn’t want to continue with everything as planned and not leave room for the unexpected and unplanned. This ongoing collaboration and open communication is encouraged, from those who create the product to stakeholders who have a stake in the direction of the product. There is a vested interest throughout the entire agile project management lifecycle process model. Agile project management improves upon the waterfall (linear) model by incorporating planning as part of the incremental activity and resolves those plans iteratively.
The greater the project’s uncertainty, the more space is required for change. Adaptive and extreme project management process models encourage uncertainty, but navigating the terrain with an uncertain perspective may be difficult. Thus, agile project management has been favoured in most organisations for including small- to large-scale agile project implementations.
History of Agile Project Management
Continuous development, deployment, and integration are not new to today’s vernacular. They have been around since the mid-20th century and have been practised in various forms throughout the decades, championed by visionaries in software engineering and software craftsmanship. While waterfall project management techniques were gaining ground in the 1990s, James Martin’s 1991 publication introducing Rapid Iterative Production Prototyping (RIPP) became the foundation of what is now practised in Rapid Application Development (RAD).
In recent years, the agile methodology known as Scrum has gained significant momentum. Scrum is an agile methodology with three roles: Product Owner, Development Team, and Scrum Master. The product owner works with a development team to create a product backlog, prioritised according to business value in Toliver features, fixes and the overall software to production. The team provides this in rapid increments.
With the increasingly dense and sophisticated world of software engineering, technological innovations, and connected systems, the 21st century demanded an evolved way of navigating the growing complexity. Rapid response is not only expected but desired.
What is Agile Project Management?
Agile project methodologies partition projects into smaller pieces completed in periodic intervals from the design phases, testing, and quality insurance. These intervals are called sprints, a popular term for an iteration used by one of the most popular agile development methodologies called Scrum.
Sprints are typically short bursts of intense productivity that begin and end in intervals of two to a maximum of four weeks. Agile methodologies rely on specialised teams to release functionality as soon as it is completed (and tested). These continuous release cycles allow teams to see the effect of their deployments, and if unexpected consequences arise (not found in testing), they can fix those issues quickly and redeploy.
Agile project methodologies empower companies to reduce large-scale failures and react quickly to uncertain conditions throughout the project’s lifecycle.
How does Agile Project Management work?
Throughout an iteration, agile teams adopt various best practices (quality assurance, software craftsmanship) and continuous adaptation.
Agile teams incorporate and develop an environment that promotes automation, error-free deployments, and early error detection in product development to speed up release deployments and testing procedures. They adopt DevOps best practices (and mentalities) to synthesise an environment capable of continuous deployment, integration, and improvement.
Agile project management requires that agile teams iteratively evaluate their time and efforts as they continue throughout their work. Metrics such as velocity, burndown, and burnup charts allow agile teams to measure their work. Here, agile teams acquire a baseline potentiality of their team’s ability (not all teams have the same metrics).
Agile project management does not require a project manager because the work of the PM is distributed among agile teams (the teams know best how to deliver their work and what effort is needed. From this, teams can synchronise their work in a timely way). A project manager was essential in project-delivery-focused waterfall methods because the company was developing projects, not products. This difference is critical.
Dedicated product owners set the project’s goals on time with an agile team to which their work is dedicated. With the product owner, agile teams handle scheduling, report project progress, and measure the quality of their work. Some agile approaches like Scrum deploy an agent dubbed the Scrum Master, whose role is to facilitate the relationship between the Product Owner and the agile team by removing impediments, streamlining workflows and processes, and simplifying communication to shepherd the project to its completion.
In some cases, agile project management may still use the project manager, except not in the same role that that person once had in the traditional waterfall process. Instead, the project manager is a coordinator and facilitator, relaying information and supporting the project’s development in a more tertiary capacity rather than administering teams. The project manager is transformed into a visionary leader rather than the previously held taskmaster role in the linear process model.
Since agile teams no longer need a project manager to tell them how to do their work and their priorities and evaluate risks, agile project management demands much more from agile teams. Agile teams know how to do their job, what is essential, and when those things can be done, so organisations trust agile teams to steer and determine their work. Companies that adopt agile project management must empower teams to take the appropriate actions and maintain the delivery pipeline at all times. Agile teams must also be able to communicate with stakeholders, product owners, and other teams—social competence is fundamental.
Organisational flexibility
Even now, companies implement complex approaches in an attempt to secure the uncertainties of the future. This method is often rigid, inflexible, and unresponsive to the dynamics of the industry, usually referred to as the „waterfall“ approach. Adapting to the changing milieu helps companies respond to customer feedback, which is crucial to your product’s success. This feedback enables you to implement solutions wherein your customer gains a new (and better) understanding of your product. Throughout the product’s development, especially after introducing it to the customer, wouldn’t you augment the product rather than engage in an entire re-planning process? This is precisely where Agile can help you. Agile methodologies can be scaled according to your project demands, the number of teams, and scope. When using an agile method, keep in mind that:
- Agile does not limit developers to specific techniques or methods. This gives space for your team to innovate and discover optimal ways to implement requirements;
- Agile is flexible enough to permit adaptation to your organisation;
- Agile methodologies employ variable approaches, such as different software development techniques.
The transition phase between each iteration is focused on acquiring customer feedback. Early detection of issues found in your product, from the customer’s point of view, will help you adjust your product accordingly. The team consistently and constantly tests to ensure that customer feedback is seamlessly integrated. When the team receives the customer’s feedback, they use it to determine the context of that feedback and where it fits among their priorities. A common thought is that „there is no planning in Agile if all you do is evolve iteratively“.
In some cases, that may be true. Some aspects of your product may spontaneously evolve without you being aware of its direction. It’s important to give room and possibility for this to occur.
Nevertheless, agile methodologies encourage planning because those plans are flexible and responsive to the environments where those plans are situated. According to Shane Hastie, the Director of Agile Learning Programs for ICAgile and founding chair of the Agile Alliance New Zealand, agile should not cause your team to ignore design principles. Agile still needs analysis to review impactful decisions and assess necessary changes. Shane Hastie said, “There is nothing in the Agile manifesto about not planning the overall structure of the product from the beginning”. This integrated natural alignment towards planning allows agile companies to lower their risk by working on what is necessary and avoiding waste in the process of the project’s realisation.
Agile Methodologies and Customer Feedback
The diagram above represents how the iterations (also called sprints) (could) work. Remember that a cycle, or aspects of an iteration, may be adapted to the team’s purpose. The diagram above is merely an example of a possible iteration cycle. The cycle perpetuates infinitely; there is no end to it (unless the project has come to an end). Each cycle releases a functional prototype, or improvement of the prototype, to stakeholders and customers. The upcoming iterations are based on feedback obtained during review cycles of previous iterations. The ‘requirements’ phase is where the business defines what is needed. This depends on the initial purpose of the project or customers’ feedback on previous iterations. After determining the requirements, the team responsible will begin the development phase. Once development is complete, acceptance tests begin to ensure quality compliance. The team tests regularly and actively throughout the entire engagement of the work. When ready, the developed prototype is released to the customer. Feedback is gathered from customers and stakeholders who use this product. The growing team reviews This feedback thoroughly, and thus, the cycle begins anew.
Apart from changes in customer needs, other changes are expected to occur, such as in the economy, laws, teams, business competition, etc.… It may not be necessary to accommodate all of these industry changes, but some cannot go unnoticed. If these industry-impacting changes are not adequately accounted for, the organisation may suffer the consequences of its neglect. Agile methods help businesses reduce the impact of these unplanned occurrences, allowing them to adapt on the fly to changing organisational dynamics.
Sources:
Wysocki, R. K. (2014). Effective project management: traditional, agile, extreme. Indianapolis, Indiana: Wiley.
