Please Stop Misusing Buzzwords

Please. Please, just stop. Stop using buzzwords if you do not know the meaning. Somewhere in the past couple of years “agile”, “lean”, “mvp”, and “scrum” became the “it” thing in the tech world. Everyone wanted to be agile. Every manager wanted to say they use scrum. I’m a huge proponent for these methodologies and practices – look above it says lean all over my page. I think they can really turn companies around and produce great products when implemented and used correctly. But, I have seen a fundamental problem with a lot of teams and people who claim to be agile or lean: they have absolutely no idea what these words actually mean.

Here’s one example of the wrong use of a buzzword gone haywire. During August at Techpeaks, the staff announced they were implementing a “scrum of scrums” every Wednesday. Upon hearing this new plan, I asked myself “What the hell, is that even possible?” If you know what scrum is, you will understand that this term doesn’t even make sense. It got better when they explained that during this “scrum of scrums” we would have a mandatory 2 hour meeting with all 20 teams at Techpeaks where each team would stand up and say what they did last week, what they’re doing next week, and what problems they need help on. At this point, I audibly said “what the hell?” Obviously, this is just a progress meeting to keep track of what the teams are doing, but by using the term “scrum” a whole abyss of misunderstanding opened up. Teams started freaking out that the day for scrum didn’t match up with schedule for scrums that people were doing in their teams. Huge debates started about teams changing their scrum schedules to match the Wednesday end date, or move the Wednesday date to Friday so they can report on what they did. This discussion went on for weeks and weeks, and “scrum of scrums” (which ironically got shortened to “sos”) became a huge point of contention and anger for all the participants.

The misuse of one word, “scrum”, started a landslide of problems. Our common language started to unravel. One group was no longer on the same page as the other, and working relationships became utterly confusing. This is the danger of using buzzwords without understanding the meaning. The words become nothing more than a shiny badge of honor for being “cool” in this industry. Congrats, you are a lean startup and the new hip place to work. But what happens when you advertise this and attract people who actually know lean startup, and want to conduct lean experiments? They will be unhappy, because you will have promised them something different than what they understood. I know, it’s happened to me.

It’s imperative that we cut the crap with buzzwords and start using them properly. Simply launching a landing page does not necessarily make you “lean”. Deciding to chunk up a large project over 4 weeks does not necessarily make you “agile”. There are theories behind all these practices that were lost along the way. So here is my quick refresher on what these common buzzwords really mean and some common misconceptions:


Agile is a set of software development methods that focuses on iterating products incrementally. Agile values continuous delivery, personal interactions over documentation, and close collaboration between cross-functional teams to plan and evolve requirements and solutions. You can read the Agile Manifesto here and the 12 principles of Agile here.

One common misunderstanding I see is when developers require Product Managers to write out a complete, multipage, highly detailed spec before starting development on any products. The first half of the Agile manifesto states “Individuals and interactions over processes and tools. Working software over comprehensive documentation.“ Working face to face inside the team rather than handing off documentation not only creates a more collaborative environment, but it surfaces problems earlier.


Scrum is an Agile framework that embodies the Agile manifesto in its practice. Scrum contains 3 core roles: the Product Owner, the Scrum Master, and the development team. Work is defined and agreed upon by the team and then sectioned off into sprints of a certain length. Scrum values teams working together to complete a common goal, responding to customer’s changing needs, and delivering quickly. You can read more about Scrum practices and values here.

Scrum is not a rigid process, but many teams understand it to be. One very common statement I hear from teams practicing scrum is that once the sprint is planned, nothing can be changed. This directly contradicts the flexible nature of scrum and one of the principles of Agile: “Welcome changing requirements, even late in development.“ This is not to say that you should be changing what you’re building all the time, but learning to be open to changes in product backlogs and deciding if they are a bigger priority is key.


Lean is most commonly used in our industry referring to Lean Startup principles, but Lean originated from the Toyota Production System and the term is also used for Lean Software Development. Using the term just “lean” can get really confusing depending on who you are talking to. For our sake, we’ll stick with Lean Startup Methodology when we refer to Lean here. Lean Startup Methodology focuses on building what customers will use, not what you think they will use. It values eliminating waste, maximizing learning, and measuring results. Iterating through the Build-Measure-Learn loop quickly is the goal.

Many folks miss the maximizing learning part of Lean. They build products quickly, release them to customers, and ask them if they like it. As soon as they get a yes or see a bit of traction, they think they are done. They stop talking to customers, and just keep building. Soon customers are out of the feedback loop. If you are focusing more on building your solution than learning from your customers, you are not Lean.


