If you’re calling it ‘Agile’, you don’t understand …

… and aren’t well equipped to decide if the ideas behind that simple word are right for you or your organization.

TL;DR – Principles of the Agile Software Development Manifesto and Scrum are great for people who believe collaboration is the key to success.  You may find these ideas aren’t for you, or your organization, however, once you understand what these principles really mean. Organizations and individuals who lump these concepts together as, “Agile,” probably don’t understand themselves or the principles. By educating yourself, you can decide if these ideas really are for you.

I won’t pretend that my professional experiences are universal. I believe there are universal principles found in well-articulated explanations of personal experience. Based on my work experiences, as an employee, entrepreneur and artist, I’ve come to strong conclusions about the Agile Software Development Manifesto, Scrum, and the applicability of both beyond Software.

Namely, I think that a lot of people truly don’t understand what those ideas mean, or the purpose of them, and thus end up missing some critical points about themselves and their best selves because of it. To put it simply, as an expert in organizational development and training, if you tell me, “We work Agile,” it tells me, “We don’t know what we’re talking about.

Given how ubiquitous the terminology is, and how many organizations (and people) truly believe, “We’re working Agile,” I think it’s important to understand. Without real understanding, you may be creating misery for yourself, or for the people who work for your organization, without realizing it.

It boils down to a question, which is distilled from the Agile Software Development Manifesto.

“How do we work together better to make good stuff?”

If your values don’t align with that question, if you don’t value collaboration, then these ideas aren’t for you. After you read this, hopefully, you’ll have enough of a grounding to ask the right questions of yourself and your organization to help lead you to success.

  • The Fundamental Question: Does collaboration matter to you and your organization?
  • If you call it ‘Agile’ then that tells me that you and your organization are probably smart, but don’t understand some critical points …
  • Let’s get on the same page: What IS Agile?
  • Let’s get on the same page II: What IS Scrum?
  • What you said about Agile isn’t what my company is doing: AKA, our organization may be failing at working together to make good stuff …
  • You can understand everything about the Agile Software Development Manifesto, Scrum, and still decide it’s not right for you or your organization …
  • Ya On Point about Agile?

The Fundamental Question: Does collaboration matter to you and your organization?

As a person who likes to work with other people, who believes the best works come from collaboration, from people working well together, as someone who believes that the architect who designed the Sistine Chapel is just as important as the masons who built it, is as important as the Pope who later commissioned and paid for the famous ceiling frescos, who are as important as the genius artist who eventually placed those Frescos, I think great works come from people working together. When I saw the Falcon 9 successfully land on a barge in the middle of the ocean, I imagined the hundreds of people who worked together, failed together, learned together, and eventually succeeded together.

It’s an equally valid, if diametrically opposed viewpoint, to look at the Sistine Chapel and think only of the great Michelangelo, and to look at SpaceX and only think of Elon Musk.

But understanding how you and the organization for which you may work views those kind of events tells you everything about yourself, the organization you work for, and the best way for you to work.

In other words, understanding that viewpoint helps people answer the question, “Should we adhere to the Agile Software Development Manifesto, and work with Scrum?”

The key to getting to that question, though, is to understand just what those principles mean. In my experience (after fixing several impaired JIRA instances, and training people on how to execute Scrum and Kanban well), most people don’t understand these simple ideas as well as they think they do.

If you call it ‘Agile’ then that tells me that you and your organization are probably smart, but don’t understand some critical points …

I read these articles on Medium recently, and did a few searches. This piece is less of a response to these articles, and more of a realization that after twenty-plus years of these ideas, there’s a lot of misunderstanding around what these are.

It hit me, like a hammer, that there are a lot of really smart people, who truly believe they understand what, ‘Agile,’ means in the context of software development. Most likely, they understand how their dysfunctions at the organizations in which they work, and have attributed those dysfunctions to the words, “Agile, “ “Agile Software Development”, “Scrum,” and other frameworks.

Like, these very smart, well-reasoned pieces on the topic, “Agile is the New Waterfall …”

… demonstrate that whatever organizations the author has been working in have most likely never read the Agile Software Development Manifesto, or, worse, are missing the point of the various rituals the teams are using to do their work when executing Scrum.

To put it simply, most of the basic ideas are really not well-understood by a lot of smart people. In fact, a lot of smart people take a few plain language word choices, create their own definitions, then misunderstand the principles after this. That’s what smart people do, sometimes. You can be so smart, that you can organize your own thinking around a topic, and completely forgo other people’s explanations. To put this another way, sometimes, you convince yourself, “I’m the best engineer/designer/product manager/project manager around, why should I bother searching on Github for a solution?” And then you accidentally start writing node.js from scratch.

