John Mitchell and I recently presented on Agile and Azure the perfect marriage of elastic scalability and requirement driven functionality.


We are intending to present in more depth at a conference in summer on the subject , plus we are already booked to give a extended talk in Manchester at the end of this month on the subject – dates to follow.
The cut down set of slides are available here and we are happy for anyone to use them and modify them as needed to promote Agile in Azure.


If we can be of any help to any team out there trying to find a relationship between Agile and Azure please do contact me and we will be happy to either offer advise or consult as required.


Using Actors in your Tests / Specifications

Context :

I had reached a situation were a lot of my tests were really doing a lot of set up work around a user – I went back to the original stories and use cases and started to understand that in fact what I was doing was replicating Scenarios by representing state within the User object, my natural go to place at this point would of been StoryQ and more of a BDD style approach. however due to time constraints I didn’t feel I could justify the weight of a BDD implementation, none the less i continued to feel uncomfortable with the amount of duplication inside my tests and also i had this feeling i wasn’t representing “ What i wanted the system to do” but instead was “ showing how the system would do it internally” and therefore was adding a lot of noise to the tests. Finally i also understood that there would be a lot more scenario based testing around user state coming up in the near future and therefore this situation would continue to degrade if i didn’t take action now. 

Options :

  • I could use either fixture or test set up to initialise some sort of hidden user set up code
  • I could write private methods for each user state
  • I could initialize some sort of user dictionary in a base class

What did i Do :

I started to think about how i would explain what each user was doing to someone , and i started to think actually i needed something more semantic and i thought well i have a development team who have to understand my code so based on that i wasn’t happy with the solutions above, i also felt like we needed to pull out and highlight the fact that this was a user in a given state.

So i decided to introduce Actors into the test domain

What is a Actor :

An Actor is a user with a name and properties it is meant to represent a real person using the system for instance

  • Danielle is a logged in user and she is 32 and therefore she is a adult, she has ordered on the site before and has a profile.
  • John is 14 and is new to the site he has registered but hasn’t verified his email address

It could be argued that i have expressed properties of state in the examples above which are not true properties on a actor as they are only constants once they have been applied by the system , i would answer that i find these to be useful design mechanics and therefore i take licence to make use of them in this fashion but i understand the potential objection.

How did you represent this in code :

Well first of all i produced a set of tests to drive out the framework,  but the end result i have detailed below:


The code in use in a production test :



Above we are looking at a ASP MVC model called User Registration with a extension method called PopulateWithUser , we then see a Actor selected form a Enum called FemaleTestUserWithGoodData, we also see a dictionary of optional override values passed into set the Email address on the actor changing it form the pre-potted data.

The Extension Method:



Above we see the two public extension methods the first takes our ASP MVC model which it extends and the selected Actor [User], the second also takes the dictionary of override values this dictionary has another Enum UserValues which defines the overridable fields the Enums are below:




We then see both extension methods delegate to functions code below:



We can see above that we create the Type from a known folder and we append the name of the selected Actor , we then use the Activator to create a instance we then call a mapping function let us first look at the mapper and them move onto the Actors.



I do not think the mapper deserves much comment other than to say that it maps between the Actor and the ASP MVC Model there are a number of way this could of been done and perhaps this will change to another extension method but for the moment I’m happy to leave it like this.

The Actor Classes:

The actor classes are in the form of a base class and some children i will show below the base class and 2 of the children to highlight the overrides and use:


We can see above in the base class that we have 2 options for customization the first is the members are virtual with protected setters this was done to give flexibility which i will probably refactor out as it proved not to be needed  , this was superseded by the SetupValues Operation which gives the capability for the object field values to be overridden form a dictionary of values you might remember this piece of code from earlier:


The object values initialized values are set up , by the child object like so :


There is opportunity within this code for further refactoring – but i think the code itself is relatively self explanatory i have included a blow up of the code below.


The last areas of interest on the class are the constructors which complete the story


Summary and Concept:

The concept behind this code is to supply a set of users with different states set and descriptive names so that we can express intent within the test encourage reuse and still be able to hide code that adds no functional value with out diluting the value of the tests.

By the numbers:
  1. We add a descriptive name to the TestUsers Enum
  2. We add a child Actor inheriting from the DefaultUser Class adding a couple of friendly constructors and setting the data values we want for the object
  3. We pass in any override values as a dictionary to the extension method which we call by creating an ASP MVC User Model and using the “.” syntax

I hope this has been helpful



London Azure User Group


Organisers: Andy Cross , Richard Conway

Other Blogs:

Slides and media:

