Skip to content

Scrum, Agile and the Enterprise – Part 2

I’ve been thinking more about some of the challenges related to adoption of agile SDLC methods in larger enterprises. A key concept that keeps coming up is the importance of project management and how it relates to the agile SDLC (using Scrum as example here).

Some people seem to believe that agile SDLC miraculously occurs without good quality inputs. But it is just like anything else in computing – Garbage-in, Garbage-out.

Thus it is important to ensure that the agile SDLC is being executed within a sound overall project management and governance framework. And an important input into the Scrum SDLC process is a reasonable set of business requirements (not a formal Software Requirements Specification per IEEE 830, but rather a plain English outline of the business needs in non-technical terms). This is a critical input for the development of a feature list and user stories for Scrum.

There appears to be a belief in some quarters that an agile SDLC approach is un-disciplined and a bit ‘cowboy-ish’, but that belief is not correct. Executed properly agile methods are often more disciplined than a traditional waterfall approach.

The most important control provided in Scrum is the feature and/or test driven development in short sprints of 10-20 days, together with automated unit testing and continuous build and integration. The relatively simple sprint-based approach outlined in the Scrum process coupled with the rigour of continuous integration and automated unit testing can reduce development risk substantially. The risk is reduced by developing based on finer grained requirements in the way of user stories and high levels of business owner involvement in clarification and prioritisation.

There are two major risks with this approach:

(1) Lack of appropriate involvement by the business owner or their fully empowered and knowledgeable delegate; and

(2) Lack of automated testing and continuous integration (skills, tools or both).

Without these key elements in place, together with appropriate overall project management, then it might be better to stick with a waterfall SDLC.

More to come on this topic later …