Saturday, August 27, 2011

Back to the Future!

At the conclusion of the Agile 2011 conference, Todd Little jokingly looked back to the 1st Agile conference in 2004 when agile experts made predictions of the future and came up with the top 8 things that will happen once main stream gets hold of Agile Software Development:

8. The 1st Agile software development conference will undergo historical revisionism, in which it will be told as originally taking place on a farm outside Sundance, with lots of music and on-demand pairing, and announcements in middle of the conference to not eat the brown acid.

7. The Spike channel will ask Ron Jeffries to host an Apprentice-type reality show where agile teams will compete against each other to build software for rocket-packs, X-ray goggles, and invisibility rays. The catchphrase when he gets rid of the failing team each week is “You’re dead fish!”

6. GE will develop 3 year, six sigma certification programs for becoming Agile Certified.

4. You’ll see personal ads like ”Certified SCRUM master seeks product owner with large product backlog for promiscuous pairing”, and “Single Agile Developer with data envy and analysis paralysis seeks customer for private requirements collection; expect failure”.

3. Sun will come up with an innovative, elegant Agile programming language, get people to use it, and proceed to totally screw up the marketing for it and name it with really confusing release numbers.

2. Woman out at bars together will refer scathingly to the guy at the end of the bar who keeps starring at them as a “scope creep”.

1. A paperclip in Windows will pop up periodically and say, “Looks like you’re trying the waterfall method. Want me to pair with you?

Saturday, August 20, 2011

Measuring Code Quality

A common measure for code quality is to measure Cyclomatic Complexity. Cyclomatic Complexity is used to measure the number of linearly independent paths through a program’s source code. The more conditionals (if statements) or the more loops (for, while …), then the more branches run through the code and thus the code becomes more complex. But what is considered to be a good number for Cyclomatic Complexity? What should developers target?


A study by energy (http://www.enerjy.com/blog/?p=198) reveals the following:



There is a 50% chance of errors with a Cyclomatic Complexity of 38 and almost a 100% chance of error when Cyclomatic Complexity is 74. On the other hand, with a Cyclomatic Complexity of 11, the chances of errors drops to 28%.

So based on this study and the above graph, shoot for a Cyclomatic Complexity of below 20 per class.

Adapted from "Technical Debt Assessment and Reduction" @ Agile2011

Saturday, August 13, 2011

The 5 Whys

Agile Retrospectives: Making Good Teams GreatThe 5 whys is a retrospective technique that can be used when the team needs to focus on a specific symptom that does not have an obvious solution. The goal of the 5 whys is to clearly understand the situation and not necessarily to solve the problem.

The process is as follows:
  1. Write the problem statement clearly and concisely on the board.
  2.  Divide the team into groups of at least 3 but not more than 5. 
  3.  In each group, individually answer why did this happen? Number your answer as #1.
  4.  Individually answer why did #1 happen? Number your answer as #2.
  5.  Individually answer why did #2 happen? And so on until you have around 5 answers or can’t come up with more meaningful answers (try to have at least 3 answers).
  6.  Each individual places their chain of responses in a column below the problem statement. The group then discusses the individual answers and tries to find common patterns.
  7.  The group consolidates the chains into a single chain.
  8.  If necessary, the team consolidates the chains into a single chain.

Participants should focus on exploring the immediate cause of the symptom rather than attempting to immediately jump to a root cause. The intermediate reasons often spark ideas within the group that would otherwise be overlooked.

While this exercise is typically applied against problems, this same technique can also be used to discover what led a team to achieve exceptional success in one area.




Adapted from: Putting the fun back into your retrospectives @ Agile2011