Well i attended the London Azure User Group last Tuesday the room was filled with heavy weights and people just interested in finding out more about Azure. It turned out to be a fantastically interactive evening with talks on Diagnostics delivered by Andy Cross and a amazing talk on the Rest manipulation of the Management API by Richard Conway.

We were treated to pizza and beer and we had a some excellent opportunities to network within the group.

I think its very obvious this is the Azure presence the UK has been missing for a long time it is now up to the community to gather round this event and support Andy and Richard and really help to drive this forward.

Andy and Richard have fantastic ideas to extend this to include Code breakfasts and other engaging activities to try to sponsor Azure adoption within the community, i really feel that this is going to be  a huge success and my thanks go out to the guys behind it.

Elizabeth Rebecca Martin

Azure Consultant and Agile Evangelist

New Windows Azure User group in London , UK

Hi all,

There is a new user group being held in London on windows Azure it is being set up by world renowned expert Richard Conway and Andy Cross.

If you’re thinking of using Azure in your or going to be in your technology foot print you need to attend , here is the site:

I cant tell you how much of a privilege it is to hear from these guys – what they don’t know on azure frankly Microsoft haven’t imagined yet.


Agile or WAgile – Discussion : Agile Part 1


This post represents the first half of a pair of posts which will attempt to lay out some fundamental techniques which i have found helpful in delivering projects that are on time and fit for purpose, in this first post i would like to examine the difference between Agile and what is commonly referred to as WAgile. In the second post i would like to talk about requirement gathering using stories and prototypal design.

At the heart of Agile techniques is a principal of known as people over process, let us for a moment focus on one of the intrinsic component’s of this principal – ‘Collaboration’ – when we collaborate with each other we get more done, this is a historical fact proven in many aspects of life including great engineering achievements from the channel tunnel through to huge military campaigns.

When we collaborate in the Agile setting we need to enter a mind set which can be quite alien to traditional project management, due to the blame avoidance culture we typically find in hi $$ projects we tend to find abstraction and deflection in use rather then clarity and inclusion, this is generally driven by the fear of ‘Showing ones dirty washing , as it were’.


For projects to succeed under the Agile banner we must become a team composed from a number of organisations working to achieve an end goal ‘ producing a fantastic fit for purpose deliverable’ for this to be really achieved the boundaries between roles within the project ecosystem and their associated rights and privileges must become so blurred that typically in time they become background noise and new project centric roles spring into place which are flexible and distinct from the persons employing organisation. In short the team becomes a cooperative matrix of team centric players within the project ecosystem, rather than employees of one of the contributing companies.


If you do not feel it is possible to facilitate this type of relationship with the client and the other parties involved,  other techniques might come into play such as the use of a ‘Internal Customer’ who can be the bridge between the client and the team. However this is not optimal and many projects find themselves gradually slipping into a waterfall style methodology consequently blaming Agile for a failure when in fact they were not practising agile but a hybrid methodology that is classically referred as WAgile process – see the diagram below for how this might look.

Diagram : WAgile in action

Agile ciommunication in wgile setting v5

Within the Agile space there are 2 primary approaches to Agile Development

  • Scrum
  • eXtreme Programming

It could be argued that there are other front runners such as DSDM and then we must also consider the LEAN methodology sets as well, the distinction between different flavours of Iterative development techniques  is becoming increasingly more blurred as this group of methodologies gather a growing number of converts each contributing their distinctive flavour to the community.