“Minimum Viable Product” is the least amount of work you can do to learn from your customers. MVPs are experiments, not minimum feature sets. In fact, an MVP can be manually delivered without a website at all. The main goal of an MVP is to learn if customers have the problem you assume and want your solution.

Many people think an MVP is just the minimum website they can create for their product, most often a landing page. While a landing page is a good tool to gauge customer interest, every MVP is not a landing page. A landing page is just one piece of the experiment. Targeting the right subset of users, driving traffic to the page, and delivering results is the entire MVP.

One day, these buzzwords will die down and others will emerge. This whole cycle will start again – learn, practice, fad, misunderstanding. It’s always a good move to educate ourselves and others on new trends, to make sure we understand the deeper meaning behind these words and keep a common language in our workplaces.

8 thoughts on “Please Stop Misusing Buzzwords

  1. One of the main tenants of Scrum is to NOT make changes during a Sprint. This initially seems unagile but it makes sense when you realize that the agileness comes from making changes Sprint to Sprint not during a Sprint.

    Makes changes every Sprint whether that is a two week Sprint or 4 week Sprint is still more agile than traditional methodologies.

    If you accept that Sprints are mutable when started then there is no point in having Sprints. It breaks the idea of Velocity and Working Product. If you move a Story in or out during a Sprint do you half the points? Or.. manipulate things to work now? Part of the job of the Scrum Master is to ensure that the developers aren’t taken off track during a Sprint. Reprioritize The backlog all you want but don’t mess with a Sprint once it’s started. Without that single tenant there is no point in Scrum.

    • There’s actually a lot of contention in the Agile community about Scrum. The reason we implement Scrum is to break down very lengthy release cycles (months, years even) into shorter cycles to get customer feedback faster. BUT we’ve become so dogmatic about changing requirements after it’s planned that sometimes we are too inflexible. If you learn in a middle of a sprint cycle that what you are building is not what people want, do you continue building it anyway? Yes, we should not scope creep or add requirements for the sake of it during a sprint, but we need to be open to feedback coming in from the right places that may alter our final outcome. Why waste time building something that won’t work? But as I said in the beginning, many people find Scrum very “un-Agile”. I see it more as training wheels. When you learn it and can see the reasons in doing certain things and why they benefit you, you should be able to (as a team) change the processes to best fit your work. That may include being flexible in the middle of a sprint.

  2. Erm. Scrum of Scrums is actually a term in the Scrum world (see for example). It’s a scaling method for Scrum where you create a meta-Scrum team, picking one member from each team, and use it as a way to sync teams together.

    This doesn’t sound like what you’re folk were doing though 😉

    • Yes, someone else pointed that out too and I’ve looked into it since. Techpeaks was using it wrong, but I also don’t think I’m completely on board with SoS even if done right. Still listening and considering what might be better.

      • I’m at a place practicing SAFe, and it’s basically a giant sprint planning session + SoS. 2 days every quarter to break down big features and coordinate.

        We focus less on progress, even though we have demos.

        What you were doing isn’t beneficial at all. It doesn’t help coordination, and it does nothing more than expose teams to external criticism bypassing their scrum masters who can no longer block.

        SoS doesn’t do this, it main focuses on coordinating efforts, and individual progress is not exposed. Only team progress, but only for the sake of aligning deliverables.

        (Like, should I continue to work on that app that uses your API if you’re no where near done on the API?)

        Unfortunately, no one has gotten scaling agile completely right.

        But that’s more to do with all these processes not being actually endorsed by Agile itself.

        People like hard fast rules though, even though, in practice they fail most of the time.

        I find it funny that companies are quick to get their ISO certification, as if having a process should be anything more than a fallback to simply using your brain.

  3. […] Please. Please, just stop. Stop using buzzwords if you do not know the meaning. Somewhere in the past couple of years “agile”, “lean”, “mvp”, and “scrum” became the “it” thing in the tech world. Ev…  […]

  4. Back in the ’70’s a co-worker and I decided to do a little experiment. We would take the elevator in our office building, and when someone else came aboard, we’d pretend to be having a deep conversation and use a “made-up” buzzword, then see how long it would take to hear the buzzword played back to us in a meeting. The elevator stopped on the marketing department’s floor, and just as two brand managers stepped on, I turned to my friend and said, “in the interview, the candidate just didn’t seem to have ‘conceptual wraparound’……” By mid-afternoon, I had heard the term “conceptual wraparound” used twice. Little did the people know it meant nothing…..

  5. Thank you! Right to the point !

Leave a Reply