The problem is that every other engineering industry seems to have been around since the masons. The methodologies that were put into place in order to manage the construction of a building or a vehicle were well thought out. These methodologies have adapted and changed making them more versatile while still achieving confidence in the project’s success. Now don’t get me wrong, I have no problem with this at all I think they have their place and I think they are very beneficial. The problem is that adapting these methodologies for software engineeringhas been an uphill struggle. Yes we now have methods that have been used successfully in Software Engineering for a long time now, Prince2 and Six Sigma being the governmental methods of choice for obvious reasons.

The problem is that all of these methodologies were adopted and then modified from other engineering disciplines. Boehm B, was the first to create a formal methodology (CoCoMo) for Software engineering with an aim to manage estimating accuracy. He also adapted methodologies based on the waterfall for more agile developments (Spiral) but these all still have deep rooted problems in the fact that they are based around large software engineering projects developed usually in one language and with one main client. Where am I going with this? Well Digital software engineering is different! The languages and potential functionality are ever increasing, the expected deployment platforms are always evolving and increasing and the display formats and architectures are rarely the same from one day to the next. It is all of these factors that put any rigid management and development at risk. Agile methodologies then seem the logical next step.

The Manifesto for Agile Software Development

states the following:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan:
That is, while there is value in the items on the right, we value the items on the left more.

Donald J. Reifer, has written a methodology based on Boehm’s CoCoMo model called WebMo (web Model) which aims to record and calibrate a web development project’s metrics after development and based on certain ‘predictors of size,’ produce estimates of increased accuracy.

Now all of the preceding things I have talked about go a long way to helping us plan, manage and record digital software engineering projects but we are still at risk, why? Due to the number of languages, skill sets and the platform independencies above, not to mention the standard risks any project inherits, par for the course as we all know.

I do not see Agile so much as a methodology, but more a mind set.

Yes there still needs to be accurate planning, recording and management, but there also needs to be more emphasis on communication (internally and externally), trust in others abilities and an individual responsibility for the work carried out in order to produce quality working software.

Wheel-of-Tea: Case study
I have recently managed a small yet incredibly agile project. An internal project at Redweb. We have developed an application for the Apple iPhone. The brief was simple, develop an application that records a number of users (people sitting round a desk at work) select what drink options each of them prefer (tea, coffee with sugar etc) then spin the wheel and display the results. We used a form of Agile based on the SCRUM methodology. It was not only an experiment in our ability to develop for the iPhone OS but also in the method we used among lots of other unforeseen obstacles along the way:

The backlog was written. It was simple, prioritised and ready for change, like the example given below:

Working Agile

We were working with a dedicated team and had a very limited time period. Yes you know what this means, time does not change but the deliverables will – this is where agile earns its bread! Going with the Pareto principle we wanted to deliver 80% of the functioniality straight up! And we did. Holding weekly ’sprint’ demonstrations of the application to the core stakeholders we were able to re-negotiate the priorities at each demonstration. The one golden rule we had for development is that each week there would be a demonstration and this means every week the build will have to be stable, stable enough at least to demonstrate.

The plans were accurate yet simple and held nothing more than the essentials. The communication was fast and at a much lower level than other projects: This communication was the mortar of the entire project. The development cycles were very much prototype upon prototype keeping the good stuff and trashing the bad.

For all our hard work the project was a success! In terms of delivery 100 percent of the team were happy with the deliverable. The stakeholder is happy with the cost and the small amount of extra time was agreed and well worth it for the extra mile.

Key points for success:

I have read about many successes and failures of using agile methodologies and I think there are a few very good reasons how we managed to use this so successfully. The following points are what you must/must not do if you want every chance of success in your own agile development:

• The key stakeholder needs to attend every ’sprint’ (every single one)
• The PM needs to manage (not change the project) but manage the project: Monitor:Record:Report & remove hurdles.
• You need a dedicated and adaptable lead (scrum master, project lead etc) If you do not then the communication will break down.
• Trust: every member of the team must trust in each others’ ability to produce the goods and raise issues.
• Work with methodology and believe in the inverse Pareto principle (20:80).
• Prioritise (really prioritise), remember what’s important! If it’s not top priority then ditch it! You can’t take everything with you to the end (there will be other versions, let it go from this one)
• Do one thing well, really well. Then modify later with all the bells and whistles
• Know when to stop or when to quit! If you’re not going to succeed STOP. If you’ve completed your objectives STOP and deliver the damn thing!

Why use Agile?

There are many reasons to use agile but also many reasons not to. Agile unfortunately for some needs a dedicated team, sometime that is not possible. Sometimes the client will not be available or have the commitment to follow such a method. I guess what I’m getting at is that it depends on the project. There are hundreds of failing projects out there using all types of methodologies that have previously claimed “it can’t fail” and hundreds of successful ones using lots of different methods, get out there, find them!

This article will hopefully give you some confidence least of all in the ability to adopt a similar methodology for your next suitable project. If not then at least you can see the potential of using agile based on the example given here:

Designed and Developed by RedWeb
Methodoligy used: Hybrid Agile
Development Time: Confidential
Website: http://www.wheeloftea.com
Twitter: http://twitter.com/wheeloftea

How does it work?

1. Add the names, photos and drink choices of your friends

2. Shake your phone to spin the wheel and decide the loser of this round

3. They must then head to the kitchen to get everyone’s drinks

4. Start again next time you’re thirsty!

Share us with friends:
Facebook | Delicious

iPhone application for cuppa tea | iPhone tea application | Iphone application tea rounds