This is my first blog published on Agile at Scrum Alliance: http://www.scrumalliance.org/articles/440-stumbling-blocks- http://gpzee.wordpress.com/2012/08/25/stumble-blocks-while-implementing-agile-scrum/

1. Hi All,
This is my first article on Agile. I would like to express my views on
"Stumble blocks" for Agile Adoption.
Ours was a typical Waterfall team, which believed in SDLC to the core.
Our requesters were always adamant in sending countless changes to
us at all stages of the project flow. It led to a lot of rework, decrease
in customer satisfaction, increase in the number of bugs and so on…
Hence, our leadership thought of bringing a new methodology which
was very fruitful when it was applied in another location, a few years
back: Agile… as the name suggest, the whole framework is very
flexible (read: Agile).
We faced numerous stumble blocks while we were attempting to
"adopt" Agile: I would list the prominent ones below:
1. Inertia
We are performing so well: Why would we change? Why are we giving
the liberty to the client that he/she can change the scope at any time?
How would the projects be completed?
Honestly, it is very difficult to tame the inertia of the team. We ran
several round of meetings to educate the team about the Agile (read:
Scrum) framework. We started off as a
Pilot and we finally implemented in the whole service line.
2. Discipline
Discipline is the core of Scrum. We need to reach in time for all
meetings. We setup a "Softy" meter; this means whosoever is late for
some meeting (unless it is an exception); he/she needs to bring Softy
for the entire team. This way we enjoyed a lot of Softies in the initial
phase and gradually the Softies got abolished as there were no more
defaulters. Moreover, we also faced an issue of not time boxing the
meetings. Our stand-ups got extended for as large as 30 minutes as
there were parallel discussions erupted and diverting the whole agenda
of the meetings. Probably, the Scrum Master should have intervened
so that the team is following Scrum in totality.
3. Responsibilities

2. An Agile team is self-organizing team motivated enough to work for a
common goal for the company. However, during the initial adoption
time, people are not aware of their roles. A Product Owner should be
focussed on achieving Client's business piece of the project. A Scrum
Master should act as a facilitator to help in removing the impediments.
The team should be self-organizing and they have the liberty to size
the stories and pull the stories individually (No PUSH) and assign the
stories in the Product Backlog, which can be accommodated in the
Sprint.
4. Pre-requisites:
The Product Owner and the Scrum Master should not be the same
person and should not be the direct reporting manager of either of the
team mate. A Product Owner needs to be a single person and not a
committee. Both of them should be 100 percent dedicated to the
project. In case they are working on multiple projects, they need to
draw the line in such a way that the team and the project is always
taken care of.
5. Expectation Setting
The expectations of the client needs to be set "wisely": e.g. if the
client is finicky about budget, then it should be communicated clearly
to them that we will give an approximate cost estimate daily, however,
if you have any hard stop of "any figure" of cost, we will forward the
product in the current state to him/her.
6. Empirical Nature
Scrum is empirical in nature. Never make it too “calculative” or
mathematical: it will destroy it’s core purpose. As for example, always
use a rough hand to draw Burn down chart to keep it simple and
meaningful: if we make it too accurate using rules and scales, we end
up wasting a lot of time on the same and doing the real work: the burn
down chart will never be maintained if this is followed. Another
example is “Sizing”. Never size a story for the estimated time involved.
Sizing is a measure of the complexity of the task. It should be
universal in nature: the size should not change if a senior developer
takes it or a junior developer takes it. Sizing should be relative: e.g.
stories should be sized relatively to each other. Several techniques can
be followed (T Shirt size, Average, Fibonacci, etc). Also, the “Definition

3. of done” needs to be set (Acceptance criteria) to judge if a particular
story is done or not.
7. Customizations
Agile hates people working on multiple projects simultaneously. If a PO
does not have bandwidth, then a Proxy PO is setup to fulfill his
vacancy. This Proxy PO does everything in the guidance of PO: hence,
it might lead to the “distrust” of the Proxy PO in team’s guidance (lack
of power). Also, a few companies do not have Scrum Masters so the
PO does the dual role of Client’s Person and the Team’s Person (Scrum
Master). This leads to internal conflicts as the PO is a single person.
Sometimes, a person acting for a PO for a project is made to act as a
Scrum Master for another project (giving respect to his schedule). This
is a win-win situation for this customization.
Now, we are purely an Agile team. Honestly, the transformation from a
Waterfall to Agile methodology was very difficult: several pilots, extra
hours, weekend trainings, regular coaching, ego-clashes, inertia-
conflicts, etc. We are a happy Agile team: Scrum, Sprints, Retros,
Review meetings, discipline, etc are in our DNA, now.
Please feel free to write back with your feedback on this.
Br,
Gurpreet