The N+1 Iteration syndrome

I constantly ask myself if i know what is next at the end of a sprint or iteration and that I should make an effort to know what is coming up next, I observe that just like me the members of the team are only focussing only on the card that there magnet is on in the current iteration. Adapting to a constant flow of user stories and requirement is not easy for any team and is as important as focussing on the stories in the current iteration. We as a team focus on the user stories in the board, but it may be worthwhile asking ourselves how many people in the team are really aware of what is coming up in the next iteration. If members in the team were asked to answer to this question honestly you will find that a vast majority probably don’t have much information or are totally ignorant. I prefer the term N+1 for the next iteration. In most teams I have worked this is a problem that is evident in one form or the other and some common symptoms I find are the ones mentioned below.

Symptoms

• Analysts find it frustrating that they have to repeatedly read the story out and explain the same story more than a few times.
• Team velocity sways massively and the standard deviation to average velocity is quite high
• Requirements workshops are almost absent and it seems like analysts are in a different time zone on the user requirements on most occasions when compared to the team.
• Team members are not sure about the size of the story and try to come up to a size as close as possible to the rest of the team rather than putting any effort involved in understanding the size of the story.
• Constructive discussions, debate and any implementation concerns are almost absent
• The team seems to easily agree on the size of the story and gets swayed into a conclusion by anyone who can speak the team into a conclusion
• Large stories seem to be finished earlier than they ought to be and some of the smaller stories seem to take more time and some times end up looking like large stories.

This syndrome manifests itself in different ways and consequences range to varying degrees of severity on the functioning of an agile team. The team should address this situation if they do find these symptoms, the effects of not addressing this problem could result in false velocities, skewed metrics, increase in cost of the project and finally manifests itself in a loss of trust from the users for whom we actually work on the project. I wonder if I am making a big deal out of this, but this may be because I perceive the consequences of this syndrome to grow exponentially into bigger problems and can be quite damaging for the future of the team and the project.

We can mitigate some of these symptoms, a few ideas that allow you to improve and move in the right direction are below

• Introduce a N+1 sprint section on the left and side of your Kanban or sprint board and line up stories that will flow into the next sprint.
• Encourage analysts who are working on N+1 Q to speak about there analysis during your stand ups, this helps spread awareness of the N+1 iteration on a daily basis. Truth is in an iteration the analyst is probably working 50% of their time on the N+1 sprint and the other current sprint.
• Encourage your team members to pair with analysts and discuss and learn what they are working on, if you can allow your developers and QAs to pair for 5% of the iteration on a rotational basis with the analyst. These pairing sessions really helps non technical analysts to learn a few tricks and understand why you would think the story is complex or simple
• Have mini 15 minute sessions every day after the stand up to pick up one story from the N+1 board and discuss with the analyst, testability and implementation details. This will mitigate the loss of requirements workshop they are long and can be boring anyway , small cycles of these sessions will get the team to be constantly involved in requirements.. the term cross functional teams was not coined just for developers and QAs , it did mean all functions in the project.
• Have some ground rules for your planning session,
  • Team comes attend the planning session with an awareness of the stories flowing into the Kanban,
  • You really don't want estimating to eat up all your planning time, clearly planning is not only to estimate it is also about discussing priorities and setting goals for your iteration, spend some time planning how you would action retrospectives as well.

You will see that the team will at least loose the perplexed “I don't know what you are talking about look “ and the “I cant be bothered” attitude , this could be a good starting point to address the problem. This will allow your team to be more involved in planning as much as they are involved in the progress of the sprints.

Authoring and Automating - User Stories

In most agile development teams the responsibility of writing user stories falls into the hands of the analyst. The analyst not in all cases may be well versed with the idea of writing stories. This is not because he does not know what to write but sometimes because he does not know the best way to express the story in the chosen story writing platform. This doesn't warrant a developer to pair with an analyst to author a story, In my opinion developers are not welcome to pair with the analyst to author user stories. Allowing this will allow implementation detail to find its way into the stories and sometimes they dictate the users intention.

