I’ve just been involved in a project that is a classic example of how you can deliver software within an incredibly tight timeframe without compromising the client’s vision or the quality of the deliverable – it had nothing to do with following a named agile methodology (Scrum, XP, Lean…) but everything to do with following some of the principles of the agile movement. The project was http://www.office2010themovie.com, the client was Microsoft and the team imagewas from Intergen.

We often refer to projects that come through Chris Auld as “Chris Specials” – to everyone at Intergen it’s simultaneously a warning to hide and an invitation to get involved in something new and innovative. But when Chris came to us with a list of 8 “requirements”, a couple of statements of Microsoft’s vision, and 10 working days to complete it we know we had a challenge on our hands. So how did we successfully get to the finish line?

  • Trust – this is the single most important factor in being able to deliver software under these sorts of time frames. Microsoft trust Intergen – really trust. There was no room to miss the deadline – the site was going to be launched on July 13 at the Worldwide Partner Conference in New Orleans and that was a date that wasn’t going to slip. They also trusted we could interpret their needs without having to be spoon fed precise specifications. They trusted we would design the solution to cope with the inevitable last minute feature requests. They trusted we would resource the right people for the job. 
  • Daily Meetings – we sometimes even call these meetings “stand ups” but to be honest we rarely achieved the well behaved, time constrained, 3 question focus of the Scrum doctrine. However, the end result was same – we discovered progress, identified road blocks and set the priorities for the next 24 hours. These meetings were critical to make sure we were all on the same page. At almost every meeting we made small corrections to the path we were travelling to reach the end goal. 
  • The Team – we obviously had a great team. But I think the key to our success was the range of strong personality types on the project, each adding something different and creating a healthy tension to keep everyone on their toes. We had Dreamers (ChrisA and DaveK) always reaching for the stars, Technologists (Daniel, ChrisK, Aaron and David) with the smarts to create amazing software, The Troubleshooter (The King) for when the going gets tough, The Hand Brakes (me and Gabrielle the PM) always tempering the enthusiasm with the realities of delivery. 
  • Releasing Often and Early – from the first day we started to plan how we were going to release the software in to production and UAT. We scheduled releases often and early and, regardless of whether we had achieved all the functionality we were aiming for, always released an update for the client to provide feedback. In the first week we had no production environment to deploy to and had to deploy to our own servers – as soon as we could deploy to the production environment we did to ensure we eliminated as many platform specific issues. During the 10 or so day's of development we had about 5 official releases for the client to review and about 20 internal releases for our own testing.
  • Prioritisation – we constantly evaluated the priorities of features and other requirements and communicated our ideas to the client as quickly as possible. A good example of this was the decision to defer categorising videos for the first release – this saved us time and since the site would initially only have 3 videos it would not impact users. I think we’ve all worked on projects where a client will insist on the inclusion of a feature simply because “it’s in the list of requirements”. Additionally, new features were added when they were deemed important. The ability to move things in and out of scope was crucial and only possible given the trust and sense of partnership we enjoyed with Microsoft.
  • Core Functionality Comes First – this is especially important for applications built in Silverlight. Silverlight has so many cool UI features that it’s very tempting to get stuck into this goodness at the expense of actually implementing all the mandatory functionality first. Our first few releases where entirely unbranded but by the 3rd release we had implemented all the essentially functionality – by this time Dave was ready with the UI designs and the guys could start to integrate these into the final product. At the end of the day, if we couldn’t play videos or record comments it wouldn’t matter how amazing the site looked - we would have failed.
  • Documentation – emails was our primary means of non-verbal communication with the client and each other. Apart from an initial Statement of Work we didn’t really produce any documents.

 So that’s what we did and it seemed to work.