Sunday, December 13, 2009

When to Scrum

I often hear companies claiming that they are much better in software engineering since they follow Scrum. How valid is that claim? Rather than challenging further, let me share some of the experience on when can an organization be effective with Scrum.

First of all, it is important to understand what problems Scrum is actually trying to solve. Scrum is mainly about making things more visible and measurable. It makes requirements more visible, progress more measurable, impedances more visible, etc... It encourages decisions to be made by the right people keeping everyone involved and interested. 

Wait... isn't this we always hear and know about Scrum? Yes... but is that the complete picture of Scrum? Unfortunately NOT! It is equally important to understand what Scrum is not! Scrum is a management framework but does not define engineering practices. What happens if your Scrum team lacks engineering practices? It will be like trying to win 'Formula 1' race, by employing Michael Schumacher to drive a bullock cart. No matter how well Michael Schumacher can drive, bullock cart is not going to perform. In short, it is not possible to drive, if engine is not up to the expectations. Scrum is NOT about the engine, but about driving it. The engine is the engineering practices followed such as how the coding is done, reviews are made, documentation is done, testing is done, resources are planned, infrastructure is managed, and this list can go on and on.... 

It is important to know that none of the above is addressed by Scrum. Many get confused by trying to understand Scrum by comparing to XP (Extreme Programming) which has defined some good engineering practices such as unit testing, continuous integration, etc. Scrum is a different concept altogether. 

For a company with proper engineering practices Scrum can make a lot of sense. But when there is no proper engineering process exist, it is quite easy to get your incapabilities hindered under the word 'agile'. Unless you have addressed software engineering processes in your company, adapting Scrum will probably have negative results. 

Do not use Scrum as a means to fix the engineering process. It is impossible. Instead you may admire the engineering value added by standards such as CMMi, ISO, etc.

[tag: 99xp ]

5 comments:

Anonymous said...

Hi, as you may already found I am recent here.
I will be glad to get any help at the beginning.
Thanks and good luck everyone! ;)

Anonymous said...

I Agree with you in this. There limitation Scrum it self.

sanjaya said...

yea, hasith you are absolutely correct regarding the practice of scrum as an engineering process. I have the experience of some companies which think that scrum can solve each and every problem of engineering, but which is not.

Good post!!!

sanjaya

Lakmal said...

I'm not into Scrum that much sir, but for me it feels like, Scrum is making customer requirements so close to the developers than any other process do (As I know).With Scrum, requirements (Whatever finalized and assigned) are always in hand for developers and it's forcing developers to be in touch with customer requirements.
But when it’s come to Waterfall model, how many developers are checking Use cases even before the start of the development or in the mean time. How most of the developers are get to know about customer requirements, is that one of their senior person is explaining the requirement like a story, and then developer won’t mind to open and see the Use Cases. Whatever missed to include in the story will be fired after a particular release is been given to QA.
In Addition to that, Scrum is keeping teams alive all the time, means always it’s measuring the progress of the works by the burn down charts. This is something especially I see in SCRUM and it makes management happy all the time, because they know how things are progressing.
Quick Releases, Immediate Responds to Customer requirements changes (This is one of the thing to accept in pain in the middle of the project Implantation), Always have deliverable version of project in hand and etc, always makes SCRUM more handy.
I believe that we have to keep in live most of the good practices we followed in ISO or CMMI on maintaining project documents and some project logs, but in the mean time we have to move the Implementation process into a process like scrum.

Hasith Yaggahavita said...

Lakmal, no disagreement. But my point is different. Scrum is a management practice, and it can be applied to many different type of projects even outside IT (e.g. manufacturing).

But for any project to succeed, we need engineering practices as well. Scrum does not specify those. Sometimes what I see is that some organizations without proper engineering practices can hide behind the Scrum glory and suck the blood out of their amployees and customers.