Is your team Agile or Fragile?

With the massive increase in the number of products launched in the past decade, a lot of organizations have adopted the AGILE approach as a system of managing their processes.

Agile involves an approach of development in which the requirements and solution of a project involve the collaborative effort of self-organized and cross-functional teams. This approach has made software development more effective in the last couple of years.

To learn more about Agile, you can simply search online, there are tons of resources online that talk about how to run and manage an Agile team. Link

Whilst a lot of people claim to follow the Agile approach in their processes, the truth is that they are actually following a Fragile approach.

In this post, I would outline 5 signs that would indicate if your team follows a Fragile approach and not an Agile approach.

Are you ready?

1. When all the ideas come from the management/leadership and not from the team building and managing the project.

For a lot of organizations, the whole idea of the product comes from the leadership and not from every team member. This is a fragile system. The best ideas could come from the least expected mind.

If you follow the HIPPO’s rule, then you are building a Fragile team. HIPPO is an acronym for ‘Highest-Paid Person’s Opinion’. Agile suggests that the voice of all the stakeholders be heard.

I was recently reading a book I’d recommend for any product person titled INSPIRED by Martin Cagan. He stated that in his early years as a software engineer at HP, they spent over a year building an AI-powered technology. They spent a lot of time and resources but at the end of the day, NO ONE bought the product. I learnt a big lesson here, the voice of the users of a product also needs to be heard. It is important that the pain points of users are adequately understood if we are to build a great product.

2. When tasks are not well defined and documented.

I played the telephone game in a group of 10 friends some time ago. Person 1 whispered a word to person 2, Person 2 whispered the word they heard to Person 3 and we went on that way until Person 9 whispered the word he/she heard to Person 10.

Person 1 then told us what he initially said and Person 10 told us the last word she heard. The words were different. Somehow, the initial message had been corrupted as it moved from one person to the other.
This is why every major decision has to be well documented so that all stakeholders have access to the same information. Word of mouth information always have tendencies to be filtered down as it passes from one person to another.

If you have a meeting and you come up with very brilliant strategies, it is important to properly document this so that people who would work on the project in the future would have a clear understanding of what is to be achieved.

3. When activities are not time-boxed.

Timebox is the agreed time that a team works towards in order to achieve their goals. This is why teams must have well-defined sprints and scrum ceremonies.

I have worked in teams where we followed the five scrum ceremonies captured in the image above and I have worked in teams where we worked on activities as they come. I would confidently tell you that life is easier when you time-box all team activities and the results are better.

Adopting sprint events allows a team to work more effectively. You can read more about timeboxing here

4. When little or no attention is paid to continuous delivery.

You do not have to build an entire solution before launching to the market. Agile teams build and launch an MVP to the market, learn what works and what doesn’t work early enough and iterate over the right strategies to be deployed.

Fragile teams spend lots of time and resources trying to build a solution they think should work before launching to the market.

This was the challenge Martin Cagan described in his early days at HP. They spent one year building a product that no customer ended up buying.
A better approach that HP would have taken would be to launch a small feature or chunk on the product to the market and learn what works or what doesn’t work early enough. This is the approach an Agile team would take.

5. When the team burn-out rate is very high.

I understand that a lot of start-ups have to move at a very fast pace in order for them to meet up with their personal target and the ones set by investors.

When team members are overworked, they might not be able to put their best foot forward and one might begin to lose key team members.

I know there are other indicators of a Fragile vs an Agile team. I would love to know what you think. 😎