Agile Fails

"To be pressure-proof, a process needs to become second nature." We look at learning from and overcoming the issues that slow our teams down.

photo of Samir Hanna
Samir Hanna

Agile Coach

photo of Samir Keck
Samir Keck

Lead for Agile Coaching

Posted on Nov 02, 2017

Learning from and overcoming the issues that slow our teams down

As Agile Coaches we meet a lot of teams, engineers, product people, leads and managers throughout our daily work. Not all of them are agile experts and we understand that there are some misconceptions about “agile”. When we encounter a misconception several times, we see it as a pattern that we can overcome.

We’ll take a closer look at some of the misconceptions surrounding “agile”, or what we refer to as #agilefails. You might even recognize some of them from your own organization.

1. #Agilefail: “Process is bypassed” Teams often see their processes bypassed. For example, under pressure, stakeholders may directly push their needs on the team instead of using the existing planning sessions. Or perhaps management asks for (push) reporting instead of using a review meeting. In practice, this could be considered disrespect to processes.

To be pressure-proof, a process needs to become second nature. This can be achieved by reinforcing the social dynamics between the team, the stakeholder and management. From our experience, it takes between six and nine iterations. This is also known as the forming, storming, norming and performing phases (this is assuming the team goes through these phases without disruption).

What can you do to build a routine?

  • Build your process collaboratively with your stakeholders and management
  • Reinforce the connections within this group (team, stakeholders and management)
  • Protect your team from disruptive change (new hire, team split, complete new setup) during the six to nine iteration period
  • Monitor and refine your process (using retrospectives)

As a result your process will become a routine.

2. #Agilefail: “No more meetings” This is a sentence we hear a lot in coaching sessions with teams. “We want to work, we do not want meetings.”

Let’s use empirical data to make a decision here. Take a look at all of the Scrum meetings or activities involved in a weekly sprint: Backlog Grooming (1h), Planning (4h), Demo (1h), Retro (1h) and Standup (1,5h). Altogether we end up with around eight and a half hours spent, which equals around 20% of our work time.

We observed that if you do not spend time well-ordered and organized in these meetings, you will need to spend more time in unorganized meetings and alignments. Without proper planning, you spend more time planning small bits and pieces throughout the week. Manage and optimize your time to organize so that it does not exceed 20%. Structured meetings with a clear purpose means less meeting time in the long run (not less meetings).

3. #Agilefail: “More people = more outcome (team setup)” Sometimes we hear the following about teams and their workflow: “Teams need to grow in order to get their work done and speed up” or “Agile means constant change and therefore it is okay to change teams very often.”

It is a common misunderstanding that adding more people to a team will increase performance. If you look at team dynamics ( e.g. the team phases defined by Tuckman), you see that every team goes through a “natural” development. Every time you add a new member, team development basically starts back at zero. This means that every newly added team member will slow your team down, bring it to a “storming” phase again.

null

Secondly, team size has a natural peak, where communication, alignment and number of members are in balance. If you exceed the size of a team, alignment will take more time than the resources of the extra person will add.

null

The LeSS Framework gives us four indications for a well structured team:

1- Dedicated teams 2- Cross-functional teams 3- Co-located teams 4- Long-lived teams

4. #Agilefail: “Output instead of outcome” Some members of our department indicated that teams that end up becoming more and more efficient, but focus mainly on themselves can be problematic. In the end, they are somewhat closed-mindedly steering “agile” to focus on their velocity (“We get faster and faster”). This is a failure we have also seen a few times ourselves.

“Agile” focuses not on getting faster and faster as a team (output), but on delivering constant value to the customer (outcome). There is no bigger waste than delivering valueless software, but in a very efficient way. “Agile” makes us deliver what customers need and enables us to learn from their feedback. It is more than a tool to purely optimize the workflow of your working items. It is vital for an efficient and satisfied team.


We're hiring! Looking for a new leadership challenge? Consider joining our Leadership team!



Related posts