The Agile Architect

Agile Expressionism 101

Our Agile Architect explains some of the expressions you'll hear in an agile environment.

• By Mark J. Balbes, Ph.D.
• December 5, 2012

I thought it would be fun to talk about the kinds of expressions you hear in an agile environment. I polled the folks in my company, Asynchrony Solutions, and here's what we came up with. As is the case with most things agile, many of these are not new or unique to it. So here they are in no particular order and with no chance that this is an exhaustive list.

• "Great conversation. Not the right time to have it." (Heard during standup meetings.)
  I love this expression. We use it when the team can't let go of a conversation that, while important, is not germane to the standup or other meeting.
  
  
• "We're not robots." (Heard during retrospectives.)
  It's usually said when someone brings up an issue where the team didn't follow some procedure or common practice when approaching a new or unique problem.
  
  
• "Too much process." (Heard all the time.)
  Developers are typically the ones to balk at process. While agile provides very disciplined processes, they are intended to be lightweight. When processes get in the way of developers doing what they know is right, they push back. This provides an opportunity to re-examine your current processes and practices.
  
  
• "Red, Green, Refactor," a.k.a. "Test, Code, Refactor." (Heard during development.)
  This expression refers to the practice of test-driven development. Automated test tools typically use a red bar to indicate one or more failing tests. A green bar indicates that all tests passed. In TDD, you start with a failing test (red bar), write just enough code to make the test pass (green bar), then refactor to a good design.
  
  
• "What's the simplest thing that can possibly work?" (Heard during development.)
  There's a lot of misconception around this expression. You'll often hear developers use this to justify a poor design. In fact, this expression only refers to the "code" portion of "test, code, refactor." During the coding phase, it's not important to have a good design. The developers are trying to figure out the mechanics of making their solution work. How do they get the data they need, what communication protocols should be used, all the technical stuff needed just to get the test to pass. After doing the simplest thing possible, it is important to then refactor the code to a good design so that it is easy to understand, maintain and extend.
  
  
• "Agile doesn't mean be stupid." (Heard from me)
  I'll admit it. I don't think this is a common expression. But I use it all the time. Usually, this happens when someone thinks that the agile rules they've learned are telling them to do one thing when they know they should do something else. It's usually because they are being too literal when applying agile practices or they don't understand why or when a given practice applies. Often, this expression is met with a sigh of relief from the person asking the question.
  
  
• "Shu Ha Ri." (Heard from agile coaches)
  No, this isn't a Klingon expression. It's a Japanese expression for the three stages of learning. In Shu, the student follows the rules to the letter. They may not understand why but they follow the form to gain experience. In Ha, the student starts to break from the rules, doing what's right and experimenting. In Ri, there are no rules.  The individual, no longer a student, understands the reasons behind the rules and does what is right innately.
  
  
• "Do you have a test for that?" (Heard during development)
  This one should be self-explanatory. You don't write code if you don't already have a failing automated test. But it's really easy to forget in the heat of development. This question gets asked all the time in the war room.
  
  
• "ELMO" – Enough. Let's Move On. (Heard during meetings.)
  I have to admit that this isn't a common agile expression. I learned this from a client who already had a mature lean practice. Once our team learned the expression, it only took a few days for our war room to become littered with stuffed Elmo dolls.
  
  
• "You ain't gonna need it," or "YAGNI" (Heard during development)
  This expression is used to discourage coding for the future. While we want to refactor constantly, we don't want to build capability that we don't need today. Chances are, it will never be used, or worse, be wrong and have to be deleted, doubling the investment put into something that is useless.
  
  
• "Are you done done?"(Heard from QA Engineers and agile coaches)
  “Done done” is a common way of saying that the code is complete and it meets all acceptance criteria. All the tests are written, they all pass, the "i"s are dotted and the "t"s are crossed. The capability is ready to be released or deployed with no additional follow-on tasks needed. Many projects are late because all the functionality is "done" but not "done done." “We're done but we just have to...” is the cry of a non-agile team.

This next and final expression is my favorite, mostly because I hadn't heard it before but I like it. This nugget is from an Asynchrony developer and agile coach, Helena Converse. I give you her description verbatim so as not to ruin it.

• "Tomorrow me is going to hate this," or "That's a problem for tomorrow me."
  "I hear things like that said a lot when implementing small goals moving toward a larger one (small features moving toward a larger business feature, stories to a feature, etc.) where implementing one set of new functionality brings to light where refactors/enhancements are going to be necessary to implement the next set of functionality, which will be implemented tomorrow by tomorrow you.  It is quite easy when pulling stories off a board to forget that there is a bigger picture where multiple moving parts converge to form an elegant machine".
  
  "I think about tomorrow me a lot. If you do things more elegantly thinking about the bigger picture, tomorrow me might not have to do anything to finish her work for that feature/story." - Helena

Final Thoughts...
A community's language is a reflection on their values and culture. Looking back on these expressions as a whole, I see a culture of independence, focused on quality, hard work, and a desire to get the job done right and complete.