Former Lehman Brothers IT COO gives tips on using the Scrum development technique

| 2 Comments
| More

James Martin was European IT COO at Lehman Brothers when the investment banking giant collapsed in 2008.

He has since spent time at a couple of major banks and returned to the remnants of Lehman Brothers to tie up loose ends. The investment bank may have collapsed just over but there are still investments out there that need to be dealt with.

James has now set up a company to provide online performance benchmarking for small and medium UK firms. The company, Firmrater, was launched in August 2011.

As a small group of people they had to outsource development. He wrote a very interesting article describing his experience using the Scrum development method. It was a big change for someone used to huge corporate IT projects.

Just for a taster here are James' top Scrum tips.

1. Produce fully detailed functional specifications before starting development
2. Create minimal administrative documentation: focus on the product
3. Use online collaboration tools with a minimum of meetings and phone calls
4. Carry out rigorous testing based on the specifications
5. Use written change requests which include time and cost impact
6. Provide a "low distraction, high freedom" working culture for the whole team

Chicken in a Scrum:  A client's view of Scrum Rapid Development

By James Martin


"Having spent the best part of 25 years in IT, when we decided to set up our own online business and develop a bespoke application from scratch, we had enough experience to know that nothing runs quite as smoothly as it should when it comes to technology development projects.

I spent most of my career working for large corporations and struggle to remember very many projects that genuinely completed on the original time or budget. The volume of change requests usually knocked plans off track and functionality was often dropped for the now infamous "Phase 2". Not really a criticism, more a case of the traditional project development methodologies and working practices used by many large firms.

If your own money is tied up in a development project you clearly need to do everything you can to make sure the time and cost stays under control and you get the product you need to launch your business.

Having spoken to several web application development firms about technologies and methods, I was intrigued by the Scrum approach and wanted to find out more about it. I have worked with various rapid or agile methods in the past but not seen them succeed as well as they should, so this is how I became a "Scrum Chicken" for the first time.

Nobody has a crystal ball so producing a traditional project schedule in advance is fraught with risk. Why not abandon the detailed schedule altogether? You can't slip interim milestones if you don't have any and you can't add padding into them either.

The Scrum approach, which breaks a project into small pieces and tackles them as quickly as possible made a lot of sense to me, so I was sold. Of all the methods we could have chosen, we put placed out bets on the one which seemed, at face value anyway, to be relatively unstructured and with minimal documentation around it.

To give ourselves the best chance of producing the application in the shortest possible time and at the lowest cost, experience dictated that we produce detailed specifications describing all functions along with a mock-up of each web page. The key problem I have seen in IT development projects is a general lack of specifications before coding starts.

Detailed specifications are critical if you want to get a realistic fixed development price before work begins. Change requests cost time and money for all concerned so we spent several months refining the specifications with our Scrum Master before seeking a price to develop the application. Taking this approach, we ironed out a lot of the potential hazards before work started. The developers were able to quote a fixed price along with an overall timescale which was recorded in the development contract.

Overall we spent about 5 months (48% of total project duration) producing the specifications, which was time very well spent. To accelerate the start of development, placeholders were left for text content as this could be dropped into the application later. This enabled us to work on the website content in parallel with development of the application and cut the launch timescale by several weeks.

The Scrum development team then took over while we focused on the non-IT tasks that you have to put in place when starting a new business. I received a handful of clarification requests and one progress email each week. No meetings, no phone calls. That alone saved us all a great deal of time which would otherwise have been spent travelling and talking rather than coding and testing. The focus throughout was always on the product with very few distractions or interruptions. Clarifications and decisions were generally handled by email within a few hours so the Chicken did not impact the Scrum. It was a very dynamic "real-time" experience. Development took 3½ months (33% of total project duration).

The application was then made available for acceptance testing and any pre-live enhancements. We had arranged a dedicated server in a commercial data centre so several instances of the system could be installed for testing and production. This enabled the Scrum team to implement the system and enhancements for remote testing and signoff before promotion to production. It's a neat solution and again supported collaborative online working during the development process.

We spent 2 months (19% of total project duration) testing the system and making small enhancements. No major functionality was added or omitted during the development process and the work really was completed when expected. The team had been running about 2 weeks early until I decided to upgrade to a more powerful server. This Chicken-inflicted delay put the Scrum team back onto the original planned completion date. Not bad for a 5½ month development programme with no traditional schedule, formal progress reports or meetings.

The fixed price held firm but we decided to allocate additional funding for pre-launch enhancements which amounted to 6% of the original contract sum.

Now the system is running and our online working practices are well established, we can get minor functional changes live in as little as 30 minutes from the point we upload a change request. That includes development, testing in the QA environment, signoff and promotion to production. Not bad when you consider three separate firms are involved, each working remotely.

So the Scrum experience was a very good one, even for a fresh Chicken. The application really was developed for a fixed price, it landed on time and it met the specification. I know this is not simply due to the approach we selected as our Scrum team members are highly skilled, very dedicated and put a great deal of care into their work. The key point here is that a method can either help or hinder a development project and we wanted to use a method which was most likely to help us succeed. We made the right call, Scrum is the future.

Our top Scrum tips:

- Produce fully detailed functional specifications before starting development
- Create minimal administrative documentation: focus on the product
- Use online collaboration tools with a minimum of meetings and phone calls
- Carry out rigorous testing based on the specifications
- Use written change requests which include time and cost impact
- Provide a "low distraction, high freedom" working culture for the whole team"

The Scrum Master role and Project Management were performed by WeSolutions Ltd (www.wesolutions.co.uk) and Scrum development carried out by Website Design Ltd (www.websitedesign.co.uk).

The stats

james martin table.jpg

2 Comments

afraid this does not sound like scrum..especially the 1st tip:Produce fully detailed functional specifications before starting development

Who cares if it sounds like Scrum or not?

It sounds like this guy is pleased with the results, which is more than can be said for every so-called "agile" project I've worked on these last 5 years. This approach sounds sensible, especially the bit about nailing down the *functional* requirements in advance: I've seen too many projects crippled by vague and contradictory requirements that allow customers and developers alike to effectively dodge the hard thinking until far too late in the development life cycle.

So it is good to hear a positive real-world example of a rapid application development success - reminds me of the pre-Java/pre-Agile days when RAD tools and methods provided far greater productivity than we usually see these days!

Leave a comment

Have you entered our awards yet?

About this Entry

This page contains a single entry by Karl Flinders published on August 26, 2011 10:31 AM.

Is the evidence of shared services success flawed? was the previous entry in this blog.

Why is the UK border Authority still using pay rates from 2008 to limit immigration? is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

 

-- Advertisement --