Business Analysts are Important

I've always been convinced that User Stories are the way to describe feature requests. It just felt natural. IEEE 830 specification are just too ambiguous. Use Cases, even far more verbose, are often too large by covering all possible flows and exceptional cases. User Stories just fit the bill.

Writing good User Stories can be a daunting exercise. A proven way is to use the

AS A persona/role
I WANT goal
SO THAT business value

template with which the User Stories become much more tangible and more important of value to the customer. Watch out for 'and' or 'or' in the I WANT section, those often indicate a second User Story.
So far so good, but this still leaves the acceptance criteria out of the picture. Acceptance Criteria are a good guideline for developers to make sure they do the right thing right. It gives them a change to cover themselves with proper unit tests. QA also uses them as a testing foundation. Most important though, they are the definition of development done. (see 'Measuring Progress') Sure, the customer still has to like and accept them!

So that brought me to use:

GIVEN context
WHEN event
THEN expected outcome

With those kind of user stories you would think you are in pretty good shape. Well, you probably are in the remote case should you develop a programming tool. What does this mean? The more the development team knows about the problem domain the better they are off. Now, consider the case that you develop software for the financial, medical, nuclear or any other foreign field. Looking at the image below you are ok for as long as you stay in the green band where the requirements are clearly understood. In case of the mentioned programming tool your programmers will.

[Agile Software Development with Scrum; Prentice Hall, Ken Schwaber, Mike Beedle, p. 93]

Once you enter the red band, the team enters an unknown and not well understood territory. The User Stories might read like this.

AS A wombut
I WANT to blabalam amplituded chromioms in a shamaluk
SO THAT I can implotude the defused mobolobs

Makes any sense? If you are post-doctoral wombut it will. So, how can this knowledge be transfered to the mortal world of developers?
One option would be to have the wombuts and developers spent long hours together so that they get some understanding about the domain. The more knowledge is missing the longer it will take. Most often, however, wombuts are so busy that they can only spare an hour here and there. There might be some short hallway chats; but often those rise more questions then they answer.

Over the long run, this will lead to an information deficit and the resulting vacuum will be filled with assumptions. Don't assume -- if you assume you make an ASS of yoU and ME ;)

[The dotted line shows limited communication]

In the world of TOC (Theorie of Constraints) you can mitigate a constraint like this with introducing a buffer. The buffer enables you to be productive even though a upstream step is blocked. What could this buffer be? As the title already reveals, it would be a Business Analyst (BA).

[BA as buffer with good communication flow]

Having a Business Analyst will give you two things. First, knowledge you can access all the time; usually the knowledge of the BA is a subset of the experts but in general good enough. If the BA does not know an answer or isn't sure, she will follow up with the domain expert and report back and grow her knowledge by doing this. Second, the BA can help to bridge the communication barrier between the developers and domain experts. She is used to work with developers and understands how they think. Still, the lingua franca between both sides would be the User Stories with their acceptance criteria. If both the developers and domain expert are happy with the resulting User Stories then we have an agreement about how the customer value will be delivered.

What about the blue vertical band on the requirement image from above? The green/blue area is a well understood domain but is technically challenging. Think about the really fancy programming tool mentioned before -- for that strong programmers will be able to do the job. The red/blue area is when you need both; a BA and real good programmers.

Considering I lead a project in the plain red area (not red/blue) and I had to choose between a real good programmer or a BA, I would opt for the BA without hesitation.

Whose Fault Is It?

I recently read on a newsgroup about different opinions who is at fault and therefore responsible. The issue was about bugs which are discovered at the end of the iteration or during a following one.

One position was the following. This is the nature of software development and bugs do come up and they should be handled like user stories and be processed in an upcoming iteration. The other was that the developers messed up and since it is their fault they have to fix the bugs in their spare time.

