Our First Agile Project : Mindset change, Learning and Yes, we did complete it subsequently

The year was 2011 and the month -November.  Agile was still the talking point in my delivery team of 200+ resources and my esteemed client from Europe – being advised by the industry leading consultants, wanted to get hands dirty in a proof of concept development. Everybody, the stakeholders from client side and us, everyone with a level of understanding different than others of this new way of working, was in the learning curve on a day to day basis. At the behest of a senior executive, a challenge was taken up to get a ringside view of how agile would work in a distributed environment – teams separated through geographical distance and cultural differences.

With a planned budget of 4 sprints, we, a team drawn from client and vendor, got thrown into executing our first agile project.

On this journey, we got Mrs. Swati Garg, an experienced agile practitioner by then, as the coach cum scrum master to help us sail the boat. The day Swati called us – the multi-disciplinary team comprising of functional and technical fields, for a pre-project workshop, many eyebrows were raised. We, the so called experts of project delivery by all the standards practiced till then, had frowned upon the idea of the workshop at the beginning but by the end, came out as a more learned team on the concepts of this agile way of working (wow), the parlance, and the associated ceremonies to reap maximum benefit. As it involved quite a bit of unlearning and re-learning, not everything that was discussed in the workshop could be digested with our already molded mindset in the usual client-vendor mode of working. With set role and defined expectations between the client and vendor party, the concept of one team drawn from members of client and vendor did not go down well as we were apprehensive of getting exposed too early too soon and our faults could be found on a daily basis of execution.

Teams were spread across onsite and Bangalore. We had one business analyst and an additional scrum master at onsite to be close to the business –the product owner and also take part in scrum of scrum meetings with two additional teams- supposedly more experienced in agile from the overall project perspective. Though it might be pointed out that it defeats the purpose having two scrum masters facilitating and helping the team, it was a conscious decision taken and agreed by all the stakeholders with a view to smoothen out the initial hiccups and teething challenges arriving out of teams not co-locating.

The team of eight, named “Phoenix” coined by the team members, started breaking down the epics to stories to tasks along with the corresponding efforts under the careful vigilance and guidance of scrum masters. Story point estimation done in the classical way of “pack of cards” was an eye-opener for all the participants. Limiting the stand-up meetings to the 15 minutes and to limit to three questions arranged at a mutually convenient time at 2 PM IST to suit onsite time zone -not dragging the same to be a technical clarification meeting, was a huge challenge in the beginning few days.

There were initial trepidations from few quarters of client side management- coming from the traditionally biased mentality during usual trust building timeframe, to review and monitor the work being executed at offshore and wanted to have physical camera fitted at the workplace.  With help of Microsoft lync based technology, enabling AV meeting where everyone could see each other, these worries got replaced by confidence in no time.

The impediments on workspace creation for final delivery had dependency on a third agency – not made party to the whole project from the beginning and hence stories could not be delivered on time satisfying the agreed definition of done (DoD) till third sprint. From a metric perspective, this resulted to the story point delivered against story point committed as zero. Knowing the overall situation and shouldering the responsibility equally, there was no finger pointing for the failure, rather the invaluable learnings from the exercise gave credence to the overall objective – tuning the way of working in the context and devising the overall transformation charter.

At the end of each sprint demo and retrospective sessions, team gained in more knowledge with the nuances of being agile and the beauty of this simple process. When the project was over, the wisdom gained far outweighed the failures in the below mentioned areas.

  • Team is accountable and supreme.
  • Team self-manages itself.
  • Transparency is the key between product owner and team to be successful.
  • Scrum master is not a project manager rather a facilitator to remove impediments.
  • Team needs to budget time in Sprint n+1 to take care of the technical debts arising out of deliveries till sprint n.
  • Test automation is must for regression and integration points.
  • The ceremonies, if observed in the truest sense bring real value to the team.
  • There is nothing like semi Agile- either you commit to it or don’t.

We did not hesitate to conclude that the crucial 3-4 weeks spent in our first agile project – in distributed mode, was a new beginning for all of us opening a new chapter on how a project gets delivered with involvement from all the stakeholders from the word go on day one. We agreed to commit ourselves in this journey going forward as the benefits – less cost of correction, bringing business value faster; were all looming large and too obvious to ignore.

Standard