Skip to main content

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Jul 10, 2013 — Enterprise Agile Planning expert

Agile “Engineering” Practices, a Cheat Sheet

Enterprise Agile Planning

Every once in a while, somebody posts an article about “The Agile Engineering Practices”.    Usually, it is an article about why we shouldn’t do them, or why they are “considered harmful.”  These articles are often followed up by someone either rebutting or just commenting that the original author clearly didn’t understand these “Engineering Practices” in the first place.  So I thought I would create a little cheat sheet as to what I believe these practices mean.  But only after a little side trip:

I think we are doing everyone a disservice by calling these practices “Engineering”.  As we are starting to discover more about how software is a Craft, not an engineering discipline, we need to change the language.  Just as a brief reminder of what we mean by Craft, take a look at the Manifesto for Software Craftsmanship. We still need discipline, but that discipline takes a different focus than traditional engineering.  Not better or worse necessarily, but different.  So for those purposes, let’s go with Methods of Work.

Now that we have discussed that, let’s move on to a Cheat Sheet for the most highly recommended, yet not so highly understood, Agile Methods of Work:

  • Pair Programming == Working Together – There are very few methods of work charlie_parker_and_dizzy_gillespiethat upset people more than pair programming.  “Programmers are introverts, they can’t be forced to work that way” cry the analysts.  That is true, nobody can be force to work *any* way.  But if we look on pair programming as just finding someone to work with for a couple of hours in the day, it’s just not that bad.
  • Test Driven Design == Creating your hypothesis – Rather than get wrapped around the axle of whether TDD is good or bad, lets talk about what it means.  I am going to make a test to ensure that what I’m about to write works once I write it.  I will still use some understanding of design and architecture to decide what the Test wants to look like, but I will express that design in terms of a test that verifies not just that I wrote the code right, but that the design is supple enough to last.geeks-favorite-e-mc-square-derivation-formulas-cool-timeline-profile-covers
  • Automated Acceptance Testing == Giving the customer what she asks for –

treecustThere are a lot of different methodologies with fancy titles for this one:  Acceptance Test Driven Development, Behavior Driven Development, etc.  The bottom line is that we are going to describe what we want to see the software do, then automate the verification that the software actually does it.

  • Refactoring == Cleaning up after yourselfI don’t know about you, but when I am programming, I don’t always do it perfectly the first time.  I make mistakes, most woodworking11of which the unit tests catch.  But sometimes I just don’t do the best job every time.  I do my best, but that  code that seemed like a good idea the first time around, when I go back and look at it again, probably could have been done better.  Or maybe as my design starts to emerge, I see that I need to clean things up a bit.
  • Emergent Design == Learning on the job – We need to recognize we don’t know everything about how the design needs to end up until we start creating objects and having them interact.  We will start with the best ideas and design we have come up with, but we will also assume that we will learn more as we go.  Another great hellsGateChartanalogy for this came from my colleague Matt Badgley: Unfolding the Map.  Sometimes, we have a map with beginning and end points already understood, but we just need to unfold the map a little at a time to help us see the path to get there.

So there is my quick and easy cheat sheet.  The reason for this cheat sheet is to get past the usual worries around major practices and rules as to how you must or must not do something, and get back to why we want to do it.  I left metaphor off the list, as each item in the cheat sheet is just that, a metaphor.  Maybe there are other analogies that will make others more comfortable with some of these practices.  What else should we add to this list?

More from the Blog

View more
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Jan 27, 2021

Improve visibility, reduce costs, and take back control of your scaled out container and cloud deployments with the latest releases of Agility and DevOps solutions

Enterprise Agile Planning
We’re thrilled to announce the latest releases of our Agili ...
Read More
Contact Us