Building Agile Teams – Not sure?

 

In the process of adopting agile methodologies, some organisations don't really pay attention to how these teams are formed. Forming a team for a project is different from forming teams in organisation. The latter needs a lot of thought, compromise and patience. owing to the needs of the business/client. I don't understand why organisations bother adopting agile without this view. It is all done for that client/product/project who is important, yes that's the primary objective but then that doesn't cut it when you mess with the peoples minds when we constantly moving them around teams.  I would go as far as saying at least 30-40% of this effort is wasted,  every time a team is put together they go through the same cycle of storming, forming ,norming and performing. I really think this is the most underutilised concept from Hoffman, It is used as punch lines on slides with little attention to the consequences of the process. Teams formed should not be broken without valid reasons (sorry multiple projects and cost are not good enough reasons, let me know if you have other reasons, I know I have a few)

At this point you will be thinking this is just the usual crap people talk about. Here is a hint if you use the word resource for a team member, you have never paid attention to the do’s and don’ts listed below. The change in perception that's needed is, that a skilled technologist in one context is not productive or efficient in another. The context here is that of a product , project or service being worked on. This context is never constant in IT and all you can do is keep the team constant, (even your machines are changing with updates everyday). Can two moving parts in a system bringing stability unless the forces negate each other? Are there exceptions not sure…

1. Don't build teams of specialists.

When companies organise teams by discipline such as testers, analysts , designers, and developers, All they have done is create silos of specialists who are not effective in how they work together as a software development team. The dynamics between individuals with in a team are quite different to the ones who work in teams founded on disciplines. That directly reflects on how efficient they are and how productive they are. These teams based on disciplines create the biggest hurdle. How will you align the goals of these teams based on discipline with the goals of a project they working on ? It doesn't make sense because they achieve neither.

2. Don't share people unless they are specialists.

The whole theory that people in a team founded on a discipline are specialists is not true. You become a specialist by virtue of doing something valuable in a project or system. Do not share the basic functional roles of analysts, testers and developers between projects, it is not as efficient on cost as you perceive it to be.There used to be a time where i used to acknowledge the cost benefit of sharing certain roles between projects, but increasingly in recent times I have lost faith in this idea. To be honest it does more harm and costs you more (not accounted or measured most times) than any real cost benefit. I don't think the human mind is capable of treating two goals with equal priority if a person is shared between teams, If ever you wanted to do this, it may be achieved in a cross functional team, where a specialist is shared and the team has a bunch of all-rounder's.

3. Build Cross Functional teams

Building software has been split into so many functional roles these days, it is beyond me now to understand why.  Is it difficult for someone to be able to do a bit of analysis, and testing along side developing code. I am not asking them to be a specialist in those disciplines neither am I asking them to change there careers. I personally feel quite proud of being able to do more than one functional role. By being cross functional all that is expected is you should be able to do other kinds of work required for the team so you keep the work flowing on your Kanban. But I have noticed teams increasingly blocking work and team members not picking a card that needs to move further to done. This may also be compounded by managers feeling the need for specialists only to do that work. Many a specialists have screwed up and I am witness to it, so what is troubling teams to encourage new bees/ all rounder's to take a chance. There is always the specialist to come back and review it?

4. Encourage common goals for the teams.

Career progression and teams based on disciplines have murdered the whole system and have pampered individuals into thinking that it is normal to be able to work in one functional area and it is not there responsibility to do anything else that is required to achieve the common goal. Are they specialists in there own functional area ? I doubt this theory because a majority of them are not really any kind of experts they do just about enough to keep it going and make just about the same mistakes in judgement as other team members in other functional roles. The corporate annual review system has completely brain trained people to think that they need to meet there personal goals before the team goals (very few places have these). Since this is tied up to some kind of bonus , the motivation is pretty high to get at least your personal goals right. This system in my view is the worst evil in most organisations and is a passive killing machine.

5. Don’t encourage Big Teams

Any team more than 8 – 10 is big. By building teams larger than this size you end up increasing overheads. This further translates into team members beginning to feel they don't get enough information and time to function properly. This leads to lesser visibility on the flow of work and pushes some members of the team to delegate work and in some extreme cases to micro manage,

6. Don’t use Agile if team is working as a resource pool