Authoring stories

The best person for your analyst to pair with should be your QA, this proves to be the most useful.

• The QA looks at a story early in the life cycle and ensures all aspects of the story are testable.
• The ownership of the story is with the QA and he/she is able to identify any automation concerns of the story..
• Any scenarios that have not been through in a story due to data related anomalies are identified.
• The QA is involved in this process early on before the iteration in which the story is picked up , this will allow the QA to bring in some valuable information on the size of the story to the planning session.
• Since the QA gets an understanding of the story before a developer is involved his view of the story is as close as possible to the users requirement in the story. This important to make sure the intention of the user is not skewed by the understanding of a developer.
• The QA is able to identify any smoke tests that may be required to be run when a release is deployed to UAT or Live.

Automating stories

In our current project our QA starts automating user stories when he runs out of stories to test. In most cases the QA to dev ratio is 1:2 or 1:3 and so the QA gets bogged down with implementing acceptance criteria so the team has enough stories to dev on. It helps for devs to pair with QAs to automate acceptance tests and my observation has been the following

• On a normal day we developers are more in sync with writing better code than QA’s, developers can always help in writing better test code.
• When developers implement the acceptance criteria in the form of Given When Then, they actually are implementing the story itself.
• Developers will get an idea of how to implement the story and tests required when they actually develop the story.
• Where the story is looking for new elements on the UI, developers can aid in mocking the UI for the story else automating all the steps of the user story could be a night mare for the QA all on his own.

PS : My Selfish reason - Developers learn a new language .. I learnt ruby this way :)

In effect when three different people with different skills are involved in the authoring and automation of the story, this will ensure a lot more analysis happens and more often than not edge cases are discovered ahead of development. Any edge cases which will increase the cost of the story can be identified and a decision made taken if they have any real value in development.

Pair Usefully and Code Effectively

Pairing is of real value when two developers work with each other in a such a manner that they allow the other person to teach and learn new ways of working. This mutual learning process will ensure that the competency of the team will grow uniformly. In my current job we almost never work alone we always pair. Recent retrospectives have been focussing on how we get the most out of our pairing sessions. Some developers said we don’t swap pairs enough, there were questions about how and when do we determine it is a good time to swap pairs.

Well there is probably no hard and fast rule on pairing but some of the things we seem to recognise in a team are as follows.

1. Story Champs - A story owner or champion should be present on the story who will see the story go through the board

2. Story Progress - Having a story champion will allow you to swap pairs across a story reasonably well without affecting the progress of the story.

3. Keyboard Policy – More often than not this is a reason for frustration among developers in a pairing session. Use TDD to pair effectively.

Eg. Pair made of Dev A and Dev B.

• Dev A writes test to fail – Red
• Dev B implements code to pass the test – Green
• Dev A refactors the code

Alternate between the devs in this cycle will ensure pairing sessions are not driven by just one dev

4.Pairing Overdrive - If at any point during a pairing session one of the two seem to be dictating code for more than a few minutes ( I call this overdrive mode). You should really stop pairing and determine if the pairing session is useful and how it can be made useful , the dev who is on overdrive mode should really take the initiative to bring his/her pair up to speed on the story they are working on and discuss any gaps in each others understanding.. get away from the computer go for coffee break.. really helps.

5. Check-in frequency – When we pair due to reasons beyond our control one of the two dev may have to leave at any time before the other, frequent check-ins will allow you to make sure your CI is effective and also that you can switch machines quickly and effectively.

6. Computer Policy - if a pair is working on machine and dev who owns the computer has to leave, the other dev should be able to continue working on the story ..In such a situation it helps to leave the computer unlocked till your pair can make a check-in and then pull the changes on his computer and continue work, locking your computer and leaving could really be annoying to some one who really wants to continue work.

