Stumbling Blocks

27 August 2012

Gurpreet Singh
US Healthcare Company

Ours was a typical Waterfall team that believed to the core in the SDLC (systems development life cycle). Our requesters were always adamant about sending countless changes to us at all stages of the project flow. This led to a lot of rework, a decrease in customer satisfaction, an increase in the number of bugs, and other problems.

Hence our leadership thought of bringing in a new methodology, which had proven fruitful when it had been applied a few years earlier in another location: Agile. As the name suggests, the whole framework is flexible. Our group started off as the pilot project, and we finally implemented Agile in the entire service line.

However, our team faced numerous stumbling blocks while we were attempting to adopt Agile. I'll focus below on the most prominent ones:

 

1. Inertia

We're performing so well, we thought. Why would we change? Why are we giving liberty to the client to change the scope at any time? How will the projects be completed?

To be honest, it is very difficult to tame the inertia of a team. We ran several rounds of meetings to educate the team about the Agile (specifically, the Scrum) framework.

2. Lack of discipline

Discipline is the core of Scrum. We all needed to be on time for all meetings, and we soon found that this was a problem. So we set up a "Softy meter," which meant that whoever was late for a meeting (without advance notice) would have to bring Softy ice creams for the entire team. This was advantageous: We enjoyed a lot of Softies in the initial phase, and gradually the Softies were abolished as there were no more latecomers.

We also faced a problem in not timeboxing the meetings. Our stand-ups lasted for as long as 30 minutes, as parallel discussions erupted and diverted the agenda. Eventually the ScrumMaster learned to intervene so that the team followed Scrum stand-up practices.

3. Learning responsibilities

An Agile team is self-organizing team, motivated enough to work for a common goal for the company. However, during the initial adoption period, we realized people were not aware enough about their roles. A product owner should focus on achieving the client's business piece of the project. A ScrumMaster should act as a facilitator to help in removing the impediments. The team should be self-organizing and have the liberty to size the stories, pull them individually, and assign them in the product backlog of the sprint.

4. Learning the prerequisites

The product owner and the ScrumMaster should not be the same person, nor should either be the direct reporting manager of teammates. A product owner needs to be a single person, not a committee. Both of PO and ScrumMaster should be dedicated 100 percent to the project. In case someone must work on multiple projects, he or she needs to draw the line to protect each individual project and team so that they're always taken care of.

5. Expectation setting

The expectations of the client need to be set wisely. That is, if the client is finicky about the budget, then we should communicate clearly to him or her that we will give a daily, approximate cost estimate. However, if there is a nonnegotiable cost, we will clarify that we'll forward the product in its current state to the client once that cost is reached.

6. Learning empiricism

Scrum is empirical in nature. Never make it too calculated or mathematical, or you'll destroy its core purpose. For example, always draw a rough 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 and missing the real work.

Sizing the story is another example. Never size a story for the estimated time involved; sizing is a measure of the complexity of the task. The size shouldn't depend on whether a senior developer takes it or a junior developer takes it. Sizing should also be relative, meaning that stories should be sized relative to each other.

Finally, the ìDefinition of Doneî needs to be set. Acceptance criteria needs to be outlined so we can judge if a particular story is done or not.

7. Possible need for customizations

Agile hates people working on multiple projects simultaneously. If a PO doesn't have the needed bandwidth, then a proxy PO must be set up to fill that vacancy.

A few companies don't have ScrumMasters and so the PO handles the dual roles of being the "clientís person" and the "teamís person" (ScrumMaster). This leads to internal conflicts, as those roles need distinct people. Sometimes a person acting as PO for one project is ScrumMaster for another project, which can work well as long as schedules are respected.

Our team today

Now we are a purely Agile team. Truthfully, the transformation from Waterfall to Agile practices was extremely difficult. It took us several pilots; extra hours; weekend trainings; regular and ongoing coaching; and learning to deal with ego clashes, inertia conflicts, and more. But today we are a happy Agile team. Scrum, sprints, retros, review meetings, discipline — they're all now part of our DNA.

Article Rating

Current rating: 0 (0 ratings)

Comments

Mike Cohn, CST,CSP,CSM,CSPO, 9/10/2012 9:59:44 AM
Hi Gurpreet--

This is a nice post and a great list of stumbling blocks. I definitely like that you included discipline and call it the "core of Scrum." Too many people (mostly, who have tried agile) view it as loose and uncontrolled. The good teams, like yours, figure out that is definitely not the case. Being agile requires a lot of discipline--to be prompt, to always strive for high quality, to continuously improve, and so on.

Thanks for your post.
Gurpreet Singh, CSP,CSM, 9/10/2012 1:53:26 PM
Thanks so much Mike! I am really happy to receive your kind words on my first article. I will write more :)

Thanks again!
Douglas Roberts, CSP,CSM, 1/16/2013 2:52:56 PM
Hello Gurpreet,

I have one comment on your article, and it refers to the first sentence in item #7 'Possible need for customizations'. The teams that I have worked with routinely work on story cards drawn from a variety of projects, because we cannot afford to dedicate an entire sprint to just one project. In general, the various stakeholders for our teams each manage their own projects and work with our team's Product Owner to get 'space' on a future sprint for their project's priorities. Although it may be the ideal for each sprint to focus on one specific project, for us, it is not a reality. And I can't say that it's a weakness: our teams rather enjoy the variety of working on stories from a variety of projects.

You must Login or Signup to comment.