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

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

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

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.

MVP

“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.