Doing Agile in a Team of One

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.


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.


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.


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.

Blurred out Balsamiq Design

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.

This entry was posted in Agile, Development and tagged , , , . Bookmark the permalink.
  • jamesafisk


    I'm suitable inspired. I too have found myself start a project with much gusto, only to then leave in the graveyard of doomed projects. You're right there is no excuse of laying best practices to one side only because you are a one man band.

    All I need now is a whiteboard.

  • spacescape

    Good effort – I've been thinking of how to apply our agile process to a couple of project ideas of my own. I guess it should be pretty simple to translate the process for a team of one but it's good to see an example of how to go about it

    look forward to seeing how it goes. And yeah – wish I'd kept hold of my old whiteboard too now, how about this as an alternative?

  • Matt Taylor

    I'm sure there are hundreds if not thousands of devs out there like me who work projects on their own much of the time. I have been sat on the agile fence for literally years because of my assumption that it doesn't scale down to smaller teams and definitely not to a one-man-band. I'm really impressed that you picked up on this area of the market and really appreciate the time you've taken to document your experience so far. I hope you get time to document the outcome otherwise I guess we could discuss it further over a pint or two ;)

  • Eric Shupps

    Great post, mate. What's good about this thought process is that it applies equally well to teams of 1 or 100. The larger teams just have more oversight but otherwise it's the same. I hear all the time that Agile/Scrum is only for big teams. Hogwash. Everyone can do it.

    The really amazing part is that you got through day one without writing any test fixtures. Did you have withdrawls at the end of the day? ;-)

  • AndrewWoody

    No withdrawls at all, was actually a very enjoyable day. But I know day 2 of the sprint will bring in some unit testing so I have something to look forward to :)

  • Jeff Miles

    Thank you very much for this article. I have been discussing implementing Agile with a friend of mine who runs a state government IT shop, but didn't know how it would scale for a team of one since I run my own business. After reading your article, I am going to give it a try on one of my upcoming projects and if it works, start using it for all projects.

    I have created this spreadsheet to use as a replacement for my scrum board (…) feel free to download it and give it a try. The idea is that the far right column is used to color code projects I am working on and I use cut and paste to move things from column to column. The colors will be used instead of different color sticky notes to differentiate projects.

    Let me know what you think.

  • Pingback: Agile development in a team of one « Stacked Notion

  • Pingback: Doing Agile in a Team of One – Day 2 and the End of Sprint 1 | 21apps