Many of people are familiar with the acronym WYSIWYG = What you see is what you get. It’s a great pneumonic device that describes the expectations people have, versus the product they get. As it turns out, there are a few other great acronyms that describe human behavior patterns in the world of software.
WILIWIK (pronounced “willy-wick”) = “What I like is what I know”. In a technology context, this could mean “I am going to use Java to build this widget. Java is the best. Granted, Java is all I know, but I am fully convinced it is the best, because I don’t like to try new things”. In a business context, this would refer to any general resistance to change: “We’ve always issued a cover sheet for the TPS reports. That’s the best way to do it. Implementing a new policy of optional cover sheets will never work in this company. I like the way I do my job, because it’s the way I’ve always done my job.”
IKIWISI (pronounced “icky-wissy”) = “I’ll know it when I see it”. This refers to the human pattern of wanting something, but having a hard time pinning down the specifics. “I know I want a website that makes me look cool. I’m not quite sure what that means, but I’ll know it when I see it. So…when could you have that built for me?”
YAGNI (pronounced “yag-nee”) = “You aren’t going to need it”. This is a response to the human tendency to want to support every possible scenario that might potentially happen. “We need to build that laptop out of rubber, in case it gets hit by lightning.” It sounds like a good idea during the due diligence phase of a project, but really, how often are you going to be typing feverishly outdoors, in the open rain, in a thunderstorm?
GEFN (prounounced, “gefen”) = “Good enough for now”. Similar to the previous phrase, this comment reminds us that we don’t need to build a Cadillac every time. “Yes, I know you want our toy website to have a video over happy children playing with the toy…for each and every product we sell. But the CEO thinks having only 1 video on the home page is good enough to start selling toys, not that Christmas is only a few weeks away.”
WIIFM (pronounced “wif-im”) = “What’s in it for me.” This is a sort of snide articulation of the need to make the business case for any idea you suggest. Technologists fall in love with their ideas, but often fail to explain why it makes good business sense. “Yes, I know you *want* to rebuild the entire Facebook website using Java (because we’ve already established that it’s the best), but you need to help Zuckerberg understand “What’s in it for me”.
WGLL (pronounced “wiggle”) = “What good looks like”. When a team starts a new project from scratch there are a lot of unknowns. What does a good team dynamic look like for us? What does a stable infrastructure look like for us? What does a good product look like for us? When you get a little daunted by all the unknowns, it can be comforting if the team reminds itself that we are still “wiggling” towards goodness.
WDLL (pronounced ”widdle”) = “What Done Looks Like”. This is from Liza’s comment below. If you ask a team of 7 people whether a feature is “done”, you’ll get at least 7 different answers. Does that include testing? Does that include the Spanish language version? Does that include the data backup? Does that include rolling it out to the integration environment? Sometimes, to clarify the difference of interpretation, you have to hold up a specific example and say “this feature is what-done-looks-lie”.
WSTL (pronounced ”whistle”) = “Who shouts the loudest”. This tends to be the most popular way of deciding which features we build first. An agile environment is one that engages in regular re-prioritization of features in a project or projects in a portfolio. Most managers like to thing they have a rigorous methodology for choosing which stakeholder requests are important, and which can wait. But in reality, humans succumb to pressure, and often the loudest stakeholder is the one who gets the attention, regardless of whether their requests make any sense.
GASP (pronounced ”gasp”) = “Generally Accepted Scrum Practice”. From Ram’s comment below, this describes the group of agile techniques that are added to the Scrum framework to make it more effective in various contexts. For example, User Stories are not a part of Scrum, but are a generally accepted practice to use with Scrum.
WHAT ABOUT YOU? What acronyms have you come across that describe the transition from traditional to agile ways of working?