Scrum and eScrum/TFS Feedback

We adopted Scrum and eScrum/TFS (Team Foundation Server 2008) back in June this year for a pilot project. As we are a few days before Xmas, when all is beginning to quieten down, now seems a suitable point to dot down a few observations. Here we go.

The Scrum Method

First of all, I'm converted! Scrum is one of the few processes/methods (I'm not a big process person myself generally) that excites me, in that it focuses the team on delivering good working software and encourages a good relationship between the IT Team and the business. Since adopting it on a small project, I can happily [subjectively] report back that it works, and it works well. We used 3 or 4 week sprints, monthly sprint review/planning meetings, and daily scrums (sometimes missing a day if one was not felt necessary, but we still touched base to confirm this). We also had scheduled weekly "product owner update meetings" to ensure we had a regular slot in a busy "product owner's life", where we always scanned down the sprint backlog to see how things were progressing.

Here's are some observations.

1) The business loved it because:

• Transparency and business ownership. They enjoyed being a big part of the project, seeing the parts that went well as well as those that did not!
• Focus on delivery of key features. Having the control of what goes in and what does not, via strict prioritisation
• Explicitly clear what is being delivered in each iteration and by when
• Productivity. Business often surprised by the "amount" delivered
• Regular releases. This often resulted in less impact on the business at go live time ("little and often" approach)
• Gets everyone focused, especially on testing!

2) The development team liked it because:

• Clear whom is doing what
• Regular daily Scrums picked up any niggling issues very early
• Test earlier and focus on producing tested, “packaged up” work. Although we are not yet adopting TDD (test driven development), as we are doing shorter development cycles, this necessitates earlier testing to ensure all is tested before the end of a sprint. What we did find though was that during the final few days of each sprint, we found it beneficial to focus purely on wrapping up what we had done and "test/fix only" in order to deliver a fully tested product even if it meant removing a sprint item or two in order to achieve this.
• System deliverables improved. Smaller increments and closer links with business definitely has resulted in better work being produced ('better' being a system that matches what the business wants).

All OK so far. Any problems?

3) A few Issues:

• Multiple product owners (we had three distinct areas thus 3 owners). Needed a gatekeeper PO to help manage this
• Trying to fit too much into a sprint. Call it eager to please, naivety or lack of experience, but the first couple of sprints resulted in the development team working their socks off to finish the sprints on time. Looking back, this was purely due to underestimating effort and not allowing enough time for feedback/testing.
• New requirements coming in during a sprint. This is something we are now getting better at but early on we were drawn by the temptation of squeezing in "important" new requirements into an existing sprint (slapped hands I know!). We live and learn.
• Some requirements not clear during sprint. We tried to start development on requirements that were changing or not really known. Ouch.
• Keep control of the number of meetings. With 3 product owners we found we had quite a few meetings each week, some of which the development team did not always need to attend.
• Keep eScrum work items up to date. Whichever tool you use, it is only as good as the information in it. Hence encourage your team to keep it up to date.

eScrum and TFS

As mentioned in an earlier TFS/eScrum post, not only did we switch to Scrum for this pilot project, but we also adopted some new tools namely:

• TFS 2008 for source control and work item tracking
• eScrum Process Template.

Here's my brief thoughts:

1) TFS Generally

I like it. Once you get over the clunky, heavyweight feeling of the various MS products working together to give you what you want (SQL Server, Sharepoint, Reporting Services, TFS Web Services) and sorted out all the security goings on (you've essentially 3 products to set up security for), then you are away. The customisation is very flexible (especially once you have installed various power tools) and adopting a VM as a backup strategy has served us well. Well worth the move from VSS!

2) eScrum 1.0 Process Template

I looked at a few templates for managing the Scrum project (including Conchango's SFTS and MSFAgile) but in the end, eScrum had the best web interface for us. It is not without its short comings though.

Here's some of my thoughts on the eScrum web interface:

• The interface is fixed and "hard coded" as it runs as a separate web site (it does not use the generic Team System Web Access). The advantage of this is that is gives a focused interface, geared towards the eScrum template, but its drawback is that if you customise the template, add new fields etc, although they appear in TSWA and in Team Explorer on the client, they will not be seen in the eScrum web site. Shame.
• You cannot add attachments through the web interface. Not a deal breaker for me, but as users often submit bugs in the form of "screen shots" this would make a useful addition.
• No "show history of changes" option on a product backlog or sprint backlog item.
• The "all items disappearing in sprint backlog" bug needs fixing. Opening a new browser session or switching projects brings them back for now.
• The AJAX driven web interface is pretty lightweight/quick, especially compared to TSWA. Updating work items is fast and slick.
• PBI and Sprint pages have too big a header and section at the top. I would like to be able to fit more viewable item lines per page. e.g. with the product backlog page, 2 thirds of the screen is taken up with a header, menu tabs, and first three sections which are rarely expanded once product set up. The bottom third is the bit we use all the time!

Overall,  a nice interface but we are getting to a point where a version 2.0 is long overdue. I can't see this happening for a while though.... maybe MS should make it open source ;-)

Merry Xmas
Clarkey