However ‘What is Agile?’ is beyond the material I wish to discuss in this post , so let us instead accept that there are a number of buckets of techniques which all at their heart have the principals of the Agile Manifesto ( the guiding principles of which I quote for convenience below:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

As you can imagine with this amount of scope for variation an agile environment can take many shapes; so instead of trying to cover each possible variation, I will provide below a diagram which illustrates some of the common factors that can be found in a Agile environment:


The biggest differentiator between the WAgile illustration  and the Agile illustration is the communication dynamics between stakeholders, the team, we also see a distinct difference in the team value statements.


The WAgile environment uses artefacts such as project plans , long meetings , vast swathes of documentation to try to provide an accountable environment were every thing is locked down to the following factors:

  • Who takes responsibility for doing it
  • How long will it take
  • Who holds liability if it all goes wrong
  • Who’s going to pay for it
  • What is the immediate profit margin on the work
  • Do we project that this will take us over budget
  • The above quite often translates into stress / toxic pressure expressed as can we push elements of the team harder to get this done faster

While there are important issues illustrated in these points, trying to mitigate them creates a huge risk to project completion. Classically the techniques used in a Waterfall / WAgile environment to constantly answer and document the above points leads to a lack of freedom and flexibility  and a total inability to do what is needed to just get it done at the coal face. It should be noted that we also generate a environment of fear where people and companies are scared to take risks, once there opinions or improve quality.

With the on-going need to document everything and to have a paper trails for all aspects of the project, we find we end up creating roles within the team who’s sole job is to protect the company or shift liability onto other individuals, partners or companies. Thus it can easily be seen that in the attempts to lock down the Cost, Liability, exacting time frames and Risk – we find that making even the smallest movement in the project space has huge cost and requires layers of sign off and discussion this effectively knee caps the teams ability to flex to changing conditions and to innovate when the opportunity presents itself. All of the above leads to teams creating yet more documentation in attempts to fully lock down requirements in advance including some of the following documents which quite often make for miniature novels they are so great in length.

  • BRS [Business Requirement Specifications]
  • Static Wireframes
  • Business flow diagrams
  • Huge Class diagrams that document architecture which might not be needed
  • Ultra high quality creative tied down to the exact pixel
  • In depth NFR’s [None Functional Requirements]
  • Massive Risk logs which at times almost go as far as to include acts of god

Worst still for the team is the fact that most of the above form some sort of reference material within the overarching contractual agreement which generally means making changes to them takes a huge amount of time, effort and stress. One of the other factors to add into the mix is that quite often the wrong people have written these documents or the right people have written them under huge time pressures – the end result is tends to be more a set of hand-cuffs as opposed to empowerment.

The Agile environment drives for the concept of people over process, as such the number of inflexible paper artefacts are reduced, meetings tend to take the format of time boxed [normally 15 mins or less] whole team meetings these are quite often known as touch point meetings. In terms of risk most teams tend to practise ‘Don’t put off for tomorrow what you can deal with today‘ This can take the form of writing technical debt cards and having a regular technical debt review cycle or more preferable dealing with problems as they pop up.

The classic Agile environment will also try to practise philosophies like ‘Better to ask forgiveness , than to ask permission’ in general the the Agile player is a brave soul who just gets in there and gets it done, he can afford to work like this because of the tight communication across the team elements regardless of discipline he/she is given further confidence by knowing that team shares:

  • Shared Code Ownership
  • Shared Feature Ownership
  • Shared Liability
  • Shared responsibility for getting right
  • The team practises open communication and transparency across all discipline
  • Fear is not part of the team culture
  • The team makes joint decisions in transparent meeting and the concept of ‘Command and Control’ has no place in the Agile teams culture
  • Personal Ego is left at the door
  • Team Ego and identity of team self is implicit to an agile team
  • One is none , two is one [Pair Working – across planning, programming and all other applicable activities within a agile team]

One of the techniques an Agile team frequently borrows from Lean methodology is the concept of a [Red flag], this concept says that no matter a persons position inside an Agile team that person can raise a red flag , physically , by Email, by calling a meeting when they believe things are going to come off the rails and the effect of this action is everyone no matter their position stops and there is a conversation to put the situation right before the team continues.

The one main driving force behind an Agile team is not who’s fault it is , a true agile team even one split across organisations operates on a Zero blame culture because it operates on a understanding that everyone is doing there absolute best to achieve one single aim – Continually deliver high quality , demonstrable software that is 100% fit for purpose and it is this one aim that members of an Agile team no matter the company they represent or the horizontal stripe to which they belong in the ecosystem strive for, and this is one of the biggest differences between WAgile / waterfall and true Agile, true agile concerns itself totally with delivery not politics.

I as the author of this post can understand that the above statement may seem naive in the high dollar industry in which most projects live, but I would challenge back to you and ask you one simple question – would you bet all your process , artefacts and safeguards against project success – because an empowered agile team given an even playing field with a bought in client will be successful and will deliver with low bug counts and high feature saturation.

Configuring Black Box BDD with Watin , CassiniDev, NUnit , StoryQ, ASPMVCContrib, Reshaper

Example Source code :



On projects where the view and its contents need to be assured by the developer, we can implement Black Box BDD / Closed Box BDD. This technique is very much akin to acceptance testing with tools such a Selenium or Fitness.

In simple terms we will see in the following  example how to  use Watin and StoryQ to Test drive from the users perspective , the user interface in this case we will be using ASP MVC 3 View.



To implement this technique we need to implement / use a visual driver, the driver will act as a user who interacting with the interface for the system we are trying to build. This will allow the developer to drive out the system under construction from above the user interface.

In this case we are using a web front end and have opted for Watin. We also need a testing framework and i have opted to use StoryQ and Nunit.

In addition we will also be making use for the MVCContrib.Watin helper library

Our package set up will be done with NuGet.

Setting up NuGet

1. Open the Extension Manager


2. Search for the NuGet package and install




3. Add your NuGet references



Basic Solution

Once the solution framework is in place we add a class library in which we then write a few lines of code which drive us to go get NUnit.


NuGet to the rescue


Clicking back in our code file Resharper now helps us to set up the Using for the NUnit references NuGet has added for us.


Enter StoryQ

We now start to implement the Story again we need to use NuGet to get our StoryQ dll also you will note that i have added a tag with my requirement card number in.



With the StoryQ references in place and our using statements fixed up we can go ahead and write our basic story


Next we add our basic scenario im going to go for the happy path as defined on my fictional requirement card.


We can see that i have described the Happy path through the story for my customer or rather i have implemented the fictional BA’s / Agile Customers idea of what the happy path should look like next with a little Resharper magic (Alt+enter on the Red ) i will implement the stubs for the scenario steps.



We then run the test runner (in this case Resharper has use covered there to) and see that our NotImplementedException in each of our steps body translates to a pending status, so were in a good place, to start implementing.

Enter Watin

Next we need to drive the web page so we can emulate a Customer on our web site in best Blue Peter tradition enter stage right my base class.




I have used this base class a number of times and it suits my needs to make use of it we need to add some package references to support Watin so our references now look like this:


Enter CassiniDev (Portable Web server)

We still have some red in the class next lets deal with the WebServer portion of the class for this we will use a the CassiniDev project this basically an attempt to get around the limitations of Cassini ( some of which are documented here:

Cassini dev has to be downloaded from the distribution site and manually added it can be found here: so lets go ahead and download and reference this dll.



Next we need to add a App.Config file and set up Ports and Local Address.


We now add the sections to the App.Config file:


NUnit Configuration to run as STA


CassiniDev & Watin Configuration


Once the configuration file is in place we need to add a reference to the System.Configuration namespace then Resharper we ill help us to fix up our using’s.

The base class should now be completed configured and we can now make use of it to provide the Browser, Server and Driver objects to our tests.

Operation Mapping as follows:

    Final step is to inherit from the base class and write some fixture Setup and TearDown code


    *Note the only other thing you MAY  need to do depending on your OS configuration and if you are running Visual Studio as administrator,  is make sure Cassinidev has permissions to create com objects and isn’t marked as read only.
    **Note If you get a bad Image exception you need to set your test assembly to run as X86


Implementing Steps and Web functionality

Ok so al that is building and we still have our steps reporting pending so were set, we can now turn our attention to making the steps pass.



We now write our implementation for our first step


This now leads use to create our web project im going to go with ASPMVC3 here so lets add that project to our solution and change our App.Config to find our web project.


We need to match our webserver port setting to match out specification config settings and make sure we have a identical end to end experience.

Next we run our test which results in a 404 not found

so we implement our Controller and our View


We rerun our test and we get a fail like so :


So next we hop into the view and set the title text


That’s it we now have  a passing step


Now all that remains is to implement the rest of the step and get a passing green bar.

I have supplied the sample up to this point , i will leave the other steps for you to complete as practise – any problems please drop me a email.


Experiences Of Microsoft

Recently i attended a Microsoft event in Seattle (USA) and although i can say no more than that about the event or what was discussed due to NDA restrictions.

I would like to comment on Microsoft and how we were treated.

Before setting off i had been told mixed feedback about these types of Microsoft events by an associate and i was very apprehensive of what the experience would be like. I would however like to state that Microsoft were stars  they treated us like royal guests , there was plenty of food , they took care of any problems that came up smoothly and the gentleman who was orchestrating the conversations and the event did an amazing job , Well done mate!

The value of the event was in debate before going , but i learnt a lot , and i think i was able to be a very vocal part of conversations which i hope will influence future product direction , that was certainly the feeling i was left with.

Although Microsoft do not pay for travel and off premise expense the value of this event to both myself and the organisation i represent well exceeds any cost involved.

Although i would say for me this opened up the world of Microsoft for me and showed how much effort they put in into trying to get there product offering right, while i was sat there listening to the teams present i thought to myself i wish some of the bigger companies i have worked for in the past were as concerned as Microsoft are about public adoption of their products and the experience the end user has using there software.

It also showed me that for the plugged in developers there is a ton of opportunity to interact with Microsoft in there space, but if you are not plugged in at a company and an individual level you miss so much.

Anyway thank you to MS and the Seattle teams for looking after me.