Agile transformation with and agile process- part 2.
The agile journey of the Invitech’s CRM team is a perfect example, how far a small external intervention can take a team on their way towards self-organization, an agile, flexible way of working that is adaptable to changing customer needs. The international publication of the case study on our joint work (read it here) won the EODF Professional Diversity and Involvement Award. This project is obviously not just about the 3 months I was there as a consultant and an external agile coach. The team’s agile journey didn’t start and didn’t end there - we only achieved our best hopes in 3 months, after originally daring to dream completing it in a 6-month time frame.
The team continued to pursue self-improvement, and apparently successfully, 9 months later, they won the Agile Team of the Year 2020 Award. As we started working together, exactly a year ago, I have asked the project manager, Zsuzsi, to be our guest author and to write a blog post about the period after our joint works and that led them to win the award. In this post you will be reading about what has happened to the team since, and how, the agile transformation is progressing at the entire internal IT level or company (Invitech) level.
-------------------------------------------------------------------------------------------------------------
Zsuzsanna Papp:
Life after saying goodbye to our consultant
It would not be true, nor would it be believable, to say that everything went easily from then onwards, that there were no ups and downs, and that the road led us straight to the title of Agile Team of the Year Also, I do not claim that we have reached the end of our journey.
Difficulties as learning opportunities
We have encountered a lot of difficulties in the recent months which have offered us tremendous learning opportunities. I think it’s important to highlight this because experiencing hardship as a learning opportunity has a huge role to play in us becoming a high-performing team. We also discuss our mistakes that were made, while learning to correct them. In my opinion, this has contributed greatly to our performance and to earning the Agile Team of the Year title in 2020. When we are in a group, we don't consider this risky, embarrassing, and we don't judge any member in our group. It means that we want to get better and to do it better next time.
What happens if we make a mistake?
The mindset of making mistakes is acceptable, which means that there is also psychological security, which gives tremendous potential for development. By doing so, we dare to throw in new ideas. Some of them we try, but some of them we don’t. There are some that work, some that don’t (in this case we make a minor-mistake).
To make this as part of our team culture, it was important that the team members in a leadership position (such as an agile team leader or development leader) also undertake if something didn’t work out the way they needed or wanted it to. I emphasize this because they also have a kind of norming role, and with their behavior, their commitment they empower the team members, indirectly teaching them that it is acceptable to make mistakes.
The reason to our success is due to us being able to reflect on the individual, the team level, and to evaluate ourselves honestly and transparently.
At the beginning, the team atmosphere had some contradictions and tensions between its members:
the Project Manager held the developers accountable for their mistakes,
according to the developer, the analyst didn’t understand the system,
according to the line manager, the Project Manager should not have expected us to be ready in 1 week
Responsibility paired with opportunity
When we switched to a self-organizing modus operandi- shared responsibility and opportunity for change, inclusive, empowering methodology- the atmosphere also began to change. The goal became a common one, the mistakes became shared, everyone wanted the same thing, no longer arguing with each other, but helping each other.
As a result of self-organization, team cohesion has become almost indestructible. A constructive culture of discussion was developed in the team - we build on each other’s thoughts.
By now, the atmosphere in the team has been very good because of our solution focused orientation, helping each other, and understanding each other had become important to everyone. We also learned to praise and recognize each other.
In the initial period, there was quite a lot of resistance within the team about the new mode of operation, which caused the very first conflict. A good example of this is: the system of morning stand-ups, which was very difficult to start, seemed like an unnecessary pastime. However, after some time, colleagues themselves have seen the meaning and benefits of it, why it is good, and necessary. Basically, our method is to give it some time to try new things, and then give the team and each individual an opportunity to shape the way we work and collaborate. There was also a problem with the business area prioritizing tasks that they didn’t really believe in, but over time we managed to prove that this was the right and effective way to go. Our third tool in managing conflicts is faith and trust in each other, which we combine with consistency and provide an atmosphere where there is space and opportunity to discuss problems.
It's good that we're different
We have also made a lot of progress in managing diversity within the team. Just because we have different personalities, backgrounds, skills, and knowledge does not mean that we are exploiting the potential of our differences. Evolving month by month, the individuals increasingly dared to bring in their different thoughts or even qualities that might have previously seemed risky, “inappropriate”, and we were able to forge additional resources from them. In this context, I would also point out: as the culture of knowledge sharing developed, the team introduced and operated its own knowledge sharing forum, which took the form of trainings and professional show and tell sessions held by team members. Previously, many types of development tasks were characterized by the fact that only 1 person could handle and solve them, but thanks to our knowledge-sharing forums, we were able to reduce this exposure. The lead developer, who previously had difficulty with delegation, was able to master the principle of “knowledge-sharing power”.
Each member of the team mastered and embraced agility. We are not agile by means, but by our way of thinking and attitude. Instead of previous ad hoc deliveries, we have regular, monthly fixed deliveries without delay. Formerly conservative developers handle it flexibly and respond quickly to changing business needs, or scope. The experience of progress is constant, users receive some improvement or correction every month, so that they can get used to it, and learn it by the next month.
What does the business say about that?
Business areas have also become committed to the project and an agile mindset. They are thinking in phases, in functional application feature packages that can be delivered in 4 weeks:
Together with them, we have refined, and still refine, our operations and processes on a monthly basis
They are prioritized based on business value, the needs and requirements that create the highest business advantage / benefit are placed on the top of the backlog list
Additionally, demand appeared to investigate how we can achieve similar efficiencies with the tools of agile approach in our other internal development projects.
Trust and partnership: initial skepticism was reduced in a short time with improved transparency and continuous fixed deliveries, so we finally gained confidence. They have also been willing to make changes so that we can increase the efficiency of working together, e.g. testing in a fixed time window, preparing for prioritizing discussions, process interactions – feedback.
'Working with high-performing, confident IT is more effective than working with a team that struggles to exist without meeting deadlines. The overall mood and experience of progress was greatly enhanced by the perceptible pride of IT colleagues to perform well to the greatest satisfaction of the business.' – Sales Support Lead and Leader
What if the Project Manager steps back?
My personal role within the team continued to shrink and I was rather only in shadowing mode at grooming, stand-ups, weekly status meetings, retros, quasi still overseeing that things were going well. It also gave the team a sense of security that I was still there, I knew about everything and I would make a decision if necessary.
After each discussion, I regularly used reinforcing feedback with the team members involved for a few more months.
Later, I consciously began to retreat from decision-making as well to let the team make their decisions without me. I helped them with questions in the decision-making process itself, but in the end, the decision was not made by me, but by them.
Support of the business side and acceptance of the way we operate has been fully consolidated and the business side has also learned agility. I was listening with a wide smile on my faces while shadowing at each grooming, as Business actors convinced each other about the priority of business needs. ‘For the company, the business value of this is…’ ‘With that, we lose if we don’t step in… ‘ ‘Okay, the impact of my claim is much smaller than that, I'm giving up on that now’.
-----------------------------------------------------------------------------------------------------------
It is amazing to see how Zsuzsi got closer to the team, and then slowly further away from them, exactly the same way, in a similar way as I did as a consultant, coach, and mentor to her. As it turned out, Zsuzsi has been leading other projects since then, taking the methodology with her within Invitech’s internal IT. More and more teams are experimenting with finding their own agile path, often requested by the business area or their clients. Of course, it's not just Zsuzsi's job to spread well-functioning patterns, as developers also work in other teams, the business analyst also facilitates the retrospectives on other topics as well. Good practices are slowly, but surely spreading.
If you would like to learn the tools of the Solution Focused Organisation Development and Design to support Transformations and Business Evolution you can already sign up to our next Native in Change Program here.
コメント