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

Advertisements
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

Values of Team – Life Circle of an Org

Today I read the below post by Marillyn Hewson, Chief Executive Officer and President at Lockheed Martin, and felt good within. I felt ecstatic about someone somewhere thinking in in similar lines as me and reinforced my belief that I am on the right path.

http://www.linkedin.com/influencers/20130919113049-279253783-the-first-things-a-new-leader-should-do-to-build-trust?goback=%2Enmp_*1_*1_*1_*1_*1_*1_*1_*1_*1_*1&trk=nmp_rec_act_article_detail

This reiterates one of the strong values I espouse in my life  that is building trust with one’s team and being open with them. Going one step further, I personally believe that one should be  open with one’s team regarding failures as well. This surely makes you stronger in the eyes of your team members as only the weak hide things.

Power of handshake or taking out two extra minutes to listen to your employees creates such a bond which propels your team to rise above the occasion when needed to tide over a difficult situation. This should not be misconstrued to plan to be cordial to get your work done rather being sincere to acknowledge a good deed which creates the personality or character of the team.  The character is the determining factor and not the other way round.

While, practicing some or all of these principles, energize the peer level or the team under you, the possibility to experience a favorable response gets slimmer when applied upwards. Your boss, wanting you to be a go getter, might not tolerate the follies and foibles in the name of being “honest” and your career gets jeopardized. There are enough senior leadership personalities I have observed who stop short of getting introduced to the team below a certain level just to maintain the hierarchy and thereby fail to win the hearts of the people at every level.

The post, coming from such a senior leader, is quite refreshing and inspirational.

What is your thought?

–Jayanta Tewari

Standard