Towards A More Agile Team

A challenge many software companies face these days is switching to an agile methodology. Agile has grown a lot since it’s initial start and it is now widely accepted as a good methodology to develop software, and in many cases even better than the original waterfall principle.

As can be expected many companies will want to change the way they work to take benefit of this. However, such a drastic change involves more than one might think. To get a clear view of this, I will discuss the original situation coming from a waterfall based way of working and what the ultimate goal is.

A waterfall approach usually involves many different people/teams, each with it’s own purpose and role, fulfilling one step in the model. Teams are managed by a team lead which fits best in the typical hierarchy of the company. Spending a lot of time in such an environment will create a narrow vision, where each person/team is only focused on their own part. On top of that a common phenomenon is that of “throwing stuff over the wall”, which means that as soon as you are done, you don’t really care about it anymore and it becomes someone else his problem.

How do we transform this to an agile approach where there is more involvement of all the stakeholders? The big difference between waterfall and agile is not that your team becomes responsible for everything, even when using an agile methodology everybody has their own responsibilities. The big difference is that everybody is committed, and a much more interaction between all the different parties is required.

A very simple solution, and one that is often done as it requires no understanding of the true meaning of agile is putting all the different people/teams of the waterfall model together in one team. Simply putting people together in a team will not take away their way of thinking, it often leads to the individuals keeping their original responsibilities and a lot of team-conflicts.

To make agile work, teams need to be shaken up, pull them out of their comfort zone and change the way of thinking. It is a drastic change and it requires drastic measures for it to really work. The major benefit or re-organizing teams and making them involved in the entire process is that they understand the bigger picture. DevOps is a nice example of this, instead of having a separate team for development and another for operations, putting them together makes the developers more aware of the effort that has to be put in keeping something operational. It opens their eyes ans leads to new insights which in turn will change the way how software is written to decrease the effort to maintain it. All of this only happens when people become aware and responsible of doing it, otherwise they only see the extra effort, without the benefits.

Another often made mistake is keeping the hierarchy intact. This contradicts with the main idea of agile, where the Team is responsible and must be free to do things as they see fit. Having a team lead in such an environment completely breaks this, pressure is put on the team lead as he is responsible and he in turn puts pressure on the team. A team that is used to work with a team lead will keep following orders and not achieve the benefits of the freedom a self-organizing team would have.

The main challenge of re-organizing a team is to keep everybody happy with their new function. I can imagine some people prefer to be focused on the activity they did before. This should not be a problem, it is up to the team to find the best fit for each member. I don’t mind if someone keeps on doing what he is specialized in, the benefit of putting them in a team with other people with inevitably lead to new insights as ideas are easily exchanged. And who knows what new pleasures one might find when he is free to explore other activities than those he is used to doing.

One big question remains though: “what to do with the team lead?” As mentioned before it is critical to get rid of the team lead, as this is what keeps a team from being free and self-organizing. Such a team will not reap the benefits of agile, but keep on doing what they are used to: following the team lead. This change has a lot of impact, not only on the team, but on the team lead as well, after all he gets a completely new function. Will he be demoted to a regular member of the team? Or does he get another function at the same level? There is no single answer for this question and it depends on the team lead his preference. The worst case scenario would be to let go of the team lead all together.

Moving away from waterfall to agile is a big change, and therefor it is inevitable that major changes need to be changed. However, such a change can not be limited due to objections of a few individuals. A change only yields the full results when everything that needs to be done is executed. Nothing should stand this in the way, as it leads to partial or even no benefits. Claiming that the new way of working is not an improvement due to a badly executed change happens too often, but can be easily avoided if the change is considered with an open mind.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.