Agile Sharepoint development by 21apps and Andrew Woodward MVP

Following on from my rant response yesterday about the more negative views from the SharePoint community my reading this morning was so much more positive.

Unit Testing Workflows

In my response to a question from Aaron Weiker I said that I would like to see much more guidance and investigation into the way we approach Unit Testing workflows in SharePoint,  so it was great to find Richard Fennell is doing a lot of work in this area.  I have been working with Typemock Isolator, CThru and SilverUnit testing recently (post coming) and was very interested to see that Richard had picked up this whilst looking for a possible solution to the challenges of Unit Testing SharePoint workflows; something I have to confess I had not even considered.

I’m looking forward to seeing where Richard gets with this and also the use of Fit/Fitness, although I’m personally not a big fan of the way tables are used to define the tests.

Integration Testing SharePoint from MSTest

Having been a bit behind with my reviews of the latest Codeplex P&P project I missed the discussion with Francis on how they found a use for Typemock Isolator to do Integration tests.

The code is really very very simple,  many will be glad to hear, and deals with the places where your code makes a call to SPContext.Current or SPFarm.Local.

The simple ideas really are the best ones.

As you can see,  a few small steps for testing but big steps for SharePoint testing and a demonstration that in general the SharePoint community is committed to improving the way solutions are developed.

Just read a post by Sahil Malik where he gives his reasons for saying

TDD + SharePoint 2007? Well - screw it! Not worth it IMO.

The reason for his statement is that he sees the actual C# code developed as being a very small % of the total SharePoint project and the effort to do this as not worth the return when you consider the project costs overall.

The problem is, like so many people, he is getting TDD mixed up with doing good development.  He dismisses TDD because it is harder to do in SharePoint because of the API.  It’s not TDD that makes it harder,  it being able to isolate the API and design testable code that is harder.

If you listened to the SharePoint Podshow I did with Eric Shupps we were in agreement that what actually mattered was that you developed good quality code,  that you had the processes in place to enable code reviews, unit testing, integration testing, and the like, that all go together to ensure the code you do develop for your SharePoint solutions is Enterprise ready.

I hold my hands up, I do talks on TDD and SharePoint.  I don’t do this because I think that everyone should do this on day one,  I do it because people have used SharePoint as an excuse to not doing quality development.  The comment ‘we can’t do unit testing because we are using SharePoint’ has been common among development teams,  other just don’t do unit testing anyway so it never even cropped up.   So if I can demonstrate the you can go all the way and actually code your solution using a technique like TDD then this argument no longer holds water.

What the question should be

Quality Development and SharePoint, is it worth doing?

And the answer to that is a big Hell Yes!

And if your happen to use TDD to write some of that quality code, then that’s good too.

The key thing to remember is that you need to make a judgement call about the value; in Sahil’s defence he did mention this.  What I can’t take is that he adopts the ’screw it’ stance before he even starts. This to me is a much of a problem as the people at the other end of the spectrum that think you can ONLY code using TDD.

Scrum as an agile approach is great, it allows teams to get up to speed quickly with agile and also enable the business to understand what being agile means.  The problem is that people often just do Scrum.  Doing Scrum is not enough,  it is a great place to start and will help you with your projects but your team still need to get the engineering disciplines in place, they still need to work on doing the right thing the right way and with level of quality demanded by the business.

Jack Milunsky posted a nice article that talks about why Measuring Velocity is not enough.

Like burndown charts, velocity is just another metric which the team can use to reach what I believe is the ultimate goal - sustainable throughput. Velocity in my opinion, is not a metric for determining productivity.

What I really liked, and is something that I am going to be covering a lot more over the coming months is the conclusion

.in order to enhance productivity there are many things one can do:

* You have to get the requirements down pat. The best way to do this is to work with the customer to define the user stories and get their intent up-front.
* Ensure you are capturing the acceptance test criteria from the customer up-front. This helps solve the greatest risk of all - getting the wrong product.
* Define your definition of "done" up-front so that there’s no argument at the end.
* Ensure you build quality in right from the start.

The conclusion can be split into two areas

1. Understanding the Requirements
2. Getting your process right

Getting your process right is something the development teams control,  and there is a lot of information out there today about techniques like Test Driven Development, Continuous Integration and the like that all focus on the development process and quality.  

