Lesson Outline

An Introduction to Agile

The purpose of this lesson isn't really to provide an in-depth guide on how to use the Agile software development methodology, there are countless books, podcasts, and coaches dedicated to exploring this topic and I'm not going to do it justice in a short lesson. We also aren't going to be strictly adhering to any particular principles in this module either, but we will go loosely implementing an Agile methodology for our project management process. The purpose of this lesson is to give a general introduction to what that means, and why it can be effective for us.

It is also worth keeping in mind that I am writing this module with the intent that it is going to be consumed by freelance single developers or perhaps small teams. If you are working in a larger organisation there will still likely be plenty of useful advice here, but the problems larger teams face are different and there is a good chance larger organisations will already have their own ideas and methods for managing software development.

A lot of ideas have built up around the concept of Agile software development, but the core concepts are quite digestible. Basically, a bunch of clever people got together to try to figure out how to approach software development in a better way. This led to the creation of the Manifesto for Agile Software Development which prioritises the following values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

An important note here is that it does not imply that we shouldn't have a plan, or documentation, or contracts - just that the items on the left are more important than those on the right.

This manifesto is also expanded into twelve principles which I will leave for you to read in full, but some key points are:

• Welcome changing requirements
• Deliver working software frequently
• Business people and developers must work together
• Working software is the primary measure of progress
• At regular intervals, the team reflects on how to become more effective

Why should we use this Agile approach? I think Agile done correctly, or even well enough, is just a realistic way to approach software development. It includes the key value being delivered to the client and the typical problems that come up during the software development process as a core part of its principles.

I don't know what they teach in universities or wherever you're learning these days, but when I was doing my Software Engineering degree it was all about the waterfall method. Even if you haven't strictly studied or used that method, you may have seen it at some point, and Agile is often positioned as a sort of "antidote" to the shortcoming of the waterfall method. Where I think that the Agile method is a realistic way to approach software development, I see the waterfall method as an idealistic way to approach software development - it makes sense in theory, but rarely works out smoothly.

Agile vs The Waterfall Methodology

The waterfall method looks like this (it may differ slightly):

Lovely, right? Nice and organised. We get all of our requirements defined, then we design everything, once that is done we build it, and then we test it, and then we just have to maintain it! Everything flows nicely downhill... like a waterfall. The only problem with this approach is that things almost never pan out this way. There is always changes and to some degree you are going to be flowing back and forth between multiple steps in this process.

Now obviously if a software team is in the implementation phase and some new requirements come in they aren't going to just say:

Sorry, too late! We've already finished the requirements phase!

Change requests can still be accommodated for, and teams will likely have ways to deal with this (you might also see a waterfall model design that does have steps flowing back and forth), but it isn't something that is built into the overall methodology. Typically, anything that strays from the waterfall model is going to be difficult and costly.

The waterfall method doesn't account for situations that almost definitely will arise, and this can make the process painful for both the developers and the client.

On the other hand, the Agile method looks more like this:

Rather than progressing from one concrete step to another, we have a continuous iterative process. The product backlog is a key part of this that is created before we begin this iterative process (but it is also continually worked on/changed throughout the iterations). We will continue to talk about the product backlog later, but it is basically a prioritised list of the features that we want to implement (or the bugs we want to fix).

Each cycle in this iterative process will look something like this:

1. Planning: Pull in items from the backlog that you/your team will be working on in this sprint. The goal is to only pull in items that you could reasonably complete within the sprint, which might last 1-3 weeks.
2. The Sprint/Implementation: Work on the items that were defined for this sprint. It is typical to have a daily "scrum" or "standup" where the team discusses things like what they worked on yesterday, what they plan on working on today, and any issues that have arisen. This is generally done in a team setting, but it would also be useful to reflect on as an individual as well.
3. Review: At the end of the sprint you would have a review that focuses on the product itself and you would incorporate feedback from the project stakeholders (e.g. the client)
4. Retrospect: This is similar to the review, but instead it is focused on the development team and processes. Again, this is still useful in a solo context - consider whether there are any processes that could be improved.

At the end of this process, we should have a potentially releasable increment of the application. We might not release it, or demo it to the client, but generally we are aiming to get the software to a state where it could be released in some capacity at the end of each sprint. If the app only has 10% of the total functionality completed, then ideally we would still have useable software - it would just include a very minimal set of functionality which probably doesn't satisfy the clients needs yet.

Where we might complete the waterfall process in 6 months, we might complete an Agile cycle in a week or two. The entire process is completed quickly, and then we do it again, and again, and again. At each point we should have working software that delivers some kind of value. The waterfall process is completed once throughout the life of the project, The agile process might be completed 5, or 10, or 50 times throughout the life of the project.

The great thing about the Agile method is that we can deliver useable software to the client in maybe days or weeks, and use the feedback from that to guide future development. With an Agile approach we either found out we are on the right track, the client is happy, and we continue prioritising what to work on next. Or maybe we deliver the first iteration and it is way off base, the client is not satisfied at all and we need to drastically change direction - good thing we only spent a small amount of time going in this direction!

With a waterfall approach, the client might not see any working software for months, at which point a conversation about how the software isn't what they expected is going to be a lot more awkward... and people are probably going to start reaching for their phones to call their lawyers. This makes the the software creation process much more adversarial between the development team and the stakeholders, as opposed to an agile approach which is a lot more collaborative.

In the next lesson, we are going to take a closer look at what an Agile software development process might actually look like.