No one is going to read this or anything I write.

This is an example of a fallacy. I could accept it as accurate and use it to drive my decisions and behavior. Here, the fallacy causes me to stop writing, climb into a digital cave, and never come out. But, by acknowledging and managing the fallacy, I can be the digital presence I want to be: Namely, someone that occasionally writes to share and gain knowledge.

According to the Dictionary app on my Mac, here’s the definition of “fallacy:”

| a mistaken belief, especially one based on an unsound argument:

Because I am the absolute ruler of this article, I would like to amend the definition to:

| a mistaken belief, especially one based on an unsound argument that is generally accepted as true and drives behavior

In other words, a fallacy is something we all accept as true and use to make decisions but ends up being wrong and biting us in the back end (especially if that back end is ColdFusion. HEYO!)

The software universe stands on so many fallacies. My muse for writing about this subject stems from L. Peter Deutsh’s 1994 “Eight Fallacies of Distributed Computing." This enduring list includes items like “The Network is Reliable” and “Latency is Zero,” which every team supporting distributed computing has presumed at one time or another. As I reread the list, I started to think of other areas of development where fallacies wreak havoc. Agile popped up immediately.

In about 24 seconds, I had a list of fallacies. Keeping the list short became challenging, making me wonder if the phrase “The list of agile fallacies is finite” might also be a fallacy. Here’s the list (in no particular order)

Note: I use “Agile” as a noun throughout this list. I know it’s an adjective, but it’s just easier to make “Agile” and “Agile Software Development” synonyms. So please find it in your heart to forgive me.

Agile Will Solve All Our Problems

As software began to eat the world and companies struggled to build software effectively, the Agile Manifesto emerged as a beacon of light. The momentum behind Agile spurred a massive industry of books, training, and consultants, all showing that Agile Software Development will make you whole as a software team. This is the most insidious lie around Agile development.

Agile is not here to give you the one true working process. Another team’s Agile ways of working will, in all likelihood, not work for your team out of the box. Agile is a starting point and a method of evolution. It can show you where the bottlenecks are for your team, but Agile will not fix them. Your team must address them in a way unique to them. This is the promise of Agile: it can show you what’s not working, but you have to fix it.

Moral: Agile is a guide. It is a set of goals and objectives. It is not a silver bullet; if you treat it as such, you are ceding too much responsibility to the process and are about to have an additional set of problems.

The Users Know What They Want

Discussing your plans with target users is an excellent idea. They will enthusiastically tell you what to build if you plan to solve their problems. The passion and detail streaming from their mouths paint a tool that will make them ecstatic to do their job.

Here’s the thing: They’re almost assuredly wrong.

When you show them the app, they don’t want it. It’s not right, even though they thought it was in those user sessions so long ago. Why doesn’t it do this and handle that use case? Who on this earth told you this is what the users want?? So now, you have a totally different set of feedback and a need to pivot the product.

Moral: User testing is not a one-and-done event. No matter how sure your users are, they don’t know what they want. Build a little, show a little, get a little feedback, and make a little change. Rinse, repeat. If users don’t see progress regularly (think weekly), then the risk of product misalignment increases.

We’re Building the Right Thing

This is a variation of the previous fallacy, where a group of people designing and building the product think they know what the users want.

They don’t.

Maybe they used to be in the user group, and that’s why they’re on the team. But, trust me, they don’t know what the users want if they have not asked them recently. I see this often in enterprises, and it is a product killer.

Moral: Talk to the users and show them your progress frequently. Again, interacting with the software drives out the most valuable feedback.

Team Roles And Responsibilities Are Understood

This fallacy happens with more experienced teams than those new to agile development. First, everyone on the team gets a role (like Product Owner, Tech Lead, etc.), and each person knows what those roles mean from previous projects. However, each team is different. So, assumptions about who is covering specific responsibilities arise. Then, weeks later, as tasks are left undone and unplanned work overwhelms folks, it becomes clear that the team is not aligned.

Moral: At the beginning of the project, spend a few hours mapping people to roles to responsibilities and document it. Each week or so, retro the work done and the team’s expectations. Look for unplanned work or unmet tasks and adjust. It helps immensely if team members understand how the Agile process works.

Only the Product Owner Needs to Understand the Business

In Daniel Pink’s book Drive, he identifies Autonomy, Mastery, and Purpose as the three most significant contributors to a person’s morale. The last one, Purpose, encompasses the “why” and impact of the software. If developers, testers, or anyone on the team doesn’t understand how this product makes life better for its users, then they don’t know what value to create. A result is an uninvested group of order-takers that just want to get through the next feature on the list.

Moral: Create a Vision for the product with the team, and then use that vision to drive decisions. Revisiting the Vision often so the team understands the why. In the book The Fifth Discipline, the author cites a shared vision as foundational to success and says, “It’s not what the Vision says, it’s what the Vision does.” Connect the impact of the software to the work of the team.

Our Development Process is Fine the Way It is

When a team starts development, they bring their ways of working, policies, and experiences to the new project. These ways of working get pieced together into a development and deployment experience. Unfortunately, most teams never look at improving this initial approach unless things are going poorly. As a result, workarounds emerge, unplanned work grows, and team morale plummets. New team members accept the status quo, thinking workarounds are just “how it’s done.” So, instead of fixing and automating, they sit and watch.

Moral: Improving how you build is as important as what you build. Set constantly improving goals and performance standards for your team and strictly stick to them. Then, look at the process and improve the slowest or most tedious or time-consuming parts. Your development pipeline is the engine of your product, so maintain it properly.