Understanding the the requirements on the other hand and getting the business to provide you with valid and testable user stories is an area of agile development that I feel has been neglected.  There are great books that have been written on how to write user stories and how to ensure they are testable.   There are other books aimed at the business analysts about how to gather requirements.  However these have never come together, agile development teams don’t look much be the user stories. 

This pushing back beyond the user stories and into the way requirements are gathered and the business is understood is something I have been working on for a while.  And with this push back beyond the user story it is clear the way to get business and customer buy in to the agile development approach is to really change the way businesses approach the complex problems they are trying to solve.

I have some really exciting things to announce over the coming weeks that will really take this discussion forward, working with some of the most visionary guys in the field.

Rest assured there will be a very big SharePoint focus.

I recently wrote about my experience of doing agile development in a team of one,  where I questioned the idea that ‘If your the only member of the team is it really worth going through the same agile development process that you would in a team of eight?’

One interesting test for the project was that it was not going to be developed in one go,  the days spent on this project would need to fit around other work and I want to see how using agile techniques could help to keep the momentum and also retain the knowledge from the previous activities in a format that would be easy to pick up.

Sprint 1 - Day 1 was 15th May 2009

Sprint 1 - Day 2 was 4th June 2009 a full 20 days gap!

Daily Scrum

Always start the day with a scrum and ensure that you come prepared.  This meant that I needed to be able to answer the following questions

• What did you achieve yesterday?
• What are you going to achieve today?
• Any blockers preventing you from doing this?

Take a minute,  try and think back 20 days and remember exactly what you had achieved?   Difficult isn’t it!  This is where using a process really helped,  I started by looking at the my white board to see where I left the project.

Interestingly I had not ‘Done’ anything (refer to Day 1 for the definition of Done and how I structure my white board), my Burndown for Day 1 was looking very sad so I won’t even show it.  What I could however see was that I had completed the work on one story,  the second story was in progress and that I had not started the 3rd.  The observant will also notice I have a couple of new stories in the backlog.

If I had not been working on the project for the past 20 days how come there are new stories?

Adding to the Backlog

One of the tenets of being agile is that you work at a sustainable pace,  you don’t do more work than is possible and you allow your team to go home, see the family and have a beer or two.  What happens when you team is having that beer?  They think about work, and have ideas about ways to do things or new requirements and then write these down as new stories.  The same is true for the business, whilst the team is busy working on the current iteration the business is thinking about what they need, reacting to change and then feeding this into the backlog as new stories.  They may even take away some stories that are no longer needed.

What does this mean?

Well for Sprint 1 nothing,  we have agreed a short period of work where we can focus on the deliverables.   The new stories will be considered for Sprint 2 and for any removed stories we will have the warm feeling that we had not spent too long on in big up front design tasks and documentation.

The Rest of Day 2

After the scrum I reviewed the solution I had put together,  and compared this to the stories.  At the end of Day 1 I had a WSP  and some features that meant I could see what I had done and actually use it.  The ability to use the solution very early in the process is another of the big benefits to being agile.  It allows people to see it for real, to make comment and also to make changes if it is not how they envisaged it.

Needless to say I made some changes,  there were bits that I had added that on reflection were not required,  I removed the extra items and did some refactoring of the solution to make it more compact and understandable.

The rest of the day went pretty well,  and at the end of Sprint 1 I had not actually written any C# code or created any Unit Tests.  The solution at the end of the sprint I had completed the three stories I had planned.  I have to confess that I did do a few extra hours work at the end of this day (Sprint) in order to complete the stories. This can be a common scenario where the a stress levels and work will increase towards the end of the Sprint.  The same if true of Waterfall projects but at the end of these projects there is just so much more that is expected to be done the stress levels go off the scale.

The final tasks for the end of Sprint 1 was to do a “Show and Tell” to the business.  To make this more real,  and to be able to provide a summary once the project is released I record a Screencast demonstrating what had been done.   It may sound silly doing the screen cast or doing a show and tell to yourself, however what it does do is make you bring together everything and ensure that what you said was done, actually was done.

Sprint 1 Retrospective

In order to improve our processes, to produce better quality solutions and to make ourselves more productive we need to look at what happened in the Sprint, the good things as well as the challenging ones and also look for ways to improve.

