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.

Advertisements
Standard

5 focus aspects for an organizational agile transformation

An organization – be it IT or non-IT, aspiring to move from traditional waterfall or V-Model way of project functioning to agile way of working (WoW) has to go through a organization wide transformation process with significant change management at all  levels  across  length and breadth. In my opinion, following are the five most important drivers that need to be followed without any deviation for a successful transformational change.

  • Ø Senior management, from all functions of the organization, have to be absolutely convinced about the benefit of this transformation and accordingly back the execution team through initial ups and downs. “Aspiration” has to be changed to “conviction” from where there is no looking back. The transformation planning has to be sponsored top-down for the success to be achieved.
  • Ø An effective communication change management plan to be devised and put in place to percolate the vision across all employee levels. This messaging has to reach to the heart and mind of all the employees and they need to be on the brought on the same boat. Resistance to change is a natural human behavior and hence this communication plan has to doubly effective to take away any kind of fear and apprehension from the mind of employees.
  • Ø Experienced agile transformation coaches or agilists need to be roped in to help steer the organization through the journey. The coaches will be supported by an internal lead execution team having a buy-in in the thought process. The lead execution time would have already embraced the new practices mentally by this time. The workshops conducted by these experts, involving employees and stakeholders at all levels, will complement the change management plan already communicated. Workshops, being a key execution stepping stone in the overall journey, will define the new WoW in the context of the business practices of the organization. The overall WoW will involve relevant external and internal factors and most importantly the customer base and expectations .
  • Ø In addition to workshops, appropriate training programs with the agile theory and principles -suited to different employee groups at different levels, will have to be rolled out by the lead execution team.
  • Ø Retrospective review by executive Sponsoring team along with the lead execution team, moderated by the Coach in a timely manner with 2 week sprint mode is a must. While tailoring of the execution plan is expected by the review committee, unflinching support by the senior management – going back to point 1, is a must, beyond any bit of doubt.

–Jayanta Tewari

Standard

IT Service Management following ITIL processes is Inherently Agile

There have been many attempts by thought leaders to link ITIL and Agile methodologies, be it SCRUM, XP or other ones.

Some say Agile and ITIL complement each other, some others opine that ITIL can be modeled in Agile. Some other organizations delving newly into agile for development projects are spawning a different thread how agile can be incorporated to reap accelerated benefits in Managed services activity (the terminology used for IT service management) without understanding the nuances and nitty-gritty of either of these. For the sake of this discussion, I will limit to SCRUM Agile methodologies that being the most popular one and benefits achieved through SCRUM related ceremonies are easily perceptible.

From my experience of delivering both Managed Services Operations and Agile based development projects, I ,convincingly, say that ITIL service management processes already follow all the basic tenets on which Agile methodologies are espoused and advocated on. To my conviction, IT Service Management-Managed Services Engagements in the ITIL model is inherently agile and that should be left to run as it is without complicating it any further.

If one digs deep, ITIL basically classifies the followings:  

  • Incident management
  • Service Requests
  • Problem Solving
  • KEDB – Known Error Data Base
  • Configuration repository.

Incidents or Tickets are reported by business users which can be compared with stories in Agile. The level of incident reporting is at a very granular level of developer comprehensibility and hence qualifies the readiness criteria of a story and task. The same user plays the role of Product owner for giving additional inputs and certifying the solution at the end.

Incidents are prioritized which exactly the same what is done during backlog is grooming.  Service Requests and Problems also follow the path of prioritization with a different cycle – Sprint cycles with different durations.

Logical segregation of Teams is based as per functional area and none of the teams are bigger than 8-10 people team. I have implemented daily stand-up within the team in a managed services operation resulting into benefit of collaboration and faster impediment resolution and the result was explicably beneficial.

When a particular incident or Service request is fixed after UAT (User Acceptance testing – can be logically same as demo feedback) and moved to production system, business value is delivered to business users or to product owner and that happens in a comparative short cycle.

While RCA (Root Cause analysis) discussion can be nearly related to sprint retrospection, there can be a periodic visit and look-in amongst team members to chew upon what are going well and what needs to be discarded at a regular interval of 2-3 weeks. This generally happen in some form or other already in any kind of engagement.

It is very clear from the above discussion that traditional IT support service engine runs like any other well-oiled machinery with improvement of efficiency and productivity on a regular basis – the concept of velocity and improvement on the same is also mapped in this case.

Known error Database and the knowledge repository is part and parcel of any execution engine and hence do not warrant any special mention in this discourse.

If one thinks a little into philosophy of both these approaches, the seed they stem from is providing business value at a shorter period and hence similar in nature of execution – this is no rocket science.

With this I conclude this discussion.

Will you share your thoughts?

–Jayanta Tewari

Standard

Agile Way of execution is fast catching up in Indian IT software sector.

While the debate is on if agile development model has gone mainstream or not (http://www.cio.com/article/737980/Has_Agile_Software_Development_Gone_Mainstream_), there is a strong wind of transformational change of Agile being more and more adopted across the length and breadth of Indian IT sector, be it internal to the organization or for a client.  There is renewed focus with clear and distinct initiatives being taken in the organization to make the workforce agile to be “agile ready” amidst apprehensions of maturity of this model. Starting in the 90s, the process base of this industry has been predominantly waterfall or V model with a little bit of productivity improvement practices borrowed from Japanese manufacturing industry thrown here and there and now, Agile, with its atypical terminologies, roles, left and right segregation in the manifesto is a strong shake up call for this industry in its adulthood. The senior leaders of this industry -more of scope freeze or schedule clarity mindset- can’t ignore this anymore and small organizations are embracing it more swiftly than their older and big brothers.

What is the change? Is this only a process engineering change?

More than an engineering change, this transformation calls for an overall mindset change to look at things differently this time. For this to be successful, along with engineering and business functions,  the other cogs in the wheel, like procurement, finance, legal need to embrace and understand the nuances so that contracts are written differently, trust is built up mutually and collaborations gets better over  so much discussion on penalties.

Quite a few of the organizations have taken this to the next big level of doing even things outside of engineering in Sprints and Scrums and they are getting real benefits – Business Value of correctly completing the work in time- out of this short cycled, feedback oriented practices. Starting from conducting workshops and management meetings at every level, discussions for event management or any new change are being time boxed with a clear goal and agenda to reap the efficiency benefits out of them.

It is encouraging to see the organizational behavior changes happening with much more to be done. The systems and processes built over a quite significant period of time need to be rechristened to facilitate the change rather obstructing it. Some of the agilists, besotted by the advantages of this model, have taken the onus on themselves to champion the cause. At the end, it is the basic mindset that needs to change of how you see things. Personally I have a strong belief that with the support from all around and strong determination at the helm of affairs, this is not going to fail albeit some changes forthcoming. Whatever project you think or visualize, try to find answer in Agility.

Share your thoughts !!!.

–Jayanta Tewari

Standard