What waterfall can learn from Agile – Focus on skills & team

This post – in a series that I plan to write, covers what waterfall can learn from Agile. A caveat emptor – these aren’t about a hybrid Waterfall-Agile approach, these are about Waterfall as is widely used but highlighting agile best practices that can be adopted without changing the model itself (at least at the beginning of team’s journey to become Agile).

Waterfall methodology is still very popular & agile pre-requisites such as deeper time commitment from business teams, short iterations and more importantly a cultural change may not be immediately possible in some organisations – but that does not mean that some of the best practices can’t be picked up.

This first post is is about organising teams the agile way. Waterfall model is built upon the relay approach – leading issues getting passed over to the next team. This ultimately results in defect detection during integration, user acceptance tests or worse in Production.

Agile teams in comparison are organic, people are encouraged to take on more than their desired area of expertise but more importantly expected to ‘own’ a piece end to end – i.e. ensuring that the work is not only ‘done’ but it is production quality.

So, how do we ensure that this maps to Waterfall model without changing the model itself –

1. Generalising Specialist: By not branding individuals by their specialities, everyone is a developer (or analyst if you prefer) and have a speciality but they are encouraged to operate across phases of software development – to be part of requirement gathering & analysis, design, coding, testing (integration, user acceptance). The easiest way to do this is to have a core team of analysts (typically a majority of these will have coding as their speciality – but other skills are appropriately represented) – who continue to remain on the project for the entire duration doing/helping others with more than their specialised area of work. If you must scale your teams during development and testing phases, ensure that part of the team (which will be beyond the core team) is engaged early & always uses a ‘test first – develop later’ (TDD) approach (more on this in the next post).

There may still be specialised skills needed in some areas (varies per project but these could be database design/development, specialised tools, specialised testing requirements etc), these skills can be engaged and supported by core team.

2. Foster ‘Feature Teams’: Challenge for larger teams is to avoid the ‘throw it over the wall approach’ when scale makes division of work a necessity – this can be achieved having horizontal ownership (i.e. functional requirement based sub-teams rather than speciality or technical component based) – although this approach may be difficult to achieve in certain circumstances but not¬†impossible. This has few advantages –

  • Defects are identified early
  • Identification of integration issues early
  • Avoid ‘Us’ vs ‘Them’ situation

The horizontal slicing can be achieved with contextualising requirements and capturing them as user interactions/system features – using system usage maps (similar to Story Maps – more on this in the upcoming post).

I believe these best practices are easy to achieve. I will talk about some other areas in the coming post.

Share |