The year of the Rooster is upon us - Gong xi fa cai!
When I walked out of my farewell party a day ago at my client’s place, I had some mixed feelings, which I wanted to pen down the soonest possible. Hence, here they are, my thoughts, my learnings, together with slight comparison with my previous experiences.
Our client, a well-known software development company was hired by their long term client, who are in transport business for decades, to develop a new, cleaner platform to replace the existing one. One of the clause for this project is to run the project with Agile approach. Client team is now undergoing an agile transformation and hence we are sharing an approach here of how we have done this transition with slight difference to other agile transitions. Apart from the software development team, we are also introducing agile principles and practices to the way the business teams (Product Owners, Stakeholders & Users) work.
Here’s what we have learned and why I think what we’ are doing is crucial to a successful transition:
1. Responding To Change Is An Attitude.
It is not in everybody’s boat to welcome changing trends. It takes courage to face and embrace changes. For some, changes can be both traumatizing and dramatizing; and it is quite a common trait to notice frustration, anxiety, feeling a sense of insecurity and strong display of objective actions. My clients faced multiple challenges during the transition with their vendor and internal IT teams made up of international engineers, a challenge in conversing in one common language and very high resistance to change.
Even though the above gives a bit of discomfort, the actual fact, according to the researches, is that only 20% resist the change (regardless of its merits), 20% embrace them (on its merits) and the rest of the 60% wait and see before adopting them.
This is where organisational leaders play a vital role in change adoption. It is an applaudable attitude that flows from the leaders of the project to the rest in the organisation, providing strong positive and confident vibes. More is covered in the following point.
2. Belief System Flows From The Leaders
As mentioned in the previous point, leaders play a vital role in change adoption. When leaders pitch an idea, in which they do not believe, and it’s purely for corporate progress, that idea usually ends up not getting far. In the case of my project, the client’s belief in Agile transition and the progress it can bring to the organisation is much stronger than the vendor’s. We could see for ourselves how fast the client’s team transited to the Agile process in comparison to the vendor’s team. The learning point here is that we cannot just dream big. We must also be passionate about converting the dream into reality. The thought waves of “we are good”, “we are making changes for betterment” and hence to be “the best in the market” and to “give only the best to our clients” are usually the winning pointers in a pitch. Passion is one of the most important attributes that any change maker can possess. Nonverbal languages like the energy level and the body language of a person is understood in a higher radar than the spoken ones.
Thus this is the non-spoken belief system that flows from the leader to the team, getting them to trust the introduction to change with confidence.
3. Planning Is ‘The Key’
In all the projects I have worked on, my emphasis is always the thought that Sprint Refinement, Sprint Planning, Quarterly Release Planning are more essential than the words themselves. Like the previous transitions, the current transition also had a toll on the team and they were showing resistance to frequent communication and planning sessions and above all, newly introduced set of “Meetings
”. Scrum process can be a quick one and something that speeds up business to be very responsive towards market conditions and changing trends. However, that doesn’t mean planning need not take place. Just talking for days about what needs to be done, in short paralysis by over analysis does not lead to any delivery. At the same time over planning doesn’t get us anywhere close to our deliverables either. Following a planning style, for example PRET (PRET = products … resources … effort … time-scales), helps.
Not to leave out retrospective. I see this as one of the most important meetings for us to reflect on our actions and decisions. It helps us to continuously give ourselves time to ponder on making processes better and learning on the way.
4. The Mighty Pair Programming
It is not an overnight incident that made me develop a strong belief in pair programming. It came from he benefits I have seen over the past couple of years through multiple projects and teams. Distributed teams, across 3 countries, following scaling agile framework, consisting of over sixty developers, and belonging to fifteen different nationalities,could not be wrong when they say they work better with pair programming. Pair programming speeds up the time invested and the efforts involved in the development process; learning from one another, discussing, giving feedback and coming up with creative solutions to resolve complex software/system development are just few of the benefits gained from pairing. I have also noticed that it is loved by clients and stakeholders. The reason being, the clients have come to an understanding that they are getting a better, as in, a faster and mightier system from teams that practices pair programming compared to teams that do not.
5. Recognise & Appreciate Individual’s Different Skills & Strengths
Corporates have always been budgeting aside an amount for appreciating and recognising their staff. Why is it so important?
Regardless of the nature of our jobs or our positions, the bottom line is :we are all humans and to value and desire a sense of positive reinforcement of our accomplishments are deep rooted within us.
And when this value or desire is not recognised, people do quit. What needs to be noticed here is that people leave their managers, not the companies.
Through the various forms of recognition and appreciation, we can even build leaders within organisations, who will then give back to the organisations in larger unspoken and unmeasured scales. The best part is, these leaders do not need to be an organisational head or someone with already given authority. Anyone who takes the initiative to see the big picture, strives to understand more about the changes and its benefits and follows it with good understanding is also a great leader. It will not be a surprise when people around this person also follow them in a similar fashion.
6. Invest Not Just On Material Project… Also On Living Project.
- Material project meaning – the hardware, software & systems.
- Living project – our people, who are our asset.
Give our ‘living project’ the best training for the best skill sets available at any moment. When people feel worth it and that the company is concerned about their personal growth, they stick around for longer time and provide a much better output to clients as they will work from their hearts. Employees happiness index matters!
7. Using Tools Isn’t The Way To Manage Thought Process.
This is not the first time I have seen the middle management of an organisation trying to ‘manage’ people and their productivity with the help of tools. This is not unusual either, considering the fact that management is introduced to multiple user friendly tools and a process that pitches transparency and productivity. It is true that it is tempting, however it is not ideal.
Our People need to understand and change for themselves. No tools can do that. Tools may change to a different version; however, people work with what they believe works. Furthermore, there is yet to be a tool invented to measure the productivity of an individual. Mechanising it is nearly impossible.
In a nutshell, the Success of any project depends highly in Quality. From the quality of story requirements to the quality within our character, the desire to produce something that we can call our own with pride. Having a sense of Quality Within is the KEY to any Successful Project.
By Kris Bharathi, Scrum Master at why innovation!