7. Early Birds –If you come in earlier than your pair, instead of just picking up the story and continuing work it helps to look at your CI server and fix any broker builds. If you do work on the story do make sure you explain what has been done and how far you have progressed so your pair gets up to speed, else you end up with Pairing Overdrive.

8. Privacy Policy – If you are working on your pairs machine and when your pair is not around do not snoop around there mail or respond to IM that they receive even for fun, what seems to be fun may turn out to be an annoyance. Finally there is absolutely no need to get personal during a pairing session, every developer has his own style and strengths it is important to respect that , for all you know they might be really skilled in areas you are not so good yourself..

After every stand up it makes sense to discuss who can swap pairs. Infact before a stand up it helps to be in a checked in state if you want to make sure your team can swap pairs every day

For now this is all.. code carefully and pair usefully  :)

Acceptance Testing

After playing around with Cucumber/ Cuke4Nuke and Specflow.. turns out cucumber is the winner for me.. Cuke4Nuke took me a while to get going and seems considerably slow and is behind cucumber by some distance..

Specflow is alright however the idea of using attributes to match my step definitions is what i didn't like.. integration with VS and being able to use the NUnit test runner are clear winners.. the entry barrier to this is pretty much minimal.

Well as for Cucumber/ Ruby / WATIR, the idea of using RubyMine to write my tests and debug them in the same doesn't make me miss VS integration and debugging.. I don't think i particularly miss writing my tests in different languages.. well i never do so why bother… The choice of gems available for Ruby and dynamic nature of ruby is something that makes the effort rewarding .. Build integration using a Rake runner is easy not much effort either..One other reason is may be because i use this at work .. there is yet one more to be looked at which is the WebDriver API for Selenium 2.0. http://google-opensource.blogspot.com/2009/05/introducing-webdriver.html ..

I took some time to play around with these since I don’t like skimming through the surface ..

SqLite Manager plugin for firefox

There is a good chance some of you use this or know about this already. However this is kind of new stuff for me.. In my current project we use SqLite  to run our integration tests for the repository tests and the some of the rhino ETL process classes. We use SqLite as a file based database rather than an in memory instance and while i was debugging through the code I hit a point where i wanted to see how the schema was created and the data stored, so i can be sure the foreign keys where stored with the right values

SqLite Manager is a useful plugin for Firefox 3.6. This is browser based and allows you to work on the file based database just like Sql Server Enterprise Manager allows you to work with SQL 2000. This is a really useful tool when you are writing integration tests with SqLite.

You can get the plugin at , you may need firefox 3.6 or above

https://addons.mozilla.org/en-US/firefox/addon/5817

NUnit - Teamcity - TestCaseSource tip

If you are using features from NUnit 2.5 or above TestCaseSource attribute may sound familiar. This is a very useful feature in NUnit now which helps us reduce the clutter of repetitive code in our test class. I am sure everyone can see how this can be done on the NUnit website as well , but the point of this post is in relation to a problem I ran into when I used the TestCaseSource attribute. To elaborate on this let me use a simple example of a class which calculates the square of an integer.

public class SquareOfNumbers
{
   public static int Square(int x)
{
   return x * x;
}
}

When i first started writing tests i used the TestCaseSource attribute , so my test class looked like the one below

[TestFixture]

public class SquareOfNumberFixture
{
private static readonly Dictionary<int, int> _testData = new Dictionary<int, int>();

public static Dictionary<int, int> TestData
{
   get
   {
       _testData.Add(2, 4);
       _testData.Add(0, 0);
       return _testData;
   }
}

[Test, TestCaseSource("TestData")]
public void Test(KeyValuePair<int, int> keyValuePair)
{
   Assert.That(SquareOfNumbers.Square(keyValuePair.Key ), Is.EqualTo(keyValuePair.Value));
}
}

These tests run successfully, but when run as part of my teamcity build there is no detail about what the tests where as in there was no reference to the name of my test method. I did spend sometime trying to fix this and found a couple of issues.

1. Team city was not using the same nunit version that I was using to write tests, so the plugin had to be updated on team city, this way i made sure the build uses the same nunit framework as my source code does

