Chapter 6 - Agile: The Good and Bad

One of the most significant project management revolutions in the past century was Agile. It was created by a prolific group of programmers who noticed that older project management models weren’t well suited to software projects since each software project is so unique.

It revolutionized the IT world and eventually gave birth to practically the entire project management industry. Before that point, “project manager” wasn’t an in-demand job title. People on a project would just manage the projects themselves.

The four key tenets of the Agile Manifesto are:

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

There is plenty of controversy over what Agile is or isn’t. There is much disagreement over whether it has made the industry better or worse. We don’t care about any of that. You’ll form your own opinions on that if you haven’t already.

In this chapter, I’m will talk about the good and bad parts of modern Agile and how they impact your daily life for managing projects.

Good Result: Embracing Flexibility

Before the advent of Agile, most projects demanded that all three project input dimensions be locked in place. People wanted fixed timelines, scopes, and costs.

As we’ve talked about, that’s not possible if there are any unknowns or variables. And there are ALWAYS unknowns and variables.

One of the significant positive results of the Agile revolution is that many more people are familiar with the idea that some variability is necessary.

This is what enables our method of locking in two input dimensions and reassessing the third variable regularly. Because of Agile, most stakeholders are very comfortable with changes as long as they are kept informed about them and have room to make alternate tradeoffs.

Bad Result: Credentials & Project Masters

One of the major downsides is the hyper-academization of project management. Before the Agile revolution, project management was just something that was naturally done by the team executing the project.

After the Agile revolution, we’ve seen tons of training courses, certification programs, and seminars emerge. Most of them don’t offer much actual value. Most of them are a fantastic way to drain companies and individuals of their money and give them little in return. They are pretty damn close to a pure scam.

Similarly, no team actually needs a SCRUM Master or Certified Project Management Professional to succeed. No research shows any benefits to teams run with project managers who have formal titles compared with a project being run by a layperson who has a solid understanding of project fundamentals, such as what I teach in this book.

Good Result: Short Feedback Cycles

Before the Agile revolution, vast reams of documentation were often created before a project began. Then, the team would disappear and work on the project for months and months. Months later, the team would finally emerge with something to show.

This huge feedback delay often meant that what was delivered wouldn’t match what was expected. Sometimes, the documented specifications were wrong. Sometimes, the project wasn’t done correctly. Sometimes, there were massive undiscovered problems that couldn’t be seen until people were using the final output.

After the Agile revolution, people expect to be able to try out the project and see it in action long before it is finished. This is a fantastic thing since seeing a project in action makes it much easier to tell what is working well and what changes are needed.

Very healthy projects provide demos and showcases as often as possible.

The quicker and more often you can get feedback on your project, the healthier and better it will be.

Bad Result: Over-Reliance On Tools and Processes

Ironically, even though the Agile manifesto explicitly says that we prefer “Individuals and interactions over processes and tools,” the exact opposite has happened in most companies that claim they are Agile.

A lot of the time, teams are burdened with company-standardized process rituals, regardless of whether they offer value. Teams are often required to use specific tools, regardless of whether they are helpful or harmful to the project.

I’m not entirely certain exactly how this happened, but I’ve witnessed it at too many companies.

What’s the antidote?

Use very simple tools. Don’t spend much time in your project tools. People should be spending most of their time and energy working on the project.

Continually evaluate your processes. If it doesn’t work for someone on the team, try something else. Processes are meant to conform to the team. The team is not supposed to conform to a process. Feel free to quit any process that people dislike, that makes more work, or that makes the project harder.

Less is more. Simpler is better. Mandated tools and processes are the opposite of Agile.

Good Result: Short Iterations

One significant benefit of Agile is that people realize that a healthy project has momentum. You can tell if you momentum if things are regularly delivered.

How can you deliver progress regularly?

• Very small tasks
• Small feature slices
• Time-boxed Sprints
• Frequent software deployments

It’s better to deliver 10 tiny tasks a day than 1 task. It’s better to have 5 2-week iterations than a 10-week whole project.

On enterprise projects, I have a standing rule that no ticket should take more than 1 workday to complete, from start to finish.

On other projects, I have a rule that says tickets should represent 15-90 minutes of work, and most of them should be towards the shorter end of that spectrum.

Just a few of the many benefits of short iterations:

• They increase the number of feedback cycles
• They capitalize on natural human energy
• They reduce the cost of context-switching
• They yield frequent progress, which gives the incredible feeling of flow
• They ensure that the changes can’t be disastrous since the project is known to have been in a good state very recently

The focus on short iterations and rapid feedback is one of the Agile revolution’s very best results.

Agile Takeaways

Those are some of the best and worst results of the Agile revolution. You may find other things you like or dislike.

My advice is that you shouldn’t get religiously invested in any particular idea or approach. Take the good and avoid the bad.

Find out what works for you.

Find out what works for your team.

Change anything that isn’t working well.

What are the big takeaways from Agile for me?

1. Embrace flexibility
2. Get frequent feedback
3. Aim for short iterations and units of work
4. Don’t be rigid about your tools or process
5. Avoid the Agile Project Management scams and titles

Chapter Review Questions

1. What started the Agile revolution?
2. What are the four key principles of Agile?
3. What are the three most significant benefits of Agile?