Project Rituals Are Project Management

When Spotify released its “Spotify Engineering Culture” videos, it took the software development world by storm. Everyone started applying the “Spotify Method” to their teams, thinking it would make them as good as Spotify.

It didn’t.

The number of teams I’ve seen adopt Agile rituals without any clue about why the ritual exists is staggering. I call this “Agile for Agile’s Sake,” and these are the teams that give Agile work a bad name. The most egregious example of bad execution is the Daily Standup. So often, it becomes a worthless recap (“I am working on JIRA3442…”) of what each person is doing or a long gripe session when it should be a way to check in with reality, update the schedule, and uncover bottlenecks.

Moral: Understand why your team does what it does. In fact, let’s stop calling them “rituals” and ensure we are getting value out of every meeting and task. If you start your Agile process where your team is today and focus on incremental improvement, the process will better match your team. On the other hand, if you copy and paste someone else’s process, you will have a team thta doesn’t understand what is happening.

We Need a Huge Process (or, Process Size Is Important)

Enterprises are, by definition, big companies. Big companies need big processes. This reasoning leads enterprises to go from not working Agilely to SAFe 4.0 in weeks. Rolling out a new, giant process like this isn’t easy and takes a long time. As I’ve often heard, Agile is an evolution, not a revolution. Start where your teams are today and evolve; you’ll increase success tenfold.

Moral: Before you pay to learn some extensive Agile process, consider starting more simply (Kanban has some great ideas here.). Pick a team, understand and map their current work, start with a simple process, and begin a series of minor improvements. Evolve.

“Done” Does Not Mean Production

Most Agile teams spend time creating a “Definition of Done” for user stories so everyone understands what “done” means. Sadly, these definitions usually don’t include production deployment. This is a mistake. A story or feature remains undone until it’s in production being tested and generating user feedback. Deploying to a QA or non-production environment is not “done.” Making production part of “done” pushes the team to maximize the flow of work, deploy smaller batches, eliminate deployment pain, and generate feedback from real users. The benefits are remarkable.

Moral: Done means “deployed to production, tested in production, and performing well” or it’s not done. Add whatever criteira is appropriate to your project, such as i18n and a11y testing, etc. but in production is the bare minimum.

We Can See All the Work or The Map is Reality

A well-known mental model is “The Map is Not Reality,” meaning frequently checking in with the real world is required. In development, teams cranking out features without checking in with metrics and users find themselves well off-course. Also, most teams have someone doing unplanned work or tasks on the board. It’s essential to find these items and make them visible and automate them away. These speed bumps or roadblocks won’t be on your map, but they are in reality and will slow your team to a crawl.

Moral: Regularly ask the team if they are doing unplanned or not visible work. If they are, figure out how to address this work or put it into the plan. And if it’s not clear by now, regularly check in with actual users using your software.

Development is a Commodity

Many product teams spend weeks or months on discovery. They employ product strategists and designers to create journeys and mockups. User testing happens, and the product starts to take shape. Once the backlog is in place, product folks hurl it over the fence to a faceless mass of developers. Then, the issues begin to mount:

• The designs are not feasible.
• Thanks to new tech, a better approach will make the product more user-friendly.
• The features are done incorrectly because the development doesn’t have enough context.

Turns out, the development team is an important source of feasibility during discovery.

Moral: Developers should be involved in product discovery. They are more in tune with what is possible technically and are often an excellent source of creativity. This is shifting your developers to the left in the product life cycle. Pulling them into discovery (strategy and design) efforts allows them to bring their perspective, understand the domain, and reduce issues during development. Also, read The Mythical Man Month if you want to understand what huge development teams bring to the complexity table.

And….one more bonus fallacy…

The Team Will Stay the Same

The start of a project is so exciting. It’s a new team; everyone is talented, and you can’t wait to build the thing that will change the world. The team learns and builds together, so everyone has a solid grasp of the domain and product. All decisions are well-understood because the team made them together. Everyone works well together, so why would anyone leave?

Then, someone gets a can’t-pass-it-up job offer, and the well-oiled machine grinds its gears. The team has to onboard a new person, but there’s no documentation on how the product evolved or the business’ need. No architecture description, decision records, explicit policies, or code standards exist. Now, someone has to walk the new person onto the team, which takes time and slows down the whole project.

Moral: Take time to consider what it would take to onboard new people. Then, each new person makes 1-2 improvements to the onboarding process. Make sure there’s a continuously improving process in place. Documentation is not optional in Agile, so be sure your team has an approach to keep team and application documenation up to date. Now, when the inevitable happens, the disruption is minimal.

Avoiding the Fallacies

The list of morals for the fallacies above gives rise to a few methods to avoid the traps. And good news, the techniques are simple to understand:

Start Where You Are

As previously said, Agile transformation is an evolution. So before you take the journey, create a map, identify potential issues, look for alternate routes, etc.. Kanban suggests every team start with a Value Stream Mapping exercise to understand what work is happening, who is doing it, and where the current issues lie.

Use this list to plan the first set of improvements, and you’re off.

Check In With Reality

A healthy agile process includes feedback opportunities, such as user testing, design mockups, unit and integration testing, QA environments, and production metrics. The feedback drives new decisions, process changes, and product improvements. In other words, the feedback keeps the team looking at reality.

Improve Incrementally

How do you manage uncertainty? You move slowly. Create just enough to generate meaningful feedback and see where that leads. This way, the product edges forward toward success and user happiness. Deploy to production in small batches.

Again, it’s simple, but it’s not easy.