Agile cant work with this model where multiple people work in  multiple projects as if they were a single team. So don't force agile to be used if your resource management is based on this model, and ask why agile doesn't work. Best not to use agile in this model.

The Agility Grid in organisations

We all work in an industry which is called Information Technology where information is the most under-rated commodity. We have structures in place which were not modelled for this industry. We have been retrofitting our operational and management models based on principles of other industries. The irony of all this not all of us are from the era that this started nor are we from other industries. A majority of us started our careers in this industry and yet we have some of the most rigid organisations and now in the last 5 – 10 years we have been trying too hard to make these structures agile and flexible.
Organisations have structures, some horizontally aligned and some vertically aligned. When organisations embark the path of using/enabling agile practices (which is the trend at the moment in IT), they tend not to reorganise themselves to enable this. A very typical observation has been that a lot of change happens from middle management to the operational teams (in IT development teams).
I think at this point it is important to reiterate that being agile is not just a following good software development practices and processes and cannot be purely achieved by fixing one business unit. It is really an outcome of collaboration of several business units in the simplest possible way, so that when they work collaboratively the outputs of each business unit enable other business units to work efficiently with agility in an iterative way. The iterative nature needs to be reflected in how they hire people, how they budget, how they specify products and also how they sell them. Purely developing a product iteratively is only the first step. Reflecting on this and modelling your business around it is the optimum path for a business which is agile
Here is my theory which i have been pondering with for a while in my head, it is in no way a pro matrix management theory, however it does seem to present hints that it may be the way to go if planned and executed with care.
The Grid
An organisation is a grid effectively, where each line has people and resources which produce forces. These forces operate (upwards/downwards) or (left/right). At all the intersections of the forces on the grid, the forces align/oppose each other to enable flow of information and change. Where forces oppose each other you will find resistance and inability to produce results , where forces support each other you will find progress and agility.
No I am not preaching matrix management but I am trying to apply forces in physics to analyse the situation and find out which organisation can adapt to agility better. I am not sure everyone will agree but the majority of organisations have decision makers along the vertical lines and enablers on the horizontal lines. This is purely based on what i have observed than anything in some ways my interpretation
In horizontal organisations, there tend to be more enablers than decision makers. This is fine so as to make progress and internal changes flow smoothly. However the ability  to react to changes i.e external forces (could say Porters 5 forces) is reduced. This is inevitable due to a reduction of or slower decision making process. So are we saying this is not going to work. No, on the contrary seems like a horizontal organisation is an easier one to model and adapt to agility. A combination of collaboration practices that balance internal forces and and how information is relayed and used make it a more viable change. Collaboration is not just about how people work with each other it is also how information is relayed and how it is consumed in the organisation. Horizontally structured organisations with good communication channels and a democratic decision making process could adapt to agility more efficiently.
So where does this leave vertical organisations, obviously based on the grid theory above there tend to be more decision makers than enablers, This is fine however progress is limited as there are less enablers, You may find that organisations which compete on market share generally fit in here, they tend not to be the innovative ones, even if they did it might be worth looking at the product life cycle of these organisations and see how short the life span of there products are. P&L’s may tell otherwise, but look into these organisations and you will find that they have a tinge of diversifying into multiple markets or industries. A relatively high ratio of  decision makers,tend to put these organisations in the mode of reacting to incidents than change of any form. This is obviously because there are lesser enablers with a reduced capacity to induce a positive change or any form of improvement. This organisation structure is the the toughest nut to crack. However this is the most common structure in the industry.
Management structures reflect this aspect more than any other form.This I believe is a consequence of modelling our management structures along the lines of the manufacturing industries, compounded by factors such as culture, control and power. This reflects itself in governance and operations. I am not going to elaborate any further but I simply feel the manufacturing line model of management from the 80’s no longer suits the 21st century organisation which is aspiring to be agile.
Move on Management 3.0 is that the answer, not entirely , there is more to an organisation than management, We haven't even skimmed other business functions such as innovation , sales, marketing , strategy etc .. These aspects need to operate differently, which comes back to validate my original conclusion that it is not enough to just change a few business units to achieve agility, you have more on your hands than you think you do..

Teamcity – Automate to find Broken Links on your website

