Self-Organization: The Linchpin of a Successful Agile Team

The biggest paradox of a Scrum Master’s role is to become obsolete. We all should aim at ensuring that we coach and build teams that do not need us in future and can run by themselves. Though this might raise concerns in minds of many, for me this was a challenge I took upon myself when we created a new product team in my company.

When you are set to reach a milestone, you need to start right. As they say the first step in the wrong direction sets you off-course for the entire journey. We were a few engineers with varied skills, levels of experience, and were from diverse cultural backgrounds, but we had one thing in common, the zeal and passion to succeed, and succeed together.

Bruce Tuckman's Forming, Storming, Norming, and Performing model describes to a great extent how a team evolves into a high performing team. But these are the times of getting things done at a pace never done before and with the quality never imagined before, hence we not only ensured that we gave every individual enough time and flexibility to understand the way of working of every other person in the team, but also ensured that the team started delivering as early as they could and probably skip a few steps in Tuckman’s model of team formation.

 Fig: Bruce Tuckman's Model

As a leader one needs to ensure that the team is built up on a foundation of common goals and objectives. It is never X’s task or Y’s story, it is always the team’s work and the team’s success and also the team’s failures. We shall never provoke any internal competition in a team; in the short run we might gain results faster, but in the long run it creates barriers for growth within the team members.
Following are a few practices that I imbibed and which helped my team not only to become a self-organized team but a high-performing self-organized team.

1- Safety is the default.
Have you ever noticed the smile on a kid’s face when we toss them in the air, they feel no fear of falling or getting hurt? Wonder why? Well, because the kid is more than sure that he will be grabbed safe when he comes down. That feeling of comfort and safeguard is what we have to instill in each and every one within the team. Risk taking shall be a default, and individuals should never be questioned on failures. Nobody would try going that extra mile, if they fear being questioned in case they fail.

2- Learning shall never stop
With the way technology is changing today, it is extremely important to keep the team abreast with the latest technical knowledge. If we invest in our teams, we reap the benefits multifold in a long run. And it is not just about sending folks for technical trainings but keeping them equipped with appropriate tools and resources to help them train themselves when the need be. In my team, we ensure that every individual has a Pluralsight license, which gives them the flexibility to take up self-paced trainings.
There was once a time where my team was very new to Polymer, and we were expecting a lot of work coming our way in that. The team members themselves decided to spend a weekend and go through a couple of courses on Pluralsight and do a POC. After just a few days into Polymer, they were not only working on it, but soon enough guiding other teams as well.

3- Value individuals
One thing that we should understand is that each and every individual in the team is equally important and valuable for the team’s success. A team is not a team without its people, if we do not value our team members’ personal life and well-being, they will never value the company or the products they work on.
In my team, we give due respect to individuals’ personal life. I don’t remember a time when anyone in my team was on leave and we called them for work, unless it was an emergency and couldn’t wait until the individual was back to work. One thing to understand is that an individual has voluntarily taken personal time off, that itself is an indication that he or she wants to be away from work, we don’t do any good by bombarding them with queries or favors to get work done while they are officially on leave. Also, denying leave is a thing of the past, these days I see emails floating in my company urging people to take break from work and spending time rejuvenating.
But this comes with a responsibility from the individual's’ side as well. In my team, we send details of any planned vacations as soon as we plan them, even if it is a month or two in advance. This not only makes everyone aware of your probable absence but mentally prepares everyone for it and any foreseen dependencies can be mitigated well in advance.

4- Empower teams and people
With great power comes great responsibilities, and this aspect not only requires an open leadership but also a set of matured team members. When we empower people to take up responsibilities, not only things move faster towards completion, but we instill a sense of ownership within everyone. It motivates teams to take the right decisions for the success of the product. They manage their work as a group, they may still require mentoring and coaching but do not require command and control.
In my team, we ensure everyone owns some or the other part of the application from the code perspective or own a part of the process such as cybersecurity, defect tracking etc. This way we not only involve everyone while we take the product to completion, but we also ensure that every individual considers themselves an intrinsic part of the team and not just a resource working on code.

5- Appreciate and recognize teamwork and attitude
Continuous appreciation for work well done, acts as the catalyst for multi-fold growth of a team and its members. Appreciation motivates people not just to do what they have been doing and but to do that more. Quoting a very unique observation by one of my leaders about my team,
“Keep up the great work that you all have been doing. It is great to see that you all work for each other’s success and go beyond boundaries to help each other achieve their goals, while focusing on your own priorities.”
These few lines of encouragement for the team, not only made the team bond better but they induced comradery and the “we are one” attitude; ultimately making the team more cohesive and efficient. So, appreciating the right attitude and teamwork is far more important and shall always precede over individual recognition. In most of the cases it is never a single hand, but always a team effort behind a successful outcome and a happy customer.

6- Deliver value and not just user stories.
One of my fellow agilist Kalpesh Shah talks about not being Backlog Lumberjacks, and instead deliver value and think about outcomes for our users. The team should be delivering value and not just running the race for story points. As leaders, we shall never consider story points as a means to judge a team’s success or failure, they should only help the stakeholders keep a track of the timelines. If a lot of importance is given to completing more story points, it might lead to development of a software which has a lot of stories implemented but none of the features ultimately add value to the user and help them do their job well. Value shall take precedence over story points.

7- Processes are to help.
Many times, we fail to understand that processes are there to help us do our jobs better and faster. In my team, if anyone feels that a process is stopping us from doing things better or faster, we simply get rid of it. If we do not see any repercussions of that, we continue or else, we change, try something new and repeat. The whole concept of Agile is to change for the better, and that is what we continue doing in my team. This not only delights the team but also makes them believe in the system.

8- Aim at product development and not just software development.
When we build software, we think about features, but when we create products we think about usable features. That is the mindset we shall bring about in every individual within the team. I was once a part of a review meeting with a scrum team, and the discussion was going on about a feature being no value add for the user. I was shocked and surprised to witness one of the engineer state that he needs to get his tasks completed for the scrum update tomorrow and isn’t bothered about what will be used or not. Even if we add a feature which makes the software smart, but it is never used by the users, it adds no value. Grooming individuals to question the status quo and work with a product mindset is a must for the ever-changing competitive market.

Take control of your career and become a project management expert with our PRINCE2 Practitioner course online. Our comprehensive program provides the knowledge and certification necessary to succeed in the industry. Sign up today and unlock your potential for success!

All in all, it is not about etching rules on stone, but setting the ideas and thoughts in practice and that's what makes it an amazing challenge for each one of us out there looking for making their teams self-organized.