What does Leadership look like in an Agile Environment?

By David Salt
By David Salt

Principal Enterprise Architect

What does Leadership look like in an Agile Environment?

By David Salt
By David Salt

Principal Enterprise Architect

What does Leadership look like in an Agile Environment?

By David Salt
By David Salt

Principal Enterprise Architect

Vision Disagreement

When working in Agile environments where the vision of a project is potentially flexible, the development team may feel that their ideas for the vision are of higher value compared to another stakeholder’s opinion.

 

As a leader, I would remind those that disagree with the vision that the decision ultimately lies with the Product Owner outlined in many agile methodologies and framework such as Scrum. In Scrum, for example, the Product Owner is the person with the budget and the vision. It is up to the team to respectfully persuade the Product Owner to see their point of view. If, however, the Product Owner does not agree to the change in vision and is prepared to pivot, the team should respect the Product Owner’s decision.

 

Process Disagreements

I have seen this many times before, where the leadership team wishes to use waterfall and endless Microsoft Project files and the team wishes to be agile and use Jira or Azure DevOps. Let’s not assume that agile is always better. For military or defence system ICT&S engineering projects, Waterfall is often a good fit as the specification must be agreed upon in full prior to the contract being signed. Any deviation from the contract must be handled through strict change requests. In these cases, as a leader, I would be guiding the build teams of the benefit of waterfall methodologies and the best practices.

Likewise, if the stakeholders are building a new application, but are not quite sure of the scope, and are insisting on a waterfall approach having the requirements and designs completed upfront; I would consider consulting the leadership team on the benefits of agile and the advantages of a “get to market first” strategy by adopting a minimal viable product. Subtle process changes can be resolved through retrospectives; inspecting and adapting to what works and what does not.

Feature and Story Disagreement

Assuming that the user stories have been written with a clear definition and clear acceptance/success criteria; it is up to the team to implement the technology that best fits the user stories. As a leader, I would also encourage the team to do the least amount of (satisfactory) engineering to achieve the requirements, maintainability, scalability, and extensibility. For example, if we are securing a simple website for an online competition, then biometrics is hardly necessary.

 

This would most likely be a simple website, which is short-lived and does not require military-grade security. A simple username password would suffice, or at most social media OAuth. However, if we are building a bank’s web-banking application, I would suggest using much stricter security measures such as MFA.In other words, finding the right tool for the job by understanding the scope of the job and, the costs and benefits of all the tools made available to us.

Disagreements with the Customer

It’s not always true that the customer is always right. The customer may have strong opinions on how something can be achieved; whether it is the scope, the process or choice of technology. As leaders, it is our duty to respectfully disagree and to challenge where we honestly believe there is a better choice to be made. Whilst we may not be in the position to make the decision, as leaders and trusted advisors we can suggest viable alternatives together with the benefits so that the customer can make the best possible decision. Once the decision has been made, then we must back it, bringing a sense of unity and professional guidance to ensure success.

Personal Conflicts and Differences

We are all professionals, and so we must behave as such. It is not always easy to remove one’s ego from the equation and judge situations objectively. When differences become heated and on the verge of conflict, it is important to “stick to the facts” and remove opinions and hearsay. Lay the facts out on the table to identify the issue and resolve it as swiftly and decisively as possible. It was once said to me that a small spot fire is much easier to put out and will cause far less damage than a major bushfire, therefore it is important to address the issue quickly to avoid lingering tensions and conflicts.

Leadership has Changed

Leadership has certainly changed over the last 10-20 years. I remember when I first started working in a sheet metal factory 20+ years ago, it was a very masculine environment, and I would describe my supervisor as bordering on being autocratic. There was no such this as career growth, and so my leader would not invest time in cultivating my skills or guiding me. I simply needed to get my work done and if did not like it, I would be reminded where the exit was. When I first started working as an IT professional, I found that the environment was so very different. My leaders would provide me feedback (usually during a performance review), be willing to invest in me, and spend time with me to understand my ideas and suggestions.

 

However, they were still very much a manager who had subordinates. Ultimately my successes were their successes, and my leader would take credit for their team as they were the one who managed the team. And it was that last point that is the biggest change in leadership over the last 10 years. Leaders used to be the managers. Instructing a team of people to achieve a task/outcome that had been handed to them by their manager. Modern-day leadership sees the leader working together with the team to achieve an outcome, that may even have been the team’s own initiative. More like a captain in a sports team, instead of being the general manager or the owner of the sports team. It is a visual we see on LinkedIn so very often, but it is a timely reminder of how leadership has changed to be that of servant leaders. Which is a nice segue into “What a good leader is…”.

A good leader is...

A good leader in agile environments is one that is a servant leader. That is, someone who has the team’s back and will work for them and with them to resolve issues, whilst paving the way forward and provide direction for the team to succeed. A leader is only successful when the team is. It is important for the leader to be honest and call out when they do not know the answer, whilst providing an opportunity to find out. A leader must share in the team’s successes and never take the credit, whilst recognising all of those who have contributed.

 

A leader must uplift their team members, whether it be through individual recognition, providing mentorship, counselling or guidance as well as enabling professional growth through learning/training, opportunity to demonstrate new skills or through career growth pathways. On the flipside, it is also important to identify areas of improvement with the team. That is, the leader and team both have the responsibility and ownership on what and how to improve. A leader must be prepared to have tough conversations when required whether it be with the team, a team member, or the client. The leader must ensure that there is an environment for collaboration and open communication, whilst condoning persecution or belittlement.

 

The leader must be transparent to both the customer, the team, and the stakeholders. Leadership is also about self-reflection and seeking feedback and guidance. Understanding your own strengths and areas for improvement is vital for your own development and better prepares you as a leader. By leaning on others where needed brings strength to the team. By cultivating a safe space where voices are heard, and an openly honest, transparent, and collaborative environment, leaders will foster trust and a sense of unity between the stakeholders and the team, ensuring strong united decision making and collective success.