My two cents on Scrum
Scrum is an agile methodology which helps companies iterate through a
product/project development to successful completion. Back in the days
we all know that we were limited to the water fall model which was later
extended to be known as the V-Model. Gantt charts and the like were
included with these methodologies.
The practices defined within these traditional methods were concise and
precise. We start off with gathering of requirements from the client,
document it which usually goes as the Software Requirement Document
(Known as SRS), which is later signed off by the client after user
acceptance testing is done. Afterwards we have the design phase where
all our class diagrams come into play as well as use case diagrams, ER
diagrams and the like. Then it’s time to implement this well designed
product with technologies that fit the choice. Testing and product
release follows the implementation phase.
Though there were no intrinsic problems with this methodology, the
problem lied in the fact that we humans are involved in every phase. In a
perfect world (such as what skynet once planned) this methodology would
work seamlessly and we would have picture perfect product releases. But
alas, with us humans nothing is guaranteed. We all know how hard it is
for us to make a decision on something at certain times. In terms of a
company, when they approach a software company to build a piece of
software for them, they might not know what they exactly want early on.
As time goes on as they see the product they might and most usually do
want something radically different to what they wanted earlier.
The problem posed by the traditional methodologies as everyone knows is
that it’s very hard to go back from once phase to a previous phase as
the cost and time involved in the process is of great monetary value to
the company. We can’t coerce the customer to agree on our basis as
client’s request are always dynamic and we as a company should have the
processes in place to adapt to such changes.
This is where Scrum shines as I see. I’m quite new to the scrum process.
In scrum what is usually done is that we start off with a base Product
backlog which has feature tasks that the client requested. There are a
few entities that are involved within the process of Scrum such as;
The Product Owner(PO) – The product owner is the one who gathers
requirements from the client and creates and maintains the product
backlog. Also he/she is responsible in assigning a priority to each task
defined within the product backlog.
The Scrum Master(SM) – The scrum master does not involve with anything
specific to the project, but acts as a supervisor helping the team and
the product owner to adhere to scrum practices whenever he/she sees that
they are deviating from proper processes.
The Team – is that development team involved in the development as well as the testing of the project features.
Ok now that we have met the people involved in the Scrum, let’s see why
it is so awesome. One of the eye catching points of Scrum is the fact
that the team decides on the time lines rather than your project manager
deciding it for you. I have been any many meetings where the developers
stand there like deaf or dumb people and watch as their Project manger
do the estimation giving unrealistic deadlines. In scrum the practice is
that the team decides along with the PO which tasks they can take on.
Usually in Scrum features are taken to fit into one spring which is more
less a month of time. This is the most efficient time as proposed by
Scrum. So the team decides what they can achieve within the month and
take on the tasks that fit the timeline.
The key feature to note is that they do not make the estimation based on
the high level task defined within the Product backlog. They break it
down to meaningful development tasks and estimate based on that. If a
feature has work for more than one sprint, some features are pushed to
the next release. This is a very efficient way of estimating as I see
because you do not leave anything out in your estimate and are able to
give credible estimates to your Product owner.
Also Scrum is dynamic in which if a customer wants a new feature added
on whilst a spring is going on, though they can’t achieve it within this
sprint they can always push it to the next sprint and the wait time of
the customer is minimized to just a month.
Also usually whilst a Sprint is coming to an end, the team gets together
with the PO to estimate on the upcoming spring to. In scrum momentum is
key, which allows teams and companies achieve its development goals in a
timely manner without pressurizing the developers with unrealistic
deadlines. So the team is aware of upcoming work load as well whilst
within the current spring. This is a great feature of scrum the scrum
practice. Planning ahead, but not too far ahead.
And also if for any reason they are unable to deliver a feature within
the current Sprint they can always push it to the next Sprint and finish
off.
As a couple or so Sprints go on, the team gets the feeling of the kind
of work it can achieve within a particular sprint which allows them to
make timely, accurate estimates on future tasks.
All in all, I believe these agile practices is the way ahead for all
companies big or small as the benefits it brings along supersedes the
switching costs involved with moving away from your current practices.
What are your thoughts on Scrum? Pls do leave a comment with your own thoughts on the same.
From http://dinukaroshan.blogspot.com/2011/07/my-two-cents-on-scrum.html
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Chris Kelly replied on Sun, 2011/07/10 - 1:06pm
Dinuka Arseculeratne replied on Mon, 2011/07/11 - 12:55am
in response to:
Chris Kelly
Hi Chris,
Thx for the error correction. Missed that :) ... Hmm you do have a point there. As a company wide policy we plan sprints for a period of 1 month. But i agree with you on shorter sprints will be beneficial to keep the pace going forward. thx for leaving by a comment. Appreciate it.
Regards,
Dinuka
Igor Laera replied on Mon, 2011/07/11 - 1:46am
That said, the problem I always have is, that SCRUM "is sold" as something that it isn't: another way around the fact that if the product owner doesn't know what he wants, doesn't know where he is headed and has no time to care about checklists or acceptance tests SCRUM won't help either. Every time I have discussions with people who are sure they do SCRUM (or any other method); but still missing deadlines, still don't have the acceptance of the software with their customers etc it always boils down to the fact that SCRUM can't force the PO to do his part, his role when he didn't *want* to. It quite seldom that the "failure" lies in the skills or the management of the dev team.
I'm always pleased if I hear that people have great successes with any method, especially SCRUM, since it gives lots of freedom back to the designers and coders to solve the problems their way, not the way some "higher up" thinks it should be done in his 600 pages "grand opus" requirements document, that was old the minute he printed it out six month ago.
Josh Marotti replied on Tue, 2011/07/12 - 9:50am
in response to:
Dinuka Arseculeratne
"As a company wide policy we plan sprints for a period of 1 month."
Isn't that rigidity the opposite of what you want in scrum? Scrum is agile... it is meant to be dynamic. Applying rigid rules to it is counterproductive.
Bob Jones replied on Tue, 2011/07/12 - 1:11pm
in response to:
Josh Marotti