Agile leadership

“Inspired by Paul’s book “Rogue Leadership: Harnessing Headwinds to Drive Performance” – I decided to try some points described in the book on practice at Code Inspiration. When I contacted Paul and shared my experience, we both agreed, that the points we discuss might be interesting for other participants of IT outsourcing community. That’s how we have decided to share our thoughts in a co-article”. – Yulia Koroleva, Head of Business Development at Code Inspiration.

The article was written by Paul Rosenberg – a top-rated writer from the USA, international coach, leadership expert with a unique leadership approach, and Yulia Koroleva – clutch.co contributor, Head of Business Development at Code Inspiration – international consulting and software development company.

“Learn from yesterday, live for today, hope for tomorrow. The important thing is never stop questioning.” – Albert Einstein.

ASPECTS OF AGILE TEAM LEADERSHIP

What happens when a leader becomes part of a team? A team that depends on equal voices, inputs, creativity, and less formal roles? Nothing is more fraught with risk than when a leader must “lead” an agile team.

An agile team, by nature, is built on collaboration, and improving its own velocity. These core characteristics are often opposite of a leader’s role as ultimate arbitrator and decision maker. And then there is the Scrum Master, who has responsibility for guiding the team through if you are in Scrum mode. Once can keep this simple, but most leaders we’ve worked with make it complicated.

The struggle that all leaders have in any situation, much less being a part of an agile team, is understanding their role and value, and more importantly, when to apply it. Because they are ultimately accountable, there is a tendency to put their stamp on all that they do. When it comes to true agility, “their stamp” is often not needed, but their presence as an equal voice in the team.

In Agile, teams use Agile project metrics that help to measure the development process, gauging productivity, and product quality.

First, some obvious and common pitfalls:

• According to statistics, 16% are agile projects completed on time, 31% cancelled.

The popularity of agile in Software development companies keeps growing, and if we check the statistics, according to the Standish Group the percentage of successfully delivered projects grew from 16 % in 1955 to 42 % in 2019.

As well, according to the information provided by PMI’s “Pulse of the Profession” agile techniques are ALWAYS applied by 11% of organizations managing their projects, 29% OFTEN, 31% SOMETIMES, 17% RARELY and only 12% NEVER.

The percentage of failed projects decreased significantly from 31% in 1955 to 8% in 2019.The numbers prove that agile is becoming more and more popular and applicable in the IT sphere as well as in many other social industries.

• Unclear need in agile and misapplication of the methodology.

In the software development companies, the list of methodologies to set the in-house processes is pretty long: waterfall, extreme programming, Critical Path Method, LEAN, and so-called hybrid methodology, when some of the methodologies are used. Usually it is a mix of Waterfall and Agile technologies.

Does agile always suit all project types? – for sure no. We also assume that it was one of the reasons why 25 years ago there was a great number of challenged projects applying agile, what means not delivered on time, or were delivered over expected budget. Companies were trying to apply agile on every project, which was one of the biggest mistakes.

For the little and well-defined projects, it is always better to use waterfall, when the budget and the scope of work are done in the very beginning and changes are not accepted during the development. Also, waterfall methodology will be much better for projects, where the client is not going to participate and communicate with the team on daily basis to discuss and re-prioritize the tasks for the next iteration.

Hybrid approach is usually recommended for the projects which require well-defined structure of the initial requirements, however, need flexibility as well.

• Executives must be able to remove obstacles and support, and often times they don’t understand that key role.

Most leaders believe that they must be decision makers or responsible for the outcome. This affects their ability to let go of that role as a part of a team. And no, there is no one single solution how to avoid this pretty common situation in the company. But for Code Inspiration, we found a solution in one of ideas described in Paul’s book. In few words, the main idea was to let team members take their own decisions. From one side it could seem very easy, but on practice it was not.

Examples speak louder than general descriptions, here is an example from Code Inspiration team:

“About half a year ago we were planning a release of a product version, very important for our client in order to show to the stakeholders. His meeting was already scheduled and it was extremely important that the version worked flawlessly to get funding for further development. While final testing we unexpectedly discovered an issue, even some issues, which were not affecting the general overview or logic of the website, however, we knew how important the release was for our client, and didn’t want to risk. We decided to make all possible and impossible to provide our client with a release version ready for demonstration. The team was tired and, of course, not all the team consisted of developers, however, no one left home earlier that day. Our CEO was testing with the rest of the team, and our business development department was serving tea and sandwiches. It was clear to everyone that our CEO or Project Manager would have never delivered the result, if the development department decided to leave when their working day was over. Title and department didn’t matter. We were truly a team.

For me, it is a great example, when developers decided not to leave until they delivered results, and the managing staff decided to support them. We reminded everyone that because we worked through the evening together, we all experienced the meaning of teamwork when leaders were assisting the development team in order to reach success.” – Yulia Koroleva.