What does each statement mean? In the first it means that the customer will get less value in subsequent iterations as they include bug fixes. The developers get immunity and are not being held accountable for their failures. The customer suffers.
Where as the second one is on the side of the customer as it clearly pushes the fault onto the developers and they need to fix it in their spare time which means long nights and/or week-ends.

First it should be differentiated whether this is a green field project or an existing legacy system which by its very nature tends to be more brittle. Regardless, in my opinion both approaches are too polarized and one approach possible illegal in certain countries. The high goal should be a customer getting all the value they can expect in a fair way and programmers which can have a social life. Another solution to the problem is required.

In the last couple of month I've been reading quite a lot about Lean and how Toyota achieves to make $16B profit while the US car makers are asking for federal help. Lean has some great approaches and one of them is the 5 Whys or Root Cause Analysis. The idea is to ask Why 5 times and the fifth answer provides the root cause. By fixing the root cause you fix all discovered symptoms and the problem should disappear for good.

So, I applied the 5 Whys in retrospective to a project I've been working on a while ago and which had exactly those problems.

Q: Why do we have bugs at the end of the iteration?
A: QA does not accept some user stories as they don't fulfill the acceptance criteria.

Q: Why do the user stories don't fulfill the acceptance criteria?
A: QA and domain expert don't have enough time to specify them on time and therefore the developers don't have access to them during development.

Q: Why do QA and the domain expert have not enough time?
A: They work on other project as well and share their time between those.

Q: Why do the work in several projects at the same time?
A: Matrix Management

Q: Why Matrix Management
A: Upper Management believes that this improves efficiency.

With this process we were able to identify one root cause -- Matrix Management. By removing this cause we should see improvement. In this scenario the solution is rather a structural -- I dare to say political -- then technical. Upper Management needs to be convinced that having dedicated QA and domain experts per project is necessary. Don't assume that this will be easy. I strongly recommend to provide hard data and generate some statistics describing the current situation and how the change would improve the productivity.

I want to re-emphasize the connection between Matrix Management and the problem of not having dedicated resources per team. This was obvious after answer number three but the root cause is the management structure. With that knowledge, you most likely will be able to identify and address further issues.

Once you get this sorted out and you see improvement don't let inertia slow you down. Look out for the next problem and apply the 5 Whys once more.

Just a final thought at the end. Often, if too many people work on too many projects in parallel. This is a symptom for prioritization gone wrong. Fear of postponing the wrong projects causes that more projects are underway as should.

Agile Bridge Analogy

It is quite common to make analogies between the IT industry and Civil engineering. Developers often compare software development and design with construction projects; for example, the importance of having a blueprint and following known successful practices. I have some hesitations about using analogies between these industries. I find the resources used by both industries fairly different and for that reason the analogies can create false expectations and reasoning. Nevertheless, I have been successfully using the analogy of building a bridge for explaining Agile development.

When I was a teenager, I spent my summer vacations in a small beach town near Rio de Janeiro. In that city (Rio das Ostras) there was a little river which separated two parts of the town. Back then there was no bridge to cross the river in a specific section of the town.

Over a few years, I was able to experience the bridge being built. When teaching Agile software development practices, I have been using the construction process for that bridge as an example of how Agile delivers business value incrementally and iteratively.

To better explain the analogy, I will take a look into the traditional approach for building bridges and then I will explain the Agile counterpart.

The Traditional development

Traditionally, a bridge construction will be planned in detail. The blueprint will be produced, the budget allocated and the schedule created (perhaps several months of construction).

'Big-bang release' is the term used to describe a common software development release. At the very end the software is released — one big (bang) release. But what happens if it is not successful?

Below are some photos from unfinished bridges.

Half-built bridges or long running construction does not deliver any business value: nobody is able to cross the river!

The Agile Development

Let’s now look into the Agile approach for building a bridge.

The figure below shows a first version view of the bridge (maybe after a first iteration). Even being very simple (and fast to plan and build) the bridge delivers business value: one person at a time can cross the river.

At the next iteration, another piece of wood is added to the bridge. Now, the bridge handles more load and two people can cross the bridge at a time, as well as bicycles and motorbikes.

