Why SCRUM’s agile development framework is more effective than the traditional “waterfall” approach

It's good to see this sort of exposure in the CIO Business Technology Leadership Magazine.

Why SCRUM’s agile development framework is more effective than the traditional “waterfall” approach

It's good to see this sort of exposure in the CIO Business Technology Leadership Magazine.

Although I don't agree with the part that says:

"In my experience, the types of projects that don’t work include:

• projects smaller than about two months of development work"

Thanks Michael,

An interesting article, although I would have liked them to have elaborate on what an "improvised version" of Scrum actually means. What agile princples did they feel needed to be comprimised etc..

Cheers,
Martin.

Just catching up some reading here, haven't made it to a get-together yet but hoping to get there in March.

Just a couple of comments on the concept of "improvised Scrum". A few years back I went over to the States for a Scrum gathering and did the course with Ken whilst there. If there was one thing I garnered from it all it was reinforcing the fact that Scrum is a set of principals you adapt to your local culture.

- It doesn't dictate that you use Story based requirements, they're just popular
- It doesn't dictate that you run a particular length Sprint
- It doesn't dictate that the only possible output from a Sprint is software

The vast majority of the most interesting discussions related to applying Scrum in a fixed price, multi-national, major project world - and how you took the principals of Scrum and applied them in settings where you had little if any control over commercial arrangements. Ken had a wonderful purist view, supportable based on the fact that his usual engagement with a company started with the CEO and drove down through the organisation from there. However, for most of us, Scrum is introduced in a pilot situation - and we have a company that needs to maintain CMMI or ISO accreditation and requires a process where results drive cultural change rather than cultural change driving results.

I've run Scrum teams on a number of projects with a variety of teams in the years since, ranging from a product on a monthly release cycle to an extensive requirements and scoping analysis project inside a Mil-Standard organisation where 80% of the output was simply documentation.

My conclusion is that in the vast majority of circumstances if you try to introduce "pure Scrum" on day 1 you will fail. The cultural change required in both your Scrum teams and the rest of the organisation is so vast that getting there in one fell swoop is just not possible.

If you start with something as simple as a daily standup you're on the path and will see results. Introduce practices from there that are based upon fitting the Scrum principals into the boundaries of your organisation and its ability to embrace cultural change whilst maintaining commercial viability and with time comes success.

Why SCRUM’s agile development framework is more effective than the traditional “waterfall” approach

It's good to see this sort of exposure in the CIO Business Technology Leadership Magazine.

Although I don't agree with the part that says:

"In my experience, the types of projects that don’t work include:

• projects smaller than about two months of development work"

Same here. We have had successful agile projects as short as 3 weeks - finishing one today in fact. We work on 1 week iterations when its that short. Of course it works better having a longer project as you get to incorporate feedback into the loop more often. However if you have a project that can only run for 3 weeks, well you run it for 3 week and get more ad-hoc feedback from the Product Owner during each iteration.