Russell and Associates – Forum

I just finished a short run using the scrum method of Agile project management:  stories, retros, sprints and all.   It was a very educational experience since I had never been a part of a project that used ‘formal’ Agile development.

- First, Agile sounds cool. There is an inherent power and affinity to like the word ‘agile’, to say ‘I am agile’, ‘we have an agile development team’, ‘our business model is agile’.  The power in a word cannot be understated – business wants to be agile; developers like to be seen as agile.

A few operational definitions. Agile software development is short term goal oriented – component directed. The idea is to get a bunch of software developers working on a project by picking components (‘stories‘) from a master list of ‘backlog’ items and completing those individual components within a short period of time – called a ‘sprint‘. The typical goal of the sprint is a complete sub-component, one that can be demonstrated during the ‘retrospective‘ as a stand-alone element.  Some shops even demand that these components are ‘go-live’ ready.

The first deficit with Agile project management appears when there are components that are comprised of multiple smaller sub-components that are not separated into different stories. For example, a form page.  A form page is composed of the following: the HTML wrapper, CSS formatting, the form proper, business rules for managing the form input/processing/output, form content validation and security, other user interface components, data definition/acquisition layers (db abstraction/ORM), and presentation components. There may be Ajax components to the form, as well as validation, and visual/auditory Fx via JavaScript.

The failings of Agile comes to light where ‘expectations’ are concerned. Business expects a completed components at the end of a sprint. Anyone who has designed and developed a full blown web application (as opposed to a ‘site’, ‘page’, or ‘component/widget’) understands the iterative nature of such a ‘process’. The final result is most often a group of components that can be reused to simplify program maintenance and improve program performance through re-factoring to optimize the total application developed over the duration of the project.

I think the best way to compare Waterfall with Agile is that Agile is concerned with ‘events‘ and waterfall is concerned with the flow of app development that results in a completed product – the  ’outcome‘. Conceptually, both are correct – an app is a bunch of ‘events’ that interact to produce some result, and, an app is a business process that must be satisfied through a series of components that elicit a specific outcome, or ‘result’.

Sprints are like a course that is made up of a bunch of quizzes with no final exam.  It is the accumulation of grades over the course.  A waterfall project is a course with NO quizzes - only a final exam, and, maybe a mid-term.

Waterfall methodology emphasizes pre-defining all components so, in theory, the development portion is very short lived.  More time is invested in defining the components and laying out the look and feel of a site than is actually set aside to code them.  Planning is everything.

What often time occurs using the waterfall method is, in Agile parlance, a bunch of backlogged items become evident very near the end of the project.  For developers, it becomes a ‘marathon’ to complete the project on time – often times with few, if any, functional components to demo for stakeholders (ie business owners).

Other deficits in the waterfall methodology are scope creep and the effects of incorrect estimation of build time (coding & system administration).  Since the planning portion is so long, items are often added that should extend the duration of coding, but seldom do.  Most projects have a go-live date that is seldom altered, even though the scope of the project increases.  As a component is added or altered, reality would dictate altering the estimated due date – but that seldom happens.

<psych aside>Human nature, for many people, dictates that we want to satisfy the needs of others – particularly superiors or people who can advance our careers.  The waterfall method plays on that human tendency to the advantage of the stakeholder at the expense of the development team.  It is difficult for many of us to say an unequivocal ‘NO’ to the VP of marketing or sales when they have a ‘really good idea’ for a feature that will add a developer-month to the project.  The problem arises when the project is past due, and that feature that the VP loved so much three months earlier in the planning stage is all but forgotten – it no longer carries the same emotional power it did earlier.  All that matters now is that the developers are late delivering the project.</psych aside>

Pure scrum can be effective when modules are very compartmentalized – there is little co-dependence on other modules.   It becomes nonsensical to use Agile when the overall system has many dependencies UNLESS there is an agreement that modules will be enhanced and integrated at a later date when the ancillary modules that, say, perform form validation, are complete.

When you get right down to it, Agile is a good way to reduce the upfront cost of a project and put most of the design and planning on the developers – which is, in my opinion, a good thing.  A less is more approach that can be effective for the largest project, so long as the stories reflect reality.

vr