Perhaps, for the next iteration(s), the bridge is reinforced and now people, bikes, motorbikes and light vehicles are able to cross the river.

Following an iterative and incremental development style, extra reinforcements are added to the bridge during the next iteration(s) and now people, bicycles, motorbikes, light and heavier vehicles can cross the river.

Even though it took a while to reach the current stage of the bridge, business value was delivered all along.

In this blog entry, I used an analogy between building bridges and developing software. I wrote about an Agile approach for building bridges. In fact, in this approach I have been a satisfied end user (someone wanting to cross a river). Furthermore, I used this analogy to illustrate how Agile focuses on delivering business value incrementally (and in shorter release cycles) through an iterative development process.

Even though in this example I compared software development to building a small bridge, Agile has been proven to work for large projects as well. I have witnessed large successful Agile projects for which business value was iteratively and incrementally delivered.

Resetting the 'Shitty' Counter

Again and again I hear the following phrase: 'This code is so bad that it has to be rewritten'. That statement is right in some cases. Even though I prefer to refactor, there are situations were it does not make sense any more. Most code bases can be salvaged with major and persistent refactoring efforts. Over time your refactoring skills get better and better and more systems are cureable but still, some cases are what they are: terminal.
What does it really mean to rewrite a system? It is the defeat of the software team. Often the existing team inherited the system, or worse they are the original authors. In either case, no team was able to make the code base more maintainable or at a minimum not to make it worse. The project lacked fundamental skills like team communication, best coding, configuration and testing practices. They failed -- the code rotted in their hands!
Next, this team decides to rewrite the system and promises to make everything better the next time. Sounds good? To me, it is more like a broken record. Why? They will repeat most of their mistakes and eventually call for another rewrite. Sure, the team learned from some of the old mistakes, but still this does not suffice to prevent another decaying code base. The rewrite means basically to 'Reset the Shitty Counter' [1].
Now your Counter is at zero, but unless you take matters in your own hands and actively manage the risks of your old mistakes your 'Shitty Counter' will slowly inch upwards. Well, ... you know the story!
How can this be achieved? There are many best practices from the agile world and even more books about those. It would be foolish for me to try to explain each of them and their dependencies and how they interact.

However, I will give you my elevator pitch:

• Test Driven Development (TDD)
• Pair Programming
• Continuous Integration
• Co-location of programmers, testers and domain experts
• Scrum (do the Nokio Scrum Test to make sure you really do it [2])
• Never ever change the length of your iteration
• Determine you velocity
• Retrospectives after every iteration [3]

From a code point of view, one should aim for:

• Short methods (not more then 10 lines per method)
• Single Responsibility Principle per Class
• Low complexity (McCabe or CCN)
• Loose Coupling and High Cohesion
• Law of Demeter
• Injectability (ie. Spring, Google Guice, PicoContainer)

Static Code Metrics

• Test Coverage (use with caution unless you have many small tests)
• Testability of Code (Testability Explorer) [4]
• Percentage of duplicated code (CPD) [5]

These are the tools of the trade of an agile test infected code warrior. If you use those best practices on a daily basis and refactor your code mercilessly. Over time your code base will actually become better. It is not easy, it is a skill you learn by doing manually, day in day out.

[1] This term was coined by a colleague of mine
[2] http://www.agilecollab.com/the-nokia-test
[3] Agile Retrospectives (Esther Derby & Johanna Rothman)
[4] http://www.testabilityexplorer.org
[5] http://pmd.sourceforge.net/cpd.html

Measuring Progress

Recently I was asked to help out on a project that was not as productive as expected. My first question about where they are and where they should be, it became quickly obvious that they did not know. They perfectly knew that they are well behind but they were not able to quantify the deficiency. How could that be? All team members were always focused and working hard. So it was not a people problem, but rather a measuring problem.

