Below is an article and thought process I align with to a great extent – it got captured in my own way in my last blog “High Performing Organizations”.
Much has been dealt on these subject by subject matter experts but today I will try to capture my thoughts and observations on this topic. As this is a treatise from someone with firsthand experience in many types of organizations in social and corporate fabric, please expect this to be bereft of the theoretical jargons and research based theories.
Establishing myself a people oriented person -believing in ultimate team work and mutual collaboration, on one hand, I have seen from very close quarters that a set of people performing out of their skin and on the other side, smart players taking the cake away. Not going to the details related to tradeoff between hard work and smart play and associated charismatic positioning of one’ self, I will allow myself to put my thoughts around three very significant aspects of a higher performing organization in my view. It is the manager’s fine capabilities to extract the very best out of his team members and below points play a much bigger role in that aspect. They push one to overcome his/her shortcomings to take that extra stride for his manager to perform. As a manager or captain in as good as his team, careful look at nurturing the individuals is very vital for a team to outperform itself.
Reduction of blame game: Accountability and responsibility are two key elements of any decision making process and the results they produce in the context of time, resources and environment vary immensely. Sometimes the decision taken after much careful jurisprudence of facts in a certain context do not yield the required result and vicious cycle of finger pointing starts towards the decision maker or taker. This results into a situation of defensive argumentation in short terms and she/he stops short of any such actions in future. In the long run, when decision making is lingered, organization suffers. The way to come out of the situation is taking a stock of the situation at hand, minimization of further loss if any and chalking out the turnaround story as a team. This kind of environment allow people to think, take calculated risks for success and back up the failures as a team as and when needed for the next hurdle to be overcome or milestone to be achieved. The organization moves forward with sharing success and failures, win and loss in the almost in similar if not same stride.
Positive reinforcement is another very important factor that helps many a time individuals and team to outperform one’s capabilities. A pat in the back or appropriate recognitions often creates wonders beyond expectations. This is something to be done whenever possible and very often rather waiting for a special moment. Crediting someone only on special and exceptions occasions are all fine and good but they being few and far between do not act as a tonic to motivate a sagging mind. Dwelling more on the positives and as less as possible on negatives improve the overall work environment for high performance. Don’t get me wrong that I am ruling out factors like “root cause analysis” as they are very much important for best practices implementation and elimination of path of error but the spirit that they should be looked at makes all the difference. The art of sharing success in public and divulging failures in private during a day to day work process have a quite significant impact on performance.
Fostering Innovation is the third point I would like to discuss and very much related to above two aspects. For a company to stay relevant and bring more and better value to its consumers, continuously innovating itself and innovating the offerings are a must and a company has to be wild into that philosophy. There is no scope of conservatism or skepticism in the path of innovation as it often deals with unknown and hence uncertainties. One needs to allow and create a culture of thinking out of the box helped with lateral thinking and thinking in every direction completely out of the systemic thoughts and out of this world forgetting the boundaries of practicability and if they are fit to be implemented.
Effective Resource utilization and making sense of profit and loss are the thoughts exactly opposite the culture of innovation and do not go hand in hand. From that aspect, the innovating companies need to have a big heart and courage to take risks allowing employees to take decisions- some of them might turn into big duds and should not blame them for that. Pushing the bar and continuously fostering that culture not taking a step back or blinking an eye in the journey of innovation create great products completely out of the blue.
To my views, these three aspects, if cultured with belief and conviction in an organization, will certainly propel the same to the next orbit of performance pushing everyone a notch high. Ultimately the organization would benefit.
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?
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 !!!.
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.
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?