Things that went well

• Adopted great agile techniques
• Was able to pickup after a break
• Good use of tools like WSPBuilder and hosted source control

Things to improve on

• Testing was manual - need more automation of integration and acceptance tests
• Testing was on single machine - need to test on multi server farm configuration
• Project break was too long - final delivery will be too late at current pace

If you want to learn how to be better at retrospectives I recommend getting a copy of Agile Retrospectives, Making Good Teams Great by Esther Derby and Diana Larsen.

Summary

Based on the experience so far I can say that adopting agile techniques in a team of one really is something that everyone should do.   I agree just cranking out code some developers could be a fair bit more productive up front than I have been. However if the project takes off and you need to bring in more help or you have a long break the project will eventually fail without these process in place.

And the biggest benefit to doing this is that you learn the benefits of being agile,  you understand why it works and you will be able to add this to your CV and Life experience and go on to become a much better developer.  You will be able to challenge the traditional practices in your organisation based on experience and not just hearsay.

One of my favourite tools Typemock has just been released in a fantastic ASP.Net bundle and have once again offered this up to the blogging community to get for free.

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.
Typemock is launching a new product for ASP.NET developers - the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.
The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.
Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.
The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you’ll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.
Go ahead, click the following link for more information on how to get your free license.

I’ve not had the chance to try out the Ivonna or SilverUnit add-ons to the framework yet, but will be looking at these in the near future and they can help you test more of your SharePoint solutions.

If your the only member of the team is it really worth going through the same agile development process that you would in a team of eight?

Isn’t it quicker to just crack open Visual Studio and start coding?   After all your the customer so you know what you want right?   You not going to have to deal with any of the social complexities that conspire against you. You’re going have the hottest of communication with the dev team,  the dev and test roles will have an interment knowledge and the scrum master won’t really have to do anything as there is not going to be any blockers on this project.

Right?

So I started down this path and before I knew it I had some weird project created with bits of code and SharePoint artefacts but not really seeming to make any progress.   I was easily distracted by other things and didn’t really have a feel for how long it would take and when I could say I was done.

STOP!

What was I doing!  I spend my time trying to help people develop better, to take small steps and sometimes big steps to help produce better software..   why was I not practicing what I preached?

I stopped!

Deep breath, deleted all the rubbish I can previously created and got back to basics.

The Team

I have a team,  the fact that some (in this case all) of the roles were done by the same person was ok; that happens often in agile teams.

Design

Yes, you heard me right here.  Eric Shupps would be proud of me :).   I’m not going to jump into Visual Studio and crank out code starting [TestFixture] I need to do some design work first, even though this application is going to be small I still need to put in the time on the upfront design.  I need to think through the solution at a high level.

Here I used the opportunity to try out the great Balsamiq application,  which I stumped up the $79 license fee for and download the desktop version.

I’ve deliberately blurred the image but you get the idea of what the mock ups look like, and these take only a matter of minutes to produce.  Definately something you should consider if your currently trying to do this in Visio or heaven forbid cranking out HTML mockups.

The few UI based mockups actually helped me to understand how the application would work for the end user, which in turn provided a clear vision for the way the solution would be developed.

User Stories

I didn’t need to do any remote collaboration on the User Stories so I was able to get back to basics and use one of the white boards in my office as the task board.   I wrote the user stories out on post-it notes and added them to the board along with rough estimates for each one.

Here you can see I’m using a very common step of status on my task board

Backlog - This is where I add all stories that came out of the design,  they are all user focused with nothing specific about the implementation.  No stories like ‘Use jQuery to make it nice’  these are user stories.  If I think of something while i’m coding or testing, or even having a beer I can just write it to a post-it and stick it on the backlog.

Sprint - I like Scrum so adopt a Scrum Esq. style to my process.  The sprint will be where I put the stories I plan to do next.  The amount is based on the estimate and also the sprint length.   In this project I’m doing stupily short sprints of 2 days each.

In Progress - When I pick off a story to work on it goes in here,  if you’ve ever looked at the Kanban approaches your looking to keep this ‘In Progress’ to a defined level.  I like to try and move things through to ‘Done’ before picking off new stories.