• Decision makers can be threatened.

The main forms of threats in IT outsourcing are the following:

1. Threat one: Additional requests for work free of charge. When you have a project with a predefined budget and scope, the customer asks you to perform additional “little work” free of charge as a matter of good faith.
2. Threat two: Delayed bills won’t be closed. The customer delays paying the bill, and the company stops work as bills are not closed. A rock and a hard place. “If you don’t proceed working while waiting for us to resolve our monetary issues – your company won’t be paid at all even for the work which is already done”.
3. Threat three: Contract demands mid-project. When your own team participants are threatening CEO who hired them to work on a long-term project to provide them with a higher salary, otherwise they threaten to leave the company. And as a result, the development agency won’t meet its obligations according to the contract with their customer, because it will be extremely difficult to change the developer at that stage.

Yulia’s comments: “One more funny story we had at Code Inspiration. A mobile developer, not a rock-star, but not a bad one, asked for the third monitor, explaining that this will help him to provide better results, then he asked for another chair, then for few more improvements to his working PC. One day he came to the office and announced that he was thinking of a “corporate bicycle” … He was fired the same day”.

What to do if you are “leading member” and people keep threatening?

– Yulia: “I have found one of the solutions in Paul’s book. Try not to react immediately. Take a pause, and take decision the other day”.

– Also, remember, if the other person plays “dirty”, you can always show them that you have options. If the customer doesn’t pay bills – usually according to the contract you cannot share the source code for which they haven’t paid yet. And you have also the right to pause works and even if they finally pay for what they have ordered

– You can change the conditions to the prepayment, for example.

– With regard to your employees or people you are leading, if you are an honest leader always looking forward, providing your team with interesting projects, the pizza deliveries on holidays or simply being an authentic human, this all strengthens your impact. If you have problems with your own team, check how you can improve yourself before evaluating them. This models much needed accountability.

• Real energy and commitment are needed, and so often may organizations and their teams go through the motions, but haven’t created the right culture and environment to execute this fully and authentically.

It is of the highest importance to create an atmosphere when all team participants are ready to help each other. A good agile team lead is the one who not only verifies the code, but also the one who can help to find where the problem is. A good agile project manager is not only the one who sets tasks, but also the one to whom the developer can apply in order to get clarification and advice. A good agile office is not only the working place, but a second home for employees. There are hundreds of coaching methods and techniques in order to establish a great working environment. In this article let us mention few but proven on practice for your consideration:

1. We believe that 5-minutes stand-ups every morning help the company’s leaders feel the atmosphere in the company.
2. Brainstorming is also a good practice to hear the voice of all team participants. Ideas derived not only from one single mind usually are better applicable, also, for a leader it is a common technique to listen to other ideas in order to form the unique one.
3. Company events, playing games after work. The main idea is that people spend most of their time at their working places, employees, who feel like being “at home” deliver better results.

One of the leaders we have worked with was certified in agile and lean processes in a high technology environment including software development. The issue was when he executed work, he did so in a totally different way. The agile label was his crutch, but his day to day work did not reflect agile philosophy at all. He controlled output, wasn’t open to ideas, never engaged, and as such, his team’s performance suffered. He fed the “agile” process machine to his superiors and his team, without really being agile day to day. This is a common issue…checking the box.

FIVE KEY POINTS FOR SUCCESS

1. Be flexible. Agile is known for its flexibility. The agile leader should follow the main principle of the methodology.
2. Make sure agile suits the project. Agile methodology doesn’t suit all project types and all business strategies. In order to benefit from selecting agile – make sure it is suitable in your concrete case.
3. Let others take a prominent role. Being a leader in an Agile development team doesn’t mean talking ALL the decisions on your own. Let your team participants decide and be accountable and responsible for their decisions. Let them drive the process.
4. Be human and open to feedback. If you feel like something is wrong with the “home atmosphere” in the office, don’t start criticizing or firing team participants. Take a deep breath and think of how you can improve yourself as a leader in order to be an exemplary employee would like to follow. As humanity + leadership is a well-known formula of success. Connect authentically.
5. You don’t have all the answers. Your job is to remove obstacles, guide, and support the people around you to be their best. Your success is never in a vacuum; its created mainly by those you lead. Enough said.

You can always take up a Team Leader training course to master the key skills you need to lead a team effectively.

Aware leaders, or in today’s street vernacular, “woke”, understand that when they join that team, they are literally one of the team, nothing more and nothing less. That being said, they must communicate to the team beforehand that they understand this, and that no one should fear their presence or worry, as they will function accordingly. All leaders (“woke” or not), must communicate this at the start. And more importantly model it. There is nothing worse than saying you are one of the team, and acting like you are leading it and dominating the discussion. You actually will create a more powerful presence, and create better results.