2. I changed my tests to use TestCaseData class in conjunction with the TestCaseSource attribute, this allowed me to specify a name for each test scenario , so after refactoring the test class , I can now see the test names on the nunit test report generated by Team city, the code for the new test class is shown below

In addition to fixing the problem , TestCaseData class made the test code more readable.

[TestFixture]
public class SquareOfNumberFixture
{
  public static IEnumerable TestData
  {
      get
      {
          TestCaseData squareOfZeroTest = new TestCaseData(0).Returns(0);
          squareOfZeroTest.SetName("SquareOfZeroReturnsZero");
          yield return squareOfZeroTest;

          TestCaseData squareOfIntegerTest = new TestCaseData(2).Returns(4);
          squareOfIntegerTest.SetName("SquareOfTwoReturnsFour");
          yield return squareOfIntegerTest;
      }
  }

  [Test, TestCaseSource("TestData")]
  public int TestSquareOfNumbers(int x)
  {
      return SquareOfNumbers.Square(x);
  }
}

On second thoughts further refactoring the class makes it more readable if i had done the following…

[TestFixture]

public class SquareOfNumberFixtureNew
{
  [TestCase(0, Description = "SquareOfZero", Result = 0)]
  [TestCase(2, Description = "SquareOfTwo", Result = 4)]
  [Test]
  public int TestSquareOfNumbers(int x)
  {
           return SquareOfNumbers.Square(x);
  }
}

Acceptance Testing – Cucumber? Specflow? Cuke4Nuke

I have been pretty much dormant on this blog due to my part time MBA coupled with a some tight deadlines at work. And to get me back into the blog bandwagon I just thought I will do this small pet project of mine outside work for which I have been exploring the acceptance testing tool to use infact functional test tool which will allow me to translate my acceptance criteria on stories to tests from plain english.

I found something about Specflow on a few blogs,it is a set of libraries to write specifications using Gherkin. You can check the screencast here or read this post from Ryan Lanciaux. SpecFlow can use either NUnit or MsTest as the engine. You could use specflow and drive WATIN.

Being a .Net developer I am quite inclined to use Specflow and Watin after having had a look at it mainly because i dont need to learn a new language and i can use my c# knowledge to write tests, However previous experience with WATIN a couple of years was not great and it always seemed be behind some of the things you could do with WATIR, hopefully this has changed now, In my current job we use Cucumber + Watir to write acceptance tests and we use Ruby, Although I found it a bit steep on the learning curve initially and mainly because i havent worked in anything but .Net. Now after a couple of weeks into it I am beginning to think if this is may be the right choice, for e.g I am not even a novice in Ruby but RubyMine from JetBrains makes it easy when you are a new bee.

I still didnt want to give up exploring a .Net + cucumber combination and my search led me to this article by Richard Lawrence in his blog which compares the pros and cons of Watir and Watin.. go to . Interestingly Richard and a group of other people started driving this project called Cuke4Nuke sometime ago now which should allow us to write tests in C# for cucumber, That sounds great to me, because I am not looking at any advanced usage of cucumber, i guess my needs are pretty basic for now, I have not used it yet but all i can say at the moment is having looked at the screen cast and the background the creators of the project have given it quite a bit of thought on performance (if you read the blog you will find that they did explore using Iron Python over WATIN which was horribly slow).

A couple of months ago they released 0.3 which supports almost everything you can do with Cucumber in Ruby or Java, making C# a first class language for Cucumber. (The only missing features are small things like tags on Before and After hooks and a richer Table object.)

To install and have a play with this go to the Cuke4Nuke Wiki at http://wiki.github.com/richardlawrence/Cuke4Nuke/

Screen Cast on Cuke4Nuke and WATIN

http://www.richardlawrence.info/2009/12/03/screencast-testing-web-applications-in-net-with-cuke4nuke-and-watin/

I am going to give this a go for a spike on my new project so lets see how this goes :).