Doing Agile in a Team of One – Day 2 and the End of Sprint 1

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.


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.

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

    It's interesting to see other folk's experiences with agile development.

    We've been doing our first 'proper' scrum project recently, and actually, I think that your series of posts might miss this little issue.

    In our case, the customer knew that the didn't really know what it was they wanted, and felt an agile approach would work best. Unfortunately, they've got internal deadlines, and not everyone has bought in to the agile approach. We find ourselves with in a position of doing agile but “we have to have all the features, and it must be by that date” (and that date is pretty close). Consequently, we've actually ended up with something that kind of approximates waterfall, rather than agile.

    So, I guess my point is that the customer really has to “get” agile, and have someone with authority to set the product backlog leading the project at there end. But I guess this isn't an issue if you're the customer too!

    And I reckon that Scrum meeting would still be useful in a waterfall project, for smallish teams.

  • AndrewWoody

    Andy, I'm not sure the series missed the issue as such, only that in a team of one and with the same person being the customer you have the buy in, the commitment and the communication so this is not an issue that a team of one needs to deal with.

    On your point, the customer absolutly has to “GET” agile. This really is the biggest challenge to adopting agile is getting the customer to understand the benefits of the iterative approach, and the best way to do this is to start delivering and continue delivering.

    A lot of projects work this way, if you talk to Eric Shrupps he works more this way with farily well defined requirements up front. What you can still do is set priorities (I know the customer wants it all) and then deliver stuff often but based on this priority. The first project may even follow a very traditional style with the customer not engaged and not changing anything on the backlog, but showing them the solution as it developes will provide confidence and start to get them involved.

    What agile won't do is allow you to achieve more than is possible, if the customer says we need all this in this timescale, and it is impossible what aspect do you drop? Quality! What you actually do is borrow from future projects and build up technical debt, this debt needs to be repaid at some point. However most customers just see that hey, if we say it loud enough it will happen, heck the devs are just on Twitter all day anyway. Eventually it will come back to bite, the problem is customers have had years and years of history and experience that is hard to break down.

    And yes a Scrum meeting, or daily stand up or whatever you want to call it is a brilliant way to help get shared commitment and understanding within a team even if the project is not following an agile approach.

  • Pingback: This Week C9: Speech Recognition, Army of 1, TweetCraft and more | Blogs

  • Pingback: This Week C9: Speech Recognition, Army of 1, TweetCraft and more - Feed -

  • AndrewBurns

    Sorry, I've been meaning to reply for a while…

    Yeah, I think I'd be more comfortable with fairly well defined requirements up front. They might not be that detailed, but you have to know what you're aiming at. And I think you've and interesting point that I'd maybe not really realised – that actually, a traditional approach and agile approach maybe aren't all that exclusive.

    And your third paragraph made me laugh. That's pretty much exactly what we're seeing – the idea that “Agile” somehow makes use 200% more productive, and technical debt building up, which is hard to get buy-in to get paid off. “Refactoring the data access layer – what does that give me?” and “Proper packaging – well it deployed last time, why would we want to do that?” – both not sexy subjects, but essential to a well run system.

    Still, it's all interesting.

  • Pingback: Doing Agile in a Team of One | 21apps