Agile stumble blocks on agile adoption


Published on

This is my first blog published on Agile at Scrum Alliance:

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile stumble blocks on agile adoption

  1. 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 tous at all stages of the project flow. It led to a lot of rework, decreasein customer satisfaction, increase in the number of bugs and so on…Hence, our leadership thought of bringing a new methodology whichwas very fruitful when it was applied in another location, a few yearsback: Agile… as the name suggest, the whole framework is veryflexible (read: Agile).We faced numerous stumble blocks while we were attempting to"adopt" Agile: I would list the prominent ones below:1. InertiaWe are performing so well: Why would we change? Why are we givingthe 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 ranseveral round of meetings to educate the team about the Agile (read:Scrum) framework. We started off as aPilot and we finally implemented in the whole service line.2. DisciplineDiscipline is the core of Scrum. We need to reach in time for allmeetings. We setup a "Softy" meter; this means whosoever is late forsome meeting (unless it is an exception); he/she needs to bring Softyfor the entire team. This way we enjoyed a lot of Softies in the initialphase and gradually the Softies got abolished as there were no moredefaulters. Moreover, we also faced an issue of not time boxing themeetings. Our stand-ups got extended for as large as 30 minutes asthere were parallel discussions erupted and diverting the whole agendaof the meetings. Probably, the Scrum Master should have intervenedso that the team is following Scrum in totality.3. Responsibilities
  2. 2. An Agile team is self-organizing team motivated enough to work for acommon goal for the company. However, during the initial adoptiontime, people are not aware of their roles. A Product Owner should befocussed on achieving Clients 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 they have the liberty to sizethe stories and pull the stories individually (No PUSH) and assign thestories in the Product Backlog, which can be accommodated in theSprint.4. Pre-requisites:The Product Owner and the Scrum Master should not be the sameperson and should not be the direct reporting manager of either of theteam mate. A Product Owner needs to be a single person and not acommittee. Both of them should be 100 percent dedicated to theproject. In case they are working on multiple projects, they need todraw the line in such a way that the team and the project is alwaystaken care of.5. Expectation SettingThe expectations of the client needs to be set "wisely": e.g. if theclient is finicky about budget, then it should be communicated clearlyto 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 theproduct in the current state to him/her.6. Empirical NatureScrum is empirical in nature. Never make it too “calculative” ormathematical: it will destroy it’s core purpose. As for example, alwaysuse a rough hand to draw Burn down chart to keep it simple andmeaningful: if we make it too accurate using rules and scales, we endup wasting a lot of time on the same and doing the real work: the burndown chart will never be maintained if this is followed. Anotherexample is “Sizing”. Never size a story for the estimated time involved.Sizing is a measure of the complexity of the task. It should beuniversal in nature: the size should not change if a senior developertakes it or a junior developer takes it. Sizing should be relative: e.g.stories should be sized relatively to each other. Several techniques canbe followed (T Shirt size, Average, Fibonacci, etc). Also, the “Definition
  3. 3. of done” needs to be set (Acceptance criteria) to judge if a particularstory is done or not.7. CustomizationsAgile hates people working on multiple projects simultaneously. If a POdoes not have bandwidth, then a Proxy PO is setup to fulfill hisvacancy. 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 (lackof power). Also, a few companies do not have Scrum Masters so thePO does the dual role of Client’s Person and the Team’s Person (ScrumMaster). 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 aScrum Master for another project (giving respect to his schedule). Thisis a win-win situation for this customization.Now, we are purely an Agile team. Honestly, the transformation from aWaterfall to Agile methodology was very difficult: several pilots, extrahours, 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