How do you measure progress? There are two sides to the equation. Work to be done and completed work. Progress is the amount of the completed 'done' side in relation to the 'to be done' side. In order to have progress you need to move finished work from one side to the other. But, what means finished and when can we stick the 'done' label on something?

That gives us two entities we need. I call them 'Unit of Work' (UOW) and a definition of 'Done'.

UOW could be anything, however it needs to be well defined and understood from every single team member. The foremost important thing is that there is no miss-understanding about size, scope and dependencies. In the agile world this is a 'User Story' (US). In RUP a 'Use Case' or otherwise a requirement. Since this is about agile, I will use US in this article.

Each user story provides value to the customer and has three main attributes. These are priority, description and effort estimate. Priority is given by the customer, the customer has the right to choose what is the most important to them. The description should be done by both developers and customers to make sure that both have the same understanding. During that process the US is also estimated. The estimate can be of any unit; for simplicity lets use days. This has to be done for every wanted US for the first release. (personally I prefer story points [1])
Now we have on side of the equation, we call this the product backlog. A number of US with a description, a priority. Higher priority US are done first. Finally, the sum of all the effort estimates, in our case a number of days. Now, we can measure progress.

Progress = 100 / Total Effort Estimate * Done

Please, be aware that this is an estimate and we allow them to change. The customer even has the right add, remove or change US. But all those changes to the US product backlog will also adjust the progress as the total effort estimate will be affected. Depending if it is a date or feature driven project, you can adjust accordingly and see what the impact is.

Now, let's have a look at a definition of Done. When is something done? In the case of software one could say that something is done once the functionality is usable. Is this sufficient? I don't think so, as there are several Dones which have to be completed before a US can be labeled as Done. I call them the 4Ds.

The 4 Dones:

1. D1: Done Implementing -- Functionality is implemented and works
2. D2: Done Unit Testing -- Automatic unit tests can repeatably proof that code is working
3. D3: Done Acceptance -- The customer likes what she sees and accepts it
4. D4: Done QA -- QA signs of

The first done is what was sufficed in a pre agile world. In a TDD environment steps 1. and 2. are basically one. However, I still like to keep them separate as a mental reminder as not every team is doing TDD. As for the customer acceptance, this would typically happen in a showcase at the end of an iteration. You demo the code and answer upcoming questions. Finally, you give it to QA and they make sure it passes all acceptance criteria defined by the US. Step 4. can actually start before step 3. and maybe even be in parallel with 1. and 2.

A US can be moved from the 'to be done' side -- the product backlog -- to the completed side if a US is D4, i.e. all four done criteria have been fulfilled. Not, earlier! A story is either done or not, there is nothing in between. A story needs to have at least a 2D state to be showcased to the customer. Unfinished US are of no value to the customer.

Assuming the size of our product backlog is 100 days and as of now the sum of D4 US is 40 days we can claim to have a 40% completion. Now, if the customer adds a couple of new US with the effort estimates summing up to 20 days we will fall back to 33%.

This is a good start, but are we able to answer the question about when the project will be finished? First, we will never be able to guarantee a specific date, however we can use historical data to make a good estimate. Let's say it took us 6 iterations to complete the sum of 40 days. That makes ~6.5 per iteration. 60 days are left in the product backlog; 60/6.5 = ~10. (with the rounding, don't be obsessed with precision; I like to err on the cautious side) If there are no significant changes we can be pretty confident to complete the project in 10 iterations. Also, it should be obvious that all the iterations are strictly time boxed and of fixed length -- No exemptions!

In order to measure progress we need tangible units like US and a clear definition of done. All US stories with their effort estimate are the product backlog. Once we have those we can measure the project progress. If we work with those units in a iterative framework, we are actually able to provide an end date with a certain degree of confidence.

[1] Agile Estimating and Planning

Testing and Handling Logging in Java