Organizations can sometimes be too smart for their own good. Agile Software Development Manifesto gets shorted to Agile Development, and then simply becomes Agile. And everyone KNOWS what the word Agile means? So, why do we need someone to explain it? Why do I need to read about, take seminars, work in organizations that implement methods based on it?

And then, suddenly, someone who says they worked, “Agile,” before becomes the resident expert at an organization in the implementation of Agile. The team’s start following Scrum rituals, although no one calls it Scrum, because, “What is Scrum?” Suddenly, your team is doing stand-ups, discovering it can’t deploy software at will, and a lot of people end-up unhappy.  In other words, an organization can follow every ritual a Scrum team follows, and completely miss the point of an Agile development process. An organization can follow NONE of the rituals of XP, Eco, LEAN, Scrum, Kanban, SaFE, LeSS, and completely get the point of an Agile development process.

There are certifications, seminars, a plethora of web-articles, and so many books on these topics. Even with all that information, a lot of people still don’t understand the ideas well. Let’s get on the same page about what these ideas mean.

Let’s get on the same page: What IS Agile?

Agile, if properly understood, is a short-hand for saying, “the Agile Software Development Manifesto”, a series of 12 Principles, outlined at agilemanifesto.org published in 2001. You can read about the history of the meeting that produced those 12 principles on their site. Ultimately, it’s about trying to make the best possible software, deliver things in a timely and tangible manner as promised, and to avoid bureaucracy as much as possible.

There’s a strong chance that if you’ve been practicing doing stand-ups and writing user stories at your ‘Agile’ shop that neither you, nor your managers, have actually read the manifesto. It’s definitely worth a read; some solid principles come from it. It takes about five minutes to read.

The good folks who wrote the manifesto summarized their approach into these central ideas …

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

So, great principles, but that doesn’t necessarily translate directly into a plan for working better at your software development company. If you look closely, the principles are all about answering the same question.

“How do we work together better to make good stuff?”

That’s Agile Software Development. You can disagree with the principles, you can have alternate definitions, but there they are.

But wait, what about daily stand-ups? User Stories? Those ideas are encapsulated in Scrum.

Let’s get on the same page II: What IS Scrum?

In the 15 years since the publication of the Agile Software Development Manifesto, a variety of methods for answering that question has come. In fact, a lot of these frameworks predate the publication of the Agile Manifesto, and were topics of conversation at the summit that produced it. You can find a lot of these methods by doing searches on the topic, “Agile Frameworks.” In truth, most of them came from the 80s and 90s and predate the Agile Software Development Manifesto; that applies to Scrum.

Agile Frameworks

  • XP: eXtreme Programming
  • CC: CrystalClear
  • DSDM: Dynamic Systems Development Model
  • Evo: Evolutionary Project Management
  • FDD: Feature Driven Development
  • ASD: Adaptive Systems Management
  • UP: Agile Unified Processes
  • Scrum …

Scrum is the most popular, because of the flexibility of the processes it introduces. It’s so popular that many organizations use Scrum and Agile as if they mean the same thing. It’s also, in my experience, highly likely that organizations that use the terms interchangeably are staffed by people who’ve either never trained themselves, or an organization, in the principles that govern either of those ideas.

Let’s come back to that. In Scrum, a few key principles are roles and responsibilities, and a few key touchpoints.

The Roles and Responsibilities on a Scrum team look like this …

  • A Product Owner …
    • Represents the voice of the customer, and helps to express the customer needs that the Scrum Team needs to fulfill
    • Grooms a prioritized Backlog of Features, which helps create the focus for the team’s deliverables. This means adding new stories when needed, removing stories that are no longer applicable, and ensuring that the right amount of detail is present for the team to be successful
    • Represents Features by User Stories and, if needed, Epics
    • Creates Acceptance Criteria within the User Stories that helps everyone understand when a Feature (or portion of a feature) is completed
  • A Scrum Team …
    • Has all of the people necessary to execute the deliverables needed
    • Works with the Product Owner to opine on the viability of the Features
    • Lets the Product Owner know if the User Story is too broad, too narrow, or requires additional information
    • Takes on work when they understand enough of the User Story detail and acceptance criteria to take on the work
    • Helps size the effort needed for User Stories, so they fit within the scope of a Sprint
    • Breaks down User Stories into Tasks
    • Tries to complete a Task every day, to make progress
  • A Scrum Master …
    • Organizes a Daily Stand-up for the Scrum Team, so the team can report to each other on progress, note what they’re working on (to prevent duplication of effort and allow for collaboration on similar Tasks), and then report any Blockers
    • Removes Blockers from the Scrum Team’s efforts. If anyone on the Scrum Team can’t move forward on a Task, the Scrum Master works to remove that block
    • Helps the team organize a Demo and Planning session
    • Helps the team organize Sprints

