Concerns about NBehave

This is an attempt to answer Scott Bellware’s concerns and questions about NBehave.

Scott, first off thanks for posing the question I really appreciate open honest feedback.

I want to make sure that everyone understands that I don’t treat Agile as a prescriptive process that has to be rigidly followed. The contextual nature of Agile and its supporting practices require that individuals analyze and determine the best tools to use for the job.

“Stories are intentionally malleable. They can be split, joined, negotiated, re-negotiated, and changed. And ultimately, they’re totally disposable. Once they’re done, they can be torn up and thrown away.”

Speaking of my specific context, I work for a financial institution that has heavy Government regulatory oversight concerning software development, in particular requirements traceability.

I agree with Scott that Stories should be malleable and the simplest mechanism should be taken in order to determine business value out of the software you are creating. When I was first introduced to Agile we started off with XP practices during the planning phase and came up with stories on index cards. It wasn’t till our auditing department became more aware of certain regulatory constraints (that I am still contesting to this day) where we had to look at more heavy weight measures of documenting our stories (requirements). As you can imagine this became source of contention amongst the team as some of the BA’s and testers wanted to immediately go back to a heavy weight approach of requirement authoring. My remediation to this was to create the requirements goal form and feature cards seen below. This at least got me away from IEEE 830 style requirements, that we all know do not work!

As you can imagine this worked great up until we had a change to the Goal or the Feature. Then the traditionalist threw up the change control flag and I cringed. But let’s talk about why they threw up the flag in the first place.

• · Is it because the code that was being affected was difficult to change? No
  • · Is it because the testing team had to change their acceptance test that they didn’t have automated at the time and only documented steps within a spread sheet? Yes
    • · Is it because the business had to go back and make sure they properly documented the changes in the feature and in the requirement goal form? Yes </ul> So you see it is not that the development team that was not welcoming the change, in fact it took the development team 10 minutes to make a change, where it took the documentation and testing efforts several hours to make a change on average. The point I am trying to make is that Agile methodologies in general (software practices aside) engage teams to find a way to solve perceived complex issues such as change control and find a simpler solution to enable change.

    In the scenario above Automated Acceptance Testing was the logical choice to curve the acceptance testing documentation since now it would be housed in a tool that propagated changes and had auditing features built in. The requirements goal side of the house was, is still a contention point since such a simple form is still not updated. There is talk about more enterprise methods of governing the requirement goals but I am not one to promote enterprise level product suites that cost hundreds of thousands of dollars.

    Then one day I came across Dan North’s post on rbehave. What a concept, story authoring at the source code level! This made so much sense to me I quickly found a hackish way to make it work in C#. To my amazement it worked and I started to ponder the benefits within my organization. The key was to make the framework as easy as possible for a product owner to author the story within the source code. Bring the focus and the continuity around the source code as point of reference to the inception of the domain concepts. Utilizing the Visual Studio IDE and ReSharper you could really ask the question to the code, “why is this FeeTemplate object here?” you can than quickly trace back to a story and see why it was created. If a domain object doesn’t trace back to a story, you should question the validity of that domain object.

    So it has two benefits Domain Validation and requirements traceability. Not to mention that if a product owner wants to make a change to a story they simply check out the story make the change with the developer and tester on hand, check in the story to the source code repository which prompts the developer and the tester to make the appropriate changes.

    NBehave is still in a beta state so I can’t call it a success or a failure yet but I will say that it has tremendous potential for organizations that have instituted Agile but have to deal with more formal regulatory constraints.

    Having said that, I would like to point out that all Agile Practioners should take a step back and question the tools they are using? Does NBehave make sense for small or medium size shops where you don’t have to worry about formal processes, probably not. Start with the simplest mechanism, in the case of story authoring that would probably be index cards. If you find that you need more control over your story authoring evolve to the next level of simplicity. If it leads to NBehave great! If it doesn’t even better! The point is remembering the first core value of the Agile Manifesto.

    Individuals and interactions over processes and tools

    Look to the left before you leap to the right!

    And Scott thanks again for making me think if what I was doing is worthwhile.