Verify - When I think it’s been coded properly and dev tested I move the story here.   Verify is where I would validate the code on another environment - i.e. a non-dev box,  one with multiple web front ends.  At this point I also look at introducing some form of automation for both the build/deployment and also the acceptance testing.

Done - This is when it is really really done,  there is nothing left to do, no documentation, no tests or tweaks,  the code is production ready.

Sprint 1 - Day 1

Having selected the user stories for the sprint it was time to setup my dev project and get some of the foundations in place.   If you follow me on twitter you will know that I previously spent time producing a decent SharePoint development Virtual Machine so it was very quick for me to roll out the few things I needed to get going.   A SharePoint team site in which I could spike and test my code,  a VS2008 solution and class library project in which to start cranking out some code.

At the end of Day 1 my board looked like this:

One of the stories I felt was ready for verification and another I was making good progress on.   At this point I had nothing ‘Done’ my burndown in the morning would look a bit sad,  but that’s OK that is often the case at the start of a project or sprint.  I also don’t at this point have a verification setup so this is going to slow me down a bit on Day 2.

Day 1 has been good,  I have the basic project structure defined.   I was able to build a WSP with the SharePoint features I needed to complete the first story and was able to deploy and test this on my dev machine.

People that have read my blog or seen me talk at conferences and user groups know that I am very keen on doing things right; I like to see Unit Tests and better still I want to see people at least trying Test Driven Development.   However at the end of Day 1 I was yet to write a single line of C# code, neither in test form or production code.   So did I really do development on day one?

Well I think I did, only the language used was XML and a little bit of CAML and for these items I do not know of any way, that makes sense, to unit test.  I often think that the XML we define as part of SharePoint projects are more inline with doing configuration,  we are just setting up SharePoint using a specific configuration and the testing for this should naturally falls into the integration space and will be picked up during verification.   That is not to say as a developer I do not validate it,  I need to ensure that it works as expected in my environment before I can move it over to the Verify column and it’ is the job of the tester to make sure this happens.  For this project the tester (me) was adamant that it all worked as they didn’t want to have to waste time on silly errors.

Interesting Test

One thing that I will be having to do with this project is fit it around real work, the sort that helps to keep food on the table sort of work.   This means that the sprints although 2 days in length the elapsed time may be significantly longer.  I know that this will impact on the velocity as I will lose some of the momentum during these breaks, however the benefit I have from adopting a more defined process is that it will be significantly easier for me to pick up the project.   Imaging if I had to go back to the mess of code I had originally created after a weeks break!

I’m really interested to see if my agile development with a team of one really does make a significant impact on the way I develop the code, on the time it takes to complete it and on the quality of the solution created at the end.

Find out what happens on Day 2.

Being an advocate of SharePoint as an application platform I looked long and hard for a decent implementation of a Scrum and have always been found wanting.  I have seen simple examples where any power user could set things up but found the lack of any Burndown charts meant you lost probably the most important part of Scrum - the visibility.

I have found that VersionOne is one of the best products on the market, although it has a lot of options which tends to put off new teams.

For those that use Team Foundation Server your probably going to head towards the Scrum for Team System developed by Conchango.  I’ve not used this in anger so am unable to comment on how well it works however this solution is not really a SharePoint specific solution as it requires you to make the commitment to using Team Foundation Server.

Bil Simser did a good post on scrum tools,  although its nearly 3 years old still has some good links.   Again however the tools are not specifically SharePoint.

Why the SharePoint Obsession?

SharePoint is the collaboration tool of choice, companies have deployed it and it is being used with varying degrees of success.  People have become familiar with the how to add items to a list, how to upload documents into a document library and for the more advanced how to build engaging dashboards.

What is the biggest thing you get from adopting scrum?  ‘Visibility’

What do you need to encourage to make Scrum work?  ‘Collaboration’

SharePoint is the natural platform choice on which to build a Scrum tool.

Introducing Project Aberdovey

As with all good development teams I think it is right that your development project should have a name,  and in keeping with some big companies in the Seattle area 21apps uses place names.   Aberdovey, or as it’s spelt in Welsh Aberdyfi, has probably one of the best beaches in the UK and is located 50 miles west of the office.

Put simply, Project Aberdovey is a Scrum tool for SharePoint.

There are a few aims for the project:

1. Produce a fantastic Scrum tool built on SharePoint
2. Develop the solution using agile techniques including TDD
3. Dogfood the solution as soon as possible - what better way to develop the right solution
4. Open development - I want to give feedback on the challenges but also welcome your input

I will be looking for ways to give people visibility,  I am looking at codeplex as an option but welcome any suggestions.

Great to see that more people are publishing their experiences with unit testing SharePoint.   Here are some of examples I have found that are really worth looking at:

Richard Fennell - Testing SharePoint Workflows using TypeMock Isolator (part 1, part 2 and part 3) - Richard is also going to be talking at a few NextGen meetings on the subject.

SharePoint Dev Wiki is really starting to get some good content not just on unit testing but on the whole development field.

Jeremy Thake (creator of SharePoint Dev Wiki) did a great usergroup meeting web cast on SharePoint Development with Unit Testing

I’ve previously mentioned the Patterns and Practices work and they have started to do some great Channel 9 videos which really do make this so much more accessible.  Brilliant Job!

If you have any links or posts on the subject please share by adding a link in the comments, and if you’ve done something new and exciting help the SharePoint Dev Wiki by posting details.

Looks like my predictions are starting to come true,  people really are doing SharePoint development better

How many times have you added an additional parameter or bit of logic to your code because you thought it could be useful and it’s easier to add whilst your already changing the code?   If you are your introducing Future Creep!  and should stop doing it.

What does Future Creep mean?

If your from from an XP (Extreme Programming) background you would know this better as YAGNI,  You Aren’t Gonna Need It!   I actually prefer the term Future Creep I first saw on the post, beware of future creep by Jamis of 37 signal.   Everyone understands the terms Scope Creep and Feature Creep and its easy to spot these, although often ignored.  Future creep is the adding of additional code by the developer because they can see a possible future requirements.

DONT DO IT!

You may think, hey it’s only gonna take me a couple of minutes to add this additional parameter which I can see being really useful in the future.  You add the code and then move on,  from that point forward that additional code needs to be maintained, every time a developer interacts with your code they need to read it and understand it - often taking more time as that bit of the code is never actually used, which leads to uncertainty about the code.

It happened to me

The reason I wrote this blog post was an example of future creep on a recent project that had a measurable impact on time and effort. The future creep was was simple, the developer was writing a light weight logging library and decided as part of the Logging.Log() method that if the code had a HTTPContext they would also initialise the current web using SPContext.Current.   None of the code within the internal methods made use of this it was just setup and passed into the method.  This in itself does not sound to bad and for most scenarios the code did run with a valid SPContext h0wever this future creep caused a number of issues which forced developers trying work around it

1. The logging library could not be used in code that had elevated privileges as SPContext.Current throws an error if accessed under a different security context
2. The logging library could not be used where a HTTPContext existed but no SPContext, as was the case for some of the Exchange integration code

Having battled with solutions to the second scenario and getting comments about not wanting to make changes to the Logging Library because the dev was not comfortable with the way it had been implemented I challenged the original author of the code as to the requirement for SPContext.

The answer:  Future Creep

A few minutes later the extra code was refactored out, and the library could be used.

Lessons Learnt and how to prevent it?

Don’t do it,  resist the temptation, remember:

The best way to implement code quickly is to implement less of it.

The best way to have fewer bugs is to implement less code.

And adopting techniques like Test Driven Development force you down a path that doesn’t allow it.

A short and to the point post by Dror Helper at Typemock looks at industry findings on the cost benefits of doing TDD.

The Cost of Test Driven Development

..the research proved two points:

1. Using TDD reduce the amount of bugs in the code significantly
2. Using TDD takes more time then not using TDD

This is in line with what was expected, the question is does the extra time doing TDD reduce the quality or is it the unit testing.  Could doing Test Last unit testing give similar results?

There is also the unquantifiable part to the numbers in the quality of the developers in each team.  This has a significant impact on the code quality.  Using processes like TDD help to raise the bar for all of the developers and the cost benefit will improve over time.  It would be a very interesting exercise to see how these numbers work out in a typical SharePoint project.

On the same lines Phil Haack (great name) has a post on Bug Driven Development where he quotes Robert Glass and Steve McConnell on the costs not doing some form of automated testing which reinforces the value in getting the right processes in place.