Agile vs. waterfall

First of all, what am I talking about?

The waterfall methodology is a very traditional way of managing software development. this is what I (and countless others) was taught at school and university and is a logical system which fits most projects across all manner of industries and business.

It fits the name as the diagram the model produces shows the project flowing from one discrete stage to the next, like a waterfall.

The main stages usually are:

Requirements specification
Design
Implementation
Testing
Installation
Maintenance / feedback

It suits larger companies as it's easy to report on, you can track what stage a project is at, and the idea is that it should give certainty around when the project will be delivered. The requirements and design stage are very important and produce many detailed and accurate documents about the project. Once the requirements have been signed off, they should not be changed. This means that someone new coming in should be able to understand all the details of the project simply from the documentation. It's good for multinationals who may have large development teams over several countries, everyone needs to be able to refer back to the same, correct set of documents.

Agile, on the other hand, as it's name suggests, tries to be a lighter and quicker method for managing projects which enables a team to change direction if necessary.

It places much less emphasis on documentation and more on face to face communications and producing working software quickly. The project will be broken down into smaller tasks which can be developed in 'iterations' (small 2 to 4 weeks worth of development). These tasks will produce prototypes or pieces of working code which can then be shown to the customer or internal business owners to get more feedback. You don't need to wait till the end of the project for feedback.

Within an iteration, the requirements for the team should not change, but requirements for the project as a whole can change and will feed into subsequent iterations.

The process involves daily short 10-15 minute meetings (scrums) for all of the small team to discuss what they are doing and any blocks they are facing. Business owners or customers can come along to those meetings but they shouldn't get involved in the discussion, they can come to the iteration planning to demo/review meetings to see what has been produced and what is planned for the next iteration. A simple addition I've found in my current role is to have the whiteboard which shows each task in the iteration and at what stage the task is at (to do, doing, done, blocked...), in a very visible place like the kitchen or the reception area. No-one can say they don't know what's going on!

I've found that the agile methodology works best for web development in smaller companies. The nature of most web projects mean that requirements are difficult to pin down 6 months or a year before (as the waterfall method would need). In the time taken between signing off the requirements and the project being completed the online market may have changed, the internal structure of a company may have changed, a competitor may have entered... it is a fast moving space. So developing in an agile way means that a team can adapt as necessary. It's still very important to have a vision and high level roadmap of where you want the product to get to, but the details of that don't need to be set in stone.

However, I did say "in smaller companies". I have worked on web projects in large companies and this is a different kettle of fish. In the larger organisation where your developers may be in another country, it could be difficult to have the level of face to face communication needed. Also many corporates have their own project management standards, it can be difficult for a central admin group to understand why your team doesn't need to (or can't) spend time filling it's hundreds of forms which the rest of the project will do. They need to sign off your work and to report up the progress of your team and they can't do that without you jumping through the same hoops as everyone else.

But for in a small, co-located team, it works well and is really motivating to see functionality being delivered often, and to know that what you ultimately produce will suit the needs of the customer and the market.

What is a product manager?

Weve been talking about this a bit at work recently so thought I'd record my thoughts here too...

I think it is always going to be difficult to give a definitive answer to what is a product manager in all cases, because all companies and teams have different structures and influences.

In previous roles I’ve been called a product manager, a business analyst and a project manager when really I’ve been doing similar day to day things.

I think some of the traditional tasks of a product manager are:

1. Understand customer needs through research, stats analysis, user groups, interviews…
2. Competitor and market analysis
3. Work with all stakeholders and business owners to create longer term vision and strategy for the product
4. Prioritise requirements, get agreement from the business and provide enough detail for development
5. Act as product expert to answer questions on functionality
6. Communicate out changes to the product and champion the product both internally and externally
   
7. Log feedback and integrate into requirements prioritising process

Brief work history and interests

I've been working mostly in London for about 5 years, in various technology type jobs for Reuters, fish4.co.uk and now The Motley Fool (fool.co.uk). I've focused on website product management and like to keep up to date with what's going on with the internet.

Further back - I took a degree in electronic engineering at Birmingham Uni. I enjoyed the course but decided I wanted to get more into the business side than be a pure engineer.

I have a lot of experience with finance related sites from Reuters and fool.co.uk, and also a big interest in eCommerce and portals from fish4. My latest projects with fool.co.uk include improvements to the mortgages area to increase the number of high quality leads coming through to mortgage advisors, and a review of current and potential ad slots on the site. How to monetize the site further without comprising it's design and usability is always a hard one.

I'm interested in how websites can become not only more usable but also more fun and relevant to your users. I think that's important if you want your site to stand out and for your users to return. I think this can be done through cool design, novel widgets, user generated content techniques such as tagging and social networks, and by allowing personalisation to suit the individual's needs.

That of course means I need detailed understanding of your users, which can be done through creating user profiles and personas to use during requirements gathering, and user testing and workshops to verify those requirements. I've been through varied ways of doing this, from structured 1 on 1 questioning to popping out into Soho with a wireframe idea to see if people get it! This is one of my favourite parts of the job :-)

In terms of processes, I've worked in quite varied positions for very different companies. At Reuters, we were mostly working in quite rigid waterfall project management processes, which I think is needed for the big global software projects there, but when working on websites agile processes can work better though as I've seen at fish4 and fool.co.uk.

I prefer this way of working myself, when done correctly it can be quicker and more flexible. You get small bits of functionality delivered often and as soon as they're ready, and can change direction if needed, rather than waiting for some gargantuan all encompassing master project which maybe have been spec'd 2 years ago and contains functionality which is no longer relevant. The scrum techniques I've been using also mean it's easy for everyone to know what's going on though the quick daily meetings and using visible tracking methods such as whiteboards, shared spreadsheets and team blogs.

It's not for everyone though. Small, co-located teams work best where everyone buys into the methods.

I could go on with these topics but sure I will go into more details with future posts. :-)