Agile Overview

Purpose of this section

To explain an understanding of agile methodology based on my training and experiences  so that teams can use this for training. There is a heavy bias towards execution based on software development.

Waterfall and Agile Are Not Opposites

Waterfall Background

When people talk about Waterfall and Agile methodologies, the assumption is that they are opposite: this is not true. However, they are often pitted against each other. I believe one is an evolution of the other and each serve their purpose. The result is the same; a working, valuable product is produced.

Let's take a deeper dive. 

Product developments usually have the following product stages:

1.  Requirements: Obtained from customers and stakeholders

2. Design: Perform technical designs and planning

3. Build: Execution

4. Test

5. Deploy 

The first versions of phase-gate (Waterfall) methodology was developed when companies pushed forward with projects even when certain stages in the process were incomplete and failing. Some requirements weren't found so the designs didn't incorporate them: nobody realized this until the product was being built. If your team were building a hydro-electric dam or a factory, then mistakes made in your requirements would lead to cost-overruns, financial ruin, and people losing jobs. The build stage is the most expensive period and you don't want major mistakes at this point. 

In response, the traditional waterfall process was implemented so that leaders could evaluate a project at each stage before going to the next. Mostly, you wanted to ensure your designs were completed upfront. It's great for $100 million projects when you've collected all the requirements. Waterfall was adopted everywhere.

Ideas from Agile Manifesto

However, it is clear that waterfall processes cannot be used for every product. It is difficult and expensive to gather 100% of requirements upfront from customers. Furthermore,  opinions or circumstances change in this dynamic world, and suddenly initial requirements are no longer valid. As a result, teams and leaders get frustrated with traditional waterfall processes because it does not address change very well. The results are finished products that aren't valuable. 

Enter the Agile Manifesto.

With the advent of new technologies for prototyping and the acceleration of software and digital tools, teams could take the typical product stages and turn them into cycles of customer feedback and improvement. This was especially the case in software development where the internet accelerated rapid delivery such that you could develop and test features using real customer feedback. This way, you could focus on satisfying the customer and try to reduce the risk of delivering products that no one wants to use.

The Agile Manifesto was released providing principles for teams to follow in response to the inadequacy of traditional methods. Here are a couple of its ideas that compare Agile principles vs traditional ones:

• Focus on individuals and interactions > process and tools

• Deliver working software > comprehensive documentation: do not over-document

• Working product > planning

• Customer collaboration > contract negotiation

• Responding to change > following a plan (assuming it is static)

• Simplicity: maximize the amount of work not done.

  • A task is either done or not done so make it easy to get things done.

  • Minimize/eliminate "work in progress"

• Learn and adjust

What Agile is Not

• Agile is not a single methodology. The release of the Agile Manifesto led to a dozen or more Agile Methodologies: Scrum, SAFe, Kanban, Lean, XP, DAD, FDD, Open Agile, etc.

  • Note: Kanban is an implementation of Lean. Lean methodology is about making a process less wasteful and more efficient so it's not quite "Agile", but they share principles. 

• Agile is not a set of tools. It is not the piece of software that helps you manage Agile. Using it doesn't mean you know how to run an Agile process.

• Agile is not the opposite of Waterfall. See above.

• Agile is not easy to master. Agile methodology requires buy-in and training for the whole team, including executives. Often times, it is very disruptive for people who've worked in traditional companies and is very difficult to implement. However, most modern software teams have experienced working in Scrum Agile. Given there are many flavours of Agile, the product leader must pick one and enforce discipline with clear guidelines. If not, then it turns into chaos.

• Agile is not new.

• Agile is not a quality output. It is up to the Agile team to agree to the definition of done with the product leaders and designers helping to define quality (including code). However, Agile processes do help by encouraging feedback.

• Agile is not without planning. Yes, continual planning is required in Agile, despite what some people falsely believe. I wrote an example about this in "Your Headspace" section, where planning didn't continue. Also, see the next section "Scrum Agile at Scale".

• Agile is disciplined. Because a working software feature is either done or not done, there's no room for ambiguity. Discipline is required to get the whole team to be self-enforcing and very strict about this. Bad experiences with Agile is because of a lack of discipline, leadership, and communication. Read the next section on creating communication feedback loops.

• Agile is not unproven. It requires the product leader to set expectations and to train team members to make Agile works. Thousands of software teams and millions of people use a form of it.  

• Agile is not faster than Waterfall. It's a massive misconception that Agile will produce products faster. Instead, Agile is supposed to produce iterations of working product so that you can test it with customers to get feedback. It enables you to adapt to changing requirements earlier and more frequently. It can indirectly lead to faster delivery.

See next section for continuation of thoughts: Scrum-Agile At Scale.