If you work on a website , one of the smoke tests for your website could be to check that no links on your site are broken. And if the CI server can do this on every check-in there is nothing better than that as you can keep an eye it for every change. Further repurposing such a test as a smoke test for every deployment or even for monitoring purposes is extremely useful productive - good luck doing this manually  (When done on Live make sure there is a filter in Google Analytics for your test machines to be excluded)

Off the many tools available out there, the application at http://linkchecker.sourceforge.net/ seems to fit the bill for CI, Supports several modes see docs for more info

Download it and install it on your development machine

To run the test locally (should install linkchecker-8.1 on the machine), you could run the following command eg."C:\Program Files (x86)\LinkChecker\linkchecker.exe" http://sometesturl.com/ --file-output=html/report.html --recursion-level=-1

This has to be installed on all TeamCity agents. To hook up a build add a build step as below which is equivalent to the command above

This will allow you to hook a build on Teamcity to run a test which spiders through your site checking for broken links.

The command above produces a report with the name linkchecker-report.html in the agents working folder. If you push this html as an artifact and add a report tab on the Teamcity server called “Link Checker Report” for the linkchecker-report.html artifiac, you should be able to see the report after every build is run

For broken links the build will fail as linkchecker will return a code 1 on the command line, for success builds it returns a 0

See below for an example report which uses report tabs on teamcity to show the report

Effect Mapping to manage products

Just been to this talk by Gojko on Product Management using Effect Mapping. It is a technique which is useful for high level project visualisation. It is very similar to mind mapping technique where stakeholders, users and teams colloborate on project scope.

It helps reduce scope of wish lists and helps teams focus on business goals by asking the questions Why?, Who?, How? and What? in this orders

Why? Allows you to narrow down to the business goal. This is the centre piece of your effect map from where all other discussions should start and reason upon

Who? It is not the user but it is who can cause the desired effect to achieve the business goal. In most cases these are project/ product stakeholders.

How? For each stakeholder , identify how the target group can achieve or obstruct the desired effect in real life and not in terms of software, these should effectively be stakeholder needs

What? For each stakeholder identify what business activities or software capabilities would support the needs of the stakeholder. These become your epics in the product backlog

At the end of the effect map both the stakeholders and team should be able to see the synergy of the business goals and what needs to be achieved.

For more see, Gojko’s white paper on this see http://gojko.net/effect-map

Some advice from people who have used this are..

• Getting the right number of people can be a challenge
• Staying focussed and at the right level of detail is important
• Ensuring enough focus on the how is important
• Keeping everyone away from solutionising is a real big challenge when technical people are involved
• Ideal group size of 5-8 when working for a time box of 2-3 hours
• Will be of immense value to the business

This technique is not necessarily something for agile projects you could use it even for waterfall projects

A useful tool I have found which you can use for this is at www.mindmeister.com. Check it out its pretty handy. Even if you are a developer striving to do something on your own , if you put your ideas on a mind map it will help you visualize the idea.

User Story - A Promise to have a conversation

 
Time and again it is important to constantly remind your team that a User story is not just a way of defining a requirement but is actually the premise on which you promise to have conversations with the user. It is by no means a finalised description of what the system should be doing. The first time it is written the analyst or product owner only has as much information as the user gives them. This information is pretty much raw most often a wish list off some post-it notes on the edge of the users monitor. It will have information of what the user wants to achieve or the grand plan of how something could be done brilliantly to save money or achieve a business goal. It will not tell you what the user wants the system to do.
This is where collaboration is fundamental to the idea of agile development ( should i say ADD – Agile Driven Development). The user story is to be evolved by having conversations between various functional experts. By functional experts I mean a QA, a developer, a business analyst or even a UI designer for that matter. The question is why? I guess it’s because these functional experts can think of the software that is to be built with a view of what the system should do, A user story should convey both what the user wants to do and what the system will do to be complete, clearly the initial draft of these stories didn’t do this.

When a developer evolves a story on his own he is going to make sure it is technically brilliant (may be not always) and eventually forget what the user wants , in most cases this conversation ends up in the developer trying to define what the system should do and what the user wants..  how many over engineered systems have we not seen and been part of in the past