Logging is a great way to communicate the systems past steps and state for debugging. Often, they are the last resort to get an idea about what is happening in a remote system.
But, not all is shiny. Usually, the log entries are printed onto the console and to a file. The later one is no problem, however, the first one can be a pain point.
How? Assuming you have an application with a good suit of unit tests. Say a couple of hundreds so that the output of running the tests does not fit on one screen any more. Now, when you run the tests, you get a few lines for each test and a bunch of logging informations. This is called noise. It gets even worse if the output is laced with exception stack traces. Sure, there are cases were you want to test error conditions and those will cause exceptions in return. However, consider yourself new to a team and you just setup a new sandbox, a good corporate citizen as you are, you run all the tests before you pick up your first user story to work on. But, what is this? The screen is scattered with exceptions in the test output. I would be scared and would assume that I did something wrong during setup. The noise drowns out the real state of the system -- a build system should communicate the health of the system in a unambiguous way. This is a risk which can be avoided easily.

Logging -- which was added to Java 1.4 -- allows you to add a filter. With that filter you can intercept and decide which logs to actually log.
Also, you have to make sure to use the same logger as the one you want to suppress. Just use the same string as identifier for both. I usually use the name of the class from the class object itself.

Logger LOG = Logger.getLogger(Example.class.getName());

once you have the logger instance, you add a filter which deals with the log record and suppresses its logging.

logger.setFilter(new Filter()
{
 public boolean isLoggable(LogRecord logRecord) {
   if (logRecord.getLevel().intValue() == Level.SEVERE.intValue()) {
        // deal with log record
   }
   return false; // suppress logging  }
});

Here the code for a small Example

public class Example {
  private static final Logger LOG = Logger.getLogger(Example.class.getName());
  public void foo() {
    LOG.info("entering");
    try {
      willFail();
    } catch (Exception e) {
      LOG.logp(Level.SEVERE, Example.class.getName(),
               "foo", "something bad happened", e);
    }
    LOG.info("exiting");
  } 
  private void willFail() throws Exception {
    throw new Exception("ERROR MSG");
  }
}

And here the matching test

public class ExamleTest extends TestCase {
  private Example example;
  private Logger logger;
  private List logRecords;

 protected void setUp() throws Exception {
   example = new Example();
   logger = Logger.getLogger(Example.class.getName());
   logRecords = new ArrayList();
 }

 public void testFooLogsSevereIfFailure() {
   logger.setFilter(new Filter()
   {
     public boolean isLoggable(LogRecord logRecord) {
       if (logRecord.getLevel().intValue() == Level.SEVERE.intValue()) {
         logRecords.add(logRecord);
       }
       return false;
   }});

   example.foo();

   assertEquals(1, logRecords.size());
   assertEquals("something bad happened", logRecords.get(0).getMessage());
   assertEquals("ERROR MSG", logRecords.get(0).getThrown().getMessage());
 }

 public void testFooLogsEntryAndExit() {
   logger.setFilter(new Filter()
   {
     public boolean isLoggable(LogRecord logRecord) {
       if (logRecord.getLevel().intValue() == Level.INFO.intValue()) {
         logRecords.add(logRecord);
       }
       return false;
   }});

   example.foo();

   assertEquals(2, logRecords.size());
   assertEquals("entering", logRecords.get(0).getMessage());
   assertEquals("exiting", logRecords.get(1).getMessage());
 }
}

With this you remove the noise from running your tests as this

ExamleTest,testFooLogsSevereIfFailure
May 5, 2008 9:50:18 PM Example foo
INFO: entering
May 5, 2008 9:50:18 PM Example foo
SEVERE: something bad happened
java.lang.Exception: ERROR MSG
 at Example.willFail(Example.java:20)
 at Example.foo(Example.java:11)
 at ExamleTest.testFooLogsSevereIfFailure(ExamleTest.java:33)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at junit.framework.TestCase.runTest(TestCase.java:164)
 at junit.framework.TestCase.runBare(TestCase.java:130)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:120)
 at junit.textui.TestRunner.doRun(TestRunner.java:121)
 at com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:65)
 at junit.textui.TestRunner.doRun(TestRunner.java:114)
 at com.intellij.rt.execution.junit.IdeaTestRunner.startRunnerWithArgs(IdeaTestRunner.java:24)
 at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:118)
 at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
