Exploring How Agile Applies To Project Management

Introduction

Frequently when discussing product or project development, you’ll often hear the words Agile and/or DevOps. While these are two different subjects, more and more, they are becoming part of the same conversation. Whenever discussions turn to best practices or approaches to plan and successfully deliver a project, you tend to hear these terms.

But what do they mean? How do they differ and why are they considered complementary? And how do they help? The focus of this blog is Agile. I’ll leave DevOps for another post.

The Waterfall Problem

Agile tries to fix problems that were encountered many times over using the typical planning and development methods used for many decades. Projects were planned and managed using formal and structured approaches with a sequential set of phases which is now called the waterfall methodology.

Waterfall is the term used to describe project planning approaches where each phase of the project was completed, then the project progressed to the next phase. Generally, the phases for waterfall included, requirements gathering, design or architecture, development or implementation, then testing and finally deployment.

Often years had passed between the start of the requirements phase to the deployment phase. And with this passage of time, it was very probable that the original requirements had changed or never even properly understood in the first place.

Frequently, the customer would look at the final product and say, that’s not actually what we wanted or that’s what we wanted two years ago; it’s not going to work now. We needed that feature six months ago. But the waterfall approach is not good at going backwards to deal with new requirements or changes in the business process.

Waterfall has its place where there is a defined need to have independent planning, architecture, construction, and operations phases. But for many projects, this process is too constrained, not responsive enough, not flexible enough and not fast enough. Waterfall also doesn’t adapt to evolving and changing requirements or the need to update, optimize, improve or extend. Hence the birth of the agile approach.

Agile Development

With the various issues with waterfall development, it became clear that other approaches were necessary. That led to the introduction of methodologies such as Unified Process, Scrum, and Extreme Programming (XP). These were ideas, guidelines and suggestions for a more structured approach to project delivery to try to fix the issues encountered with the waterfall approach.

In 2001, 17 people working on these other approaches got together and wrote the Agile Manifesto. The manifesto is very specific with 4 values and 12 principles written in plain, non-technical language. So what’s the difference between value and principle? Values come first in the manifesto that leads to the principles. Values are the things that are most important in the development process. This leads to the principles on how to make those values happen.

From the Agile Alliance, here is the manifesto:

The Agile Values

The values are written as a comparison; a contrast between two things. Prioritization of this over that.

From Project Management Knowledge Hub:

Individual And Interactions Over Processes And Tools

The human resource factor of product development needs to take into account technical knowledge, institutional knowledge, technical ability, productivity, team dynamics, various skill sets and many other things that all play an integral part. Agile asks us to pay attention to the actual individuals on the team, their personalities, and the person as a whole. And more importantly, how do all these different individuals work together, communicate and collaborate. That’s not to say tools and processes aren’t important. They are, but the individuals themselves and how they collaborate are more important to the success of the project.

Working Products Over Comprehensive Documentation

This value recognizes that there was an over-focus on exhaustive documentation where more effort, time and attention was placed on this ahead of the actual product development. Some critics say or misrepresent Agile as not doing any documentation. However, this is not true. Agile promotes documentation whenever and wherever it is needed but does not lose track of the fact that the point of doing documentation is a working product.

Customer Collaboration Over Contract Negotiation

Successful product development needs to be a partner to the business, not just as a service to it and definitely not in competition or conflict with it. Again, not saying contracts are not important. They are, but as an agreement and an understanding, not the defining factor. What is more important is the authentic and continuous collaboration with the customer.

Responding To Change Over Following A Plan

Agile is built on the principle that change will happen. In today’s ever-changing world, there are always new demands, new competition, new regulations, new devices, new business processes, new, new, new. Agile encourages responsiveness and flexibility.

So how do we actually do this? That’s where the Agile principles come into play.

The Agile Principles

I won’t go into all 12 of the principles here as the image below offers a brief description of each. But let’s take a quick look at the first one. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. You can see where this alone is a huge shift from the waterfall approach where it could take years before the final product was delivered. Even the third principle is to deliver working software frequently, from a couple of weeks to a couple of months with a preference for the shorter timescale. Again, a huge paradigm shift.

From Earned Value Management blog by Humphreys & Associates:

In order to support these principles came the need to take an iterative and incremental approach. There was the need to replace the long phases of Waterfall with multiple cycles where each cycle involves aspects of requirements planning, implementing, testing, and deploying. And then start the cycle all over again. This approach allows the delivery of something valuable, something the customer can try and test and then provide feedback. Agile embraces the idea that requirements are not fixed and thus always changing and evolving.

Many of the principles focus on the idea of communication. Communication between the business and the developers, within the team itself, trusting the team, allowing the team to self-organize. And this leads to the conclusion that communication is key.

Other terms that you frequently hear associated with agile are sprints or iterations. These are defined or timeboxed periods of time, often 2 to 3 weeks, where the team builds, tests and releases new products. Within a typical sprint, the team will take a look at their to-do list or backlog, estimate which items can be completed during the next sprint and then start working on them.

Agile is about breaking up the workload into smaller chunks and delivering one chunk at a time. Agile emphasizes technical excellence. Quality is the continuous responsibility of the project team.

Another prevalent part of agile is unit testing; a small automated test that focuses on a single behaviour that the product is supposed to perform. Developers continually write and save unit tests as they are developing, thus testing becomes part of the development itself, not something that is done afterwards. And unit testing reduces the time to release and increases the quality of the product.

Conclusion

Agile focuses on quality, shorter delivery cycles, and faster feedback. However, while the agile principles talk about continuous delivery to the customer, it doesn’t tell us how we can reliably and repeatedly do that, and that’s where DevOps comes into play. Let’s discuss DevOps in more detail in my next blog post.