When a UI designer is going to evolve it on his own he is going to make sure it is pretty software and most likely to make it usable but with lack of clarity of the functionality that the user really needs, he just has his wireframes or prototypes, which shows the user the dream he wants to have

When a QA is going to evolve this on his own he is going to make sure it is very testable, infact so testable that they start defining behaviour of the application and the implementation of the software even though they may or may not match what the user wants.. oh well make it testable but so testable that the stuff you build is not usable.

The analyst on the other hand is so caught up with making sure he conveys what the user wants he forgets most often how to test the functionality or in some case forgets to tell the team what the system should do  , well don’t blame him they are not the functional experts on the technical implementation of a system

We have seen these things happening all the time, any form of methodology without collaboration kind of summarises the situation in which these things happen. Alright then, so we can’t do without collaboration so what now and how far do we go with collaboration? How do we know where to stop, well I am going to have to be vague and say well it’s for the team to figure it out in the context of the system they are working but then, I guess some of the answer lies in the ability of the team and the user to work towards coming up with stories which adhere to INSPECT and the story itself becoming the documentation of the system.

As Gojko says in his book “Specification by Example” stories evolve into living documentation of the system. When you can actually read a story and express in simple English, the aspect of what the user wants to do and what the system is doing to achieve the users need, you could say you have reached that point where you can stop and move on to the next bit of functionality.

Again living documentation is not written once; it evolves over a period of time by refactoring constantly; Teams that collaborate constantly recognise this need to bring the stories used to build the system in line with the domain concepts in the system, and vice versa, it is a constant cycle of refactor and improve.. Oh should I say iterate and continuously improve... Rings a bell... Agile?. In reality, collaboration is under-rated by teams and it is something teams think they should do because it needs to be done. Most agile teams do this once for every story (I am laughing already) while estimating the story not so much while actually implementing it. That said there are also teams which constantly collaborate. I guess question is which team are you working in and what are you going to do about it ?

Step by Step - Cucumber, WatiR and Ruby installation tips

There are few road blocks you hit when you go about the process of installing Cucumber, Watir and Ruby the first time, you have to search all the information and then as you install there are some things that work while some dont , I just thought it may be a good idea to consolidate the information in one place for myself if i do run into this situation of having to install this again. I have tried and tested this thrice and use the same process to install our test agents.

• Installing Ruby

#Tip – Choosing the version of Ruby installer

Watir is stable with Ruby 1.8.7 so dont carried away and install 1.9.x of ruby , you learn the hard way that it is not going to work properly.

See Http://watir.com/installation for updates on when 1.9.x support will be provided. Go to http://rubyforge.org/frs/download.php/74293/rubyinstaller-1.8.7-p334.exe download the exe and run the installer. I chose the installation folder to be called just ruby as I want to avoid installing multiple versions for now.

 

• Ruby Path

Check if "c:\ruby\bin" is included in the path (else run PATH=%PATH%;c:\ruby\bin at the command prompt)

• Installing the Dev Kit for Ruby

Download http://github.com/downloads/oneclick/rubyinstaller/DevKit-tdm-32-4.5.1-20101214-1400-sfx.exe .

1. Click on it to extract files to a folder <DEV-KIT-FOLDER>.
2. Open a command prompt for the <DEV-KIT-FOLDER>.
3. Run the command “ruby dk.rb init”
4. Run the command “ruby dk.rb install”

Not sure if you need this but run a “gem update system” and it should say Nothing to update :).

• Installing gems

Now at the command prompt

1. Run “gem install cucumber”.
2. Run “gem install watir”
3. Run “gem install “win32console”
4. Run “gem install rspec”

• Installing ANSI con – if you are unable to see colours on your console window when you run a cucumber feature, you may need to install ANSICON

1. Go to http://adoxa.110mb.com/ansicon . Download AnsiCon 140.
2. Extract the files.
3. Open a command prompt for the folder you have extracted the files in
   cd to x64 folder if you use a 64 bit machine or x86 folder if you use a 32 bit machine
   type "ansicon.exe -i"
   Close the command prompt , open a new one

This should be sufficient to run cucumber features now. In a weeks time I will post a project framework with some useful stuff for ruby / selenium / cucumber which can be downloaded so you can go about building tests quickly

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 – 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 :).