May 5, 2008 9:50:18 PM Example foo
INFO: exiting

Process finished with exit code 0

becomes that

Process finished with exit code 0

The second line shows you that the tests passed (exit code 0) with no errors. All you need to know. No noise!
Best of all, you now actually test a specific exception to be thrown if a certain condition occurs. So, if a fellow programmer removes the exception with or without intention you get at least a raised finger in form of a failing test. That should lead to a conversation which again makes sure that the situation is resolved accordingly. Agile is about communication!

Note: This applies only for the JDK logger. log4j does not feature a filter which can be modified at runtime. I haven't spent lots of time investigating, but as of now I did not discover a work around. Drop me a line if you figured that one out ;)

Standups need a Scrum Master

You really need a Scrum Master (or Iteration Manager) to do proper standup meetings. Sure, you can still do them the casual way, but I dare to say that most likely they will be of not much use.
Let me describe two scenarios: The first is done by developers only. The second is run by a scrum master and she makes sure that the standup follows the protocol.

Scenario 1
Depending on the time the standup takes place, most developers are still waiting for the cafeine to kick in and try to remember what they did yesterday; at least the parts worth mentioning.
One after the other, they describe what they did, how great a job they did and what they are planning to do today. Often they mumble to themselves like lonely souls in a bar. Now, imagine a group of, let's say, 6 developers doing the round. Without some mental help, could you remember what each of the developers did the day before or even only which problems they encountered? Maybe, for one or two, but I doubt that you could do that for all of them. So, if no one has to remember and to follow up, how is it guaranteed that issues have been resolved?
How do you know that a specific feature has really been implemented? In short, it is not possible to track and therefore not possible to manage. So, at the end of the iteration it is common if not accepted that there will be surprises. Most likely of the unpleasant kind.

Scenario 2
The scrum master brings out the story board with all the story cards on them and spents a minute or two to memorize important key elements. All of the story cards which are currently played feature the owner's name and estimate and the progress done so far. Some of the cards feature red stickers to indicate problems which needed to be resolved. Once she is setup she calls out and officially starts the stand up meeting.
The developers gather and start in the same way as the other group from scenario 1 did. The scrum master looks up the card currently played by the reporting developer. She listens careful to every word and makes notes. Developers will be reminded to speak clearly and audibly for everyone if needed. If the card features a red sticker, she removes it if the problem has been resolved.
After the standup, which is a really busy moment for a scrum master, she has lots of notes and her engaged day starts. First, if not done on the fly, she will update the story board ie. moving cards to different stages, noting progress, placing red stickers, ...
She then will start to work out solutions for the problems reported. That could be to get new hardware, borrow a resource for a couple of hours from another department, etc.. The scrum master keeps the engine going all the time and knows at any moment the state the current iteration is in.
The next day, the procedure repeats. She listens again to each of the short reports and takes notes. She even might ask a couple of questions during the standup -- if short -- or address developers off-line to make sure that the story is working out as planned and that resolved issues are really resolved.

Comparing those two scenarios. Which one do you think is more effective, which one has the least chance of issues being overseen or worse forgotten? The answer is obvious. In the 2nd scenario, the scrum master is on top of things and chases loose ends and essentially herds the cats.

What can you do if your environment does not provide a scrum master? Well, this is a hard question. In best cases someone steps up to the challenge and tries to be as much of a scrum master as possible. Often, this is already an individual with leader capabilities like the tech lead or project manager. Which one of those two will fit the bill better? I won't try to answer this question as this needs to be decided on a case by case basis. Both have advantages and disadvantages which need to be evaluated against their personal role and agenda.

Now, if I reconsider the title of this blog it should be: 'Software Projects need a Scrum Master'.