There is no doubt that many software organizations realize that market challenges are increasing nowadays more than ever. Such organizations are racing to deliver more products, with less resources and in less time.
This is pushing them –outside of their comfort zone– to consider process improvement, like moving to an Agile development process.
While this might be a step in the right direction, it still comes with its own challenges. One challenge that is usually overlooked by many organizations is not with the Agile process itself, but rather with the concept of “collaborative leadership” that governs it.
In one organization, the leadership team wanted to do the right thing. They knew they did not have Agile expertise, so they hired consultants to help with companywide training in Agile practices.
Both the leaders and the consultants decided to start training one of the critical teams, learn from the experience, then improve it for the other teams. The chosen team was responsible for a set of key and complex products.
The consultants interviewed the team to identify what their challenges and needs were. Then, they started providing them with education and training.
There were various layers of education provided: education to the practitioners, education to management and even education to the “to-be Agile trainers.” In fact, the latter were selected from those who inside the organization were perceived as believers in the process –those who could influence and mentor others on an ongoing basis. These individuals were later named “the transformation team.”
As expected, there was resistance by some people to the change process.
The training was focused on the various phases of the Agile initiative, its concepts and ceremonies, and the Agile mindset. Teams were taught one of the key concepts of Agile, which was that the customer drives the priorities, but the development team makes the decisions.
The training also covered the concept of the Product Owner –the voice of the customer that guides the development team and validates its priorities. They also learned that the customer, and other stakeholders, review the team’s progress at the end of each sprint via the sprint demos.
This was all good in theory. However, in practice, there were obstacles slowing the team and hindering its progress.
One of the most important obstacles had to do with the leadership team: it was not fully on board with all the Agile concepts. It was clear that leadership did not fully adopt the Agile mindset, and therefore, teams were getting conflicting messages from their leaders.
For example, commitments were made to customers in conflict with the team’s decisions and without the team’s involvement. The leaders were dictating the use of tools that the team did not believe in. It was clear that there was a classic “command and control” issue that needed to be dealt with.
Several studies have shown that the higher up in the authority chain decisions are made, the more likely these decisions are made without proper information.
The consultants and the transformation team quickly realized that they needed to address this leadership issue, otherwise the value of the transformation could be compromised.
A course on collaborative leadership was prepared and given to various levels of leaders and executives. The intention was to demonstrate what an Agile process looks like, and most importantly, to show what the Agile mindset means –especially as it pertains to leadership.
Two main points were highlighted:
It is common that development teams go to their senior leaders and executives for guidance and direction. It is also common for leaders to give directions and provide answers on how things should be done. However, this is not the right way in an Agile process.
If leaders give answers to problems that development teams face, it is likely that those teams will take those directions and implement them without questioning. After all, these management teams were hired for their experience so we should leverage that, right?
Well, operating under an Agile mindset, instead of answering questions, a leader looks for opportunities to prod the teams into thinking about the problem, the possible solutions, and the information needed to make the best decision.
Leaders should set the strategy and the general direction, but team members and SMEs (Subject Matter Experts) translate this strategy into what needs to be done and how to do it.
The training provided opportunities for leaders to practice how to work with teams who are used to going to them for decisions. Those leaders learned how to instigate an inclusive environment where everyone takes a role in the decision-making process.
The leaders also learned that pushing decisions to their teams also meant that they will need to trust them, and accept that mistakes can and will happen. They need to provide a safe environment for their team to fail, learn and take corrective actions. This is a healthy environment that fosters change and continuous improvement.
In summary, Agile transformation is a journey that needs practice and time from everyone. Development teams need to evolve in learning how to set priorities, establish roadmaps, and execute iteratively. Management teams should expect to learn through continuous improvement and need to practice collaborative leadership by empowering their teams to take decisions and learn from their mistakes.
“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” – General George Patton
A change in the mindset of leaders was not straightforward and required more than just training. There was frustration and there were setbacks. In some cases, some radical change was needed in the leadership itself.
It took several iterations to make progress. The leadership team started to attend a lot of planning meetings, request various status reports and challenge a lot of metrics used for project reporting. It took some time for them to build trust in their teams, but also for the teams to learn what information the leaders needed to gain their trust.
Eventually leaders understood that by enabling their teams to make decisions, those teams would feel more empowered, hence move faster.
Reflecting on this journey, I remember where it started and the various iterations it went through.
I recall the mistakes that were made, the challenges that were posed, and the dilemma of following the process versus following the loud voices against it.
Years passed by and overall, it was a successful story of a team that challenged its status quo and pushed itself into a more productive state.
I am Nariman Nasef and these are my agile-thoughts
2021 © La Canada Flintridge, California, USA by Nariman Nasef
Nariman is program director of IBM Cloud PMO Strategic Programs. Nariman’s experience spans leadership roles in various software portfolios as Performance Management, software defined storage and cloud platforms, in Egypt, Canada and the US.
She has also been an agile champion and transformation lead at IBM for the last 15 years.
Nariman is also a holder of master’s in engineering management and is both PMP and PMI-ACP certified. She is also an IBM trained coach.
If it inspired you, please share it!