But we are “Agile”

I’ve heard that phrase many, many times.  Usually it’s used to justify not following the current processes, like mashing sizing and grooming together instead of having separate meetings, or making changes to a story after it’s partially (or fully) developed.

Developer:  The change you are asking for will require re-doing most of the development already done this sprint.  We’ll need a new story for this that we can work on in the next sprint

Product Owner (or any business lead):  But we’re agile, we should be able to make this change now.  You are already working in that part of the code…

It seems like being “Agile” is synonymous with not having to follow a defined process to some people.  In my opinion, this couldn’t be farther from the truth.  Agile works best when you strictly follow your process. Always, no exceptions, ever.  I think that’s worth repeating: Agile works best when you strictly follow your process. Always, no exceptions, ever.

Why?

Notice that it says your process. I’m not suggesting to follow some process in a book somewhere.  Follow the process Your Team created.  Assuming your team is following agile practices, the team has developed a very good process that works best for them, and is constantly reviewing and making improvements. If the business goes around the process, then the team is being robbed of the opportunity to improve it.

If having separate grooming and sizing meetings is too slow – isn’t it too slow for all of the other stories? If changes are needed after development is started, wouldn’t it be better to figure out why we have these late changes and how to avoid them?

It’s better to bring up the cases where the process is not working well and fix it for all stories/projects, not just the special ones.  If the process isn’t fixed, you’ll have to keep going around it every time you have tight timelines (or whatever the reason for breaking the process).

Agile works because it makes it very obvious when part of the process isn’t working well.  Everything is done in very short cycles – grooming, sizing, sprint planning, and retrospectives all happen every single sprint (if you are doing it “right”).  If it doesn’t work well, it doesn’t work well all the time.  People get tired of the process failing and will find a solution quickly.  If the pain is alleviated by not using the process, there is no motivation to fix it, so it stays broken.

My suggestion:

Follow YOUR process religiously.  If it doesn’t work well for something, fix the process, don’t avoid it.

Then, when this same type of issue happens again – your process will handle it. Sure, it might take a couple iterations to find a process that works, but you’ll be on the way to success.

 

Advertisements

How to convert a String to an Enum

The other day I was asked how to take an input string and convert it into an enum.  The individual in question searched the nets to no avail…so, this seemed like a good opportunity to impart some knowledge that is apparently hard to find.

public enum Fruit {
  APPLE("apple"), BANANA("banana"), PEAR("pear");

  private String fruitName;

  private Fruit(String fruitName) {
    this.fruitName = fruitName;
  }

  public convertToEnum(String stringToConvert) {
    for(Fruit fruit: Fruit.values()) {
      if(fruit.fruitName.equalsIgnoreCase(stringToConvert)) {
        return fruit;
      }
      return null;
    }
  }
}

In words, we construct our Enum with strings that represent the particular enum (you could probably get away with just using the name of the enum, rather than adding the string representation).  Then you simply create a convert method that can loop through the values of the enum (which is all of the enumerated values defined, in this case APPLE, BANANA and PEAR), and compare the string sent in to the string representation ignoring case and return the matching enum.

By accessing the enum.values(), you can easily add additional enumerated values without changing any of the rest of the Enum.