There’s a series of rituals that the team then engaged in to help ensure good products are delivered. Most of these should be familiar to people working in the software industry …

Scrum Rituals …

  • Sprint Planning: At the start of a new sprint, the Scrum Team meets with the Product Owner, and goes through the Prioritized Backlog. The team works with the Product Owner, to determine if the User Stories are sufficiently groomed, estimates them, then helps everyone determine how many stories can be taken on within the Sprint. If it’s the first Sprint, the team should also be making a guess about velocity; ie, how long will their sprint be? A lot of organizations typically time a Sprint to be two weeks. The goal of the Sprint is to deliver working software to an end-user by the end of the Sprint.
  • Daily Stand-Up: A 15 minute meeting where everyone on the Scrum team reports to their other team members about three key questions …
    • What did I accomplish yesterday?
    • What do I plan to accomplish today?
    • What, if anything, is blocking my progress?
  • Demo: At the end of a Sprint, each of the team members shows the Product Owner things they accomplished during the Sprint. The Product Owner is responsible for ensuring that the User Stories are accepted (if they meet their acceptance criteria) or rejected (if they do not). Typically, the Scrum Master organizes the Demo on behalf of the team.
  • Retrospective: At the end of a Sprint, typically after the Demo, the team will take some time to talk about what went well, what to improve, and what the team needs to stop doing. This is a chance to make adjustments. Did none of the User Stories get accepted? Then what needs to chance? Was the team able to finish the original Sprint scope early? If so, how do we improve estimates? Was there a lot left undone?

And that’s really it. A few key nuances come from this. If well-executed, Scrum really nails those four ideas from the Agile Manifesto. People are constantly working together, and talking, meaning (hopefully) that individuals and interactions mean more than even Scrum itself (and whatever tools you’re using to execute Scrum). The team strives to deliver working software at the end of every sprint. The team is constantly working with the product owner, and a good product owner is constantly interacting with customers (or other customer proxies). In addition, by slicing the work into manageable chunks, the team responds to change in a way that helps people.

And, if you look closely, you’ll see a meta-principle at work. The team is making all of the decisions. While the Product Owner represents the customer view point, at no point are we saying that the Scrum Team works for them. At the same time, at no point are we saying that the Scrum Team works in a vacuum. By inference, if you’re following the principles well, you’ve hired a team that can self-organize, self-manage, and be trusted to deliver good work in a timely fashion.

What you said about Agile isn’t what my company is doing: AKA, our organization may be failing at working together to make good stuff …

As previously noted, a lot of companies may use Scrum and Agile interchangeably. If they are, then they’re taking two very different concepts and using them interchangeably. While Scrum is a great way to execute those 12 great ideas from the Agile Software Development Manifesto, it’s not the only way to do it. While the rituals of Scrum are a great way to build software, it’s use doesn’t mean that your shop is automatically ‘Agile’ in its organizational practices.

Understanding those principles is important. If a company truly means what they say about being “Agile” it means they believe in working together with different people to build good stuff.

It’s important when you’re walking into a new organization, or thinking about the current place where you’re working, to ask some questions around this.

Like, a company may say, “We’re Agile.” You should search for common meaning around that term. Ask probing questions.

“Do you tend to think processes are more important than people? Like, if a whole team felt they couldn’t deliver really good software using all of the processes that the company has outlined, what would you do? Or if your customers hated collaborating with the development teams, would you stop?”

Think about those questions, and how an organization might answer them. Like, imagine this scenario …

“If we didn’t think this worked, or if a team didn’t think it would work, they have the freedom to do it differently.”

Okay, that says a lot. It says that the company tends to favor a certain amount of chaos over structure. In theory, that sounds great! The company is willing to let teams pivot to whatever method they think will work. It also means that if 4 out of 5 teams are successful with the current methods, and happy with them, that the company is willing to let those teams suffer at the hands of the fifth team that hates the structure and can’t work within it. So, expect that there’s going to be constant disruptions at code merges, and that teams may not collaborate well with each other, or at all. In other words, the company favors a chaotic process (ie, a process of constant change) over the happiness of the people working there.

Imagine another scenario…

“No, it’s important that everyone sticks with the method. It works for us, and we think it’s important that they execute against this.”

That also says a lot. It says that the company potentially favors process over people. The organization may be rigidly adhering to certain rituals, and be primarily concerned with a team’s sprint velocity (and the predictability of multiple team velocities) over working software and the collaboration of people.

Imagine a third scenario …

“That’s an interesting question. I think it’s a balance. We like to work together here, and we found that Scrum is the best way for us to work together. If you like to collaborate, this is a good place for that. We liked Scrum because it has built in mechanisms for improvement. It gives the teams some room to change. At the same time, it also creates the right amount of structure. Teams can work with each other, and know that there’s some universality to processes, so it helps to manage chaos. So, I don’t think we’d stop. But I like to think we’d respond, and try to make things better for that customer. Or, alternately, maybe let that customer go. I mean, maybe the way we’re working doesn’t work for them. Ultimately, we just want to make good products for people, and get them in their hands at high quality, as fast as we can.”

I’ve heard various versions of all the above in my career; at this point, it helps me know what I’m walking into when I go to work for or with new people.

If you find an organization that says a variation of the above in response to a variation of the original question, it also says a lot. It means the organization balances structure against the needs of the people doing the work. And it values quality.

Maybe you’re thinking, that company sounds like a unicorn. Or that it sounds impossible. Or that you don’t care about any of this. That gets us to something important …

You can understand everything about the Agile Software Development Manifesto, Scrum, and still decide it’s not right for you or your organization …

With so much misunderstanding about Agile, Scrum and more floating out in the world of software development, it’s important to understand something critical. You can do the work to understand. Your organization can do the work to implement the principles. But maybe, just maybe, the principles and frameworks aren’t right for you.

Look again at how the Agile Software Development Manifesto boils down …

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

Does any of that MATTER to you?

Perhaps you are an iconoclastic, genius product manager. If you think of yourself, or actually are, a kind of a Steve Jobs type, do you care customers? There’s a famous quote from Steve Jobs, on customers …

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” – Steve Jobs

Think about that. If you look at that, and think, yes, of course, then do you really care what your customers think? Do you care about working software over documentation? Like, think about the NeXT computer, launched in 1990 after Steve Jobs ouster from Apple. How many presentations, commercials, images, marketing documents, preceded the launch of the product? In other words, there was a time when Steve Jobs didn’t appear to favor working products over documentation; the NeXT (arguably) was ‘late’ to the market. It was also very expensive; the customers for which the product was theoretically designed (educators) couldn’t afford a $9,999 work station. It was also a beautiful, cutting edge, amazing product. It showed, in its way, what the coming iMac could be (once Jobs returned to Apple).

Sometimes, people think of Steve Wozniak, as a sort of contrasting figure to Steve Jobs. But, like Jobs, he shares a striking similarity when it comes to customers and collaboration. If you think of yourself, or actually are, a kind of Steve Wozniak, do you care about customers? Steve Wozniak said something bold, and all-inclusive, about engineers. 

“Most inventors and engineers I’ve met are like me — they’re shy and they live in their heads. They’re almost like artists. In fact, the very best of them are artists. And artists work best alone — best outside of corporate environments, best where they can control an invention’s design without a lot of other people designing it for marketing or some other committee. I don’t believe anything really revolutionary has ever been invented by committee… I’m going to give you some advice that might be hard to take. That advice is: Work alone… Not on a committee. Not on a team.” – Steve “Woz” Wozniak (from his autobiography ‘iWoz…’)

If you found yourself nodding along to this, and agreeing, then stop for a moment. Remember, Woz wasn’t saying, “Every engineer is like this …,” he said, “Most inventors and engineers I’ve met are like me …” And he says he likes to work alone. He also says that artists work best alone. There’s truth in that. If you’re a painter, a potter, a sculptor, a stand-up comedian, a polyglot engineer, or in any number of myriad artistic disciplines, maybe you do work better alone.

But just know, not every artist does indeed work best alone. Comic books are often produced in teams. Plays require teamwork. So do movies. TV shows. If you see an episode of Sesmea Bands are called Bands because they represent a group of musicians who’ve chosen to work together; Questlove may (arguably) be the most famous member of The Roots, but he’s not the only guy in the band. You may argue about whether John Lennon, George Harrison, Paul McCartney or Ringo Starr is the ‘real’ genius of The Beatles, but all four of them are required to make The Beatles. At the same time, The Beatles are not required for, “Imagine,” “While My Guitar Gently Weeps,” or, “Live and Let Die.”

This idea also applies to the Product Managers. Both quotes show a disdain for ‘design by committee.’ The phrase conjures a nightmare of cold business people or uncaring groups mangling the genius work of another artist. But they also, potentially, show a disdain for any kind of collaboration. Working together with other people isn’t, on its face, bad. Neither is working alone.

Rather, those are preferences people have.

And its a bias organizations can have as well. Organizations that don’t like their customers, or, that (maybe for very good reasons) truly believe that their customers don’t know what they want, are not the best places to implement principles from the Agile Software Development Manifesto, Scrum, or any other kind of collaborative software development framework and practice.

If your company says, “We reward collaboration,” but then only ever rewards individual performance, then it’s effectively saying, “We say we reward collaboration, but we really only reward individual effort,” then why implement collaborative working methods?  Are you becoming an, “Agile,” shop in order to stay competitive, because everyone else is doing it? Or, are you adhering to the, “Agile Software Development Manifesto,” and choosing a collaborative development framework because you value collaboration and making great stuff? Does your organization find the idea of a fully empowered team, working on their own (and collaborating with others only when necessary) too risky? Does your company find that idea so risky, that they’ll put up roadblocks that prevent a team from working independently? If so, these ideas aren’t for your company.

In other words organizations need to decide how important team work, collaboration, empowerment, and group efforts really are to do the work they do. If you don’t need it, or worse, it gets in the way, then don’t do it.  

And at the individual level, the same question applies. If you think, or truly are, a multi-talented genius business development person who can build products out of your own head better than anyone else, why are you trying to work with an engineering team? You should just hire people to do what you tell them to do. If you think, or truly are, a multi-talented genius engineer who works best on their own, why are you trying to work with other people? You should just build your own software, on your own schedule, and not worry about working with anyone else.

None of that has anything to do with methods, or work, it has to do with knowing yourself, and understanding your values.

Ya On Point about Agile?

The moment you start saying, “Agile,” is the moment you’ve started the process of confusion, and the moment you should ask yourself, “Do I really understand how I and my organization works best?”

Great work requires truly understanding yourself. If you find that individual effort is the key to success, or your organization doesn’t trust in the empowerment of teams, then stay away from ideas based around team collaboration and empowerment. They’ll make you, or the people in your organization, miserable and rob you of success.

If, however, you believe in collaboration, trust, and that great work comes from real teamwork, then the principles of the Agile Software Development Manifesto and Scrum are probably for you. Learn as much as you can about the topics, to implement them in a way that helps you find the answer to the question …

“How do we work together better to make good stuff?”

If you believe in working with other people as the best way to make good stuff, you will find success when you find your answer to that question.

Important Stuff About Me That Is Important!


Fred Chong Rutherford, that’s me, has been working on the internet since the late 20th century in a variety of digital product and project management roles. I’ve been very lucky, and gotten to work with a lot of smart, incredibly talented people over the years to make cool digital stuff. I spend my time thinking about technology, people, and the how to look sideways at problems to find the best solution. I’ve been lucky enough to work with clients like Amazon.com, Nintendo of America, EA, Tetris Online, NBC Universal and Xbox over the years. I’ve worked in product and project roles for a few companies, including IDT, The Topps Company, Viacom, Time, Inc and some start-ups. I’m currently at American Express.

Short films I’ve written, produced and or directed have appeared at film festivals around the world, including The Kino Short Film Festival, San Diego Comic Con, Seattle Asian American Film Festival, Seattle International Film Festival, Satellites Independent Film Festival, StockStock and more.Short films I’ve written, produced and or directed have appeared at film festivals around the world, including The Kino Short Film Festival, San Diego Comic Con, Seattle Asian American Film Festival, Seattle International Film Festival, Satellites Independent Film Festival, StockStock and more. I also love puppets, and do my best to help the Thigments make the videos they like to post on YouTube. I live in Brooklyn, NY, because it’s awesome. Twitter | Facebook | G+ | Instagram | IMDB |

“You on point, Phife?” – Q-Tip
“All the time, Tip.” – Phife Dawg

Also published on Medium.