This was 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:
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.
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.
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.
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 of done” needs to be set (Acceptance criteria) to judge if a particular story is done or not.
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 respond with your feedback on this write-up.
Originally published at: http://www.scrumalliance.org/articles/440-stumbling-blocks-