Recognition in an Agile Team

Most of these agile teams were not led by an appointed lead developer, thus the teams had to jointly reach consensus on technical matters. I had been working as a lead developer, as well as a CTO at my own company, and, as such, needed to assume responsibility for the delivery and high quality of products. I, therefore, at first, found team equality strange, while I worked in Switzerland. As I didn’t have any key role within the teams, I felt that all I had to do was complete tasks, one after another, while sprints followed one after another. Team members didn’t dedicate themselves to different areas within a product development process, instead, after completing a task, they assumed a task on the task board and started to work on that.

The good performance of our team was kind of recognized, but I was rarely made to feel that I was a respected or even irreplaceable, member within the organization. I sort of felt that anyone could have done the job as I did.

Some of my acquaintances have also told me stories like this. For example, a friend of mine went to work for a Hungarian self-organized company (with appr. 20 employees) as a UX Designer, and one or two months later left the company, because he simply felt unappreciated and treated as one of many employees. He went to work instead for another company as a manager.

How to become a leader and shoulder individual responsibility

I’ve seen great potential in the startup organizational structure within the Swiss large company because of its products and the openness of the management and my peers. Nothing was farther from my mind than to leave the company, I, therefore, by virtue of the absence of alternatives, had to find a sub-area, within the product, that interested me and was not yet assigned to a team member.

At that time, we were at the product development phase where first users had already started to use the product. Apart from the fact that many were willing to use the system, we didn’t know the big picture of the possible defects of the product. As the system was a desktop application, we couldn’t draw correct conclusions from existing server-side logs, we, therefore, had to set up a system for collecting data on clients, and visualizing and making this data transparent (testing in production). My suggestion met with broad consensus, and my peers considered its implementation necessary, so I started working on it after receiving the authorization from the PO.

Naturally, there were a number of hitches, because I had to convince many of my co-workers and the management of the need for change. Not all of my peers backed the change at first, as it challenged the status quo, but as we wanted to prove ourselves on the market as soon as possible, which required high-quality delivery, eventually, everyone agreed to put these changes into effect. We changed our testing strategy and substantially reduced release cycle time. It completely interrupted the busy schedule of my peers within the organization. Of course, this change triggered conflicts.

However, the results spoke for themselves: We managed to significantly improve the quality of the product, while delivering measurable benefits, and to deliver the product faster than ever before. After a short while, this sub-system has become important to the other members of the team, too, they, therefore, have further developed it and relied greatly on the data delivered by this sub-system in the Production phase.

Who will give you recognition for your work well done?

Companies often employ Scrum framework to make the transition to an agile methodology. The Product Owner (PO) is responsible for managing the product backlog, which is to be broken down into smaller tasks and completed by team members.

Meeting sprint goals is shared responsibility within the team. The team members jointly show, in the form of a sprint demo, what they accomplished during the sprint review meeting.

As the PO defines sprint goals, has the responsibility to create the list of backlog items, and has an essential role in the team demo, it is very important for the PO to provide feedback on each demo to the team. That’s how the team could primarily receive recognition for work well done. There is, however, a catch: The team, and not individual developers, gets the credit, but this practice does not necessarily give the proper credit to individual developers in a longer-term perspective, thus they may feel that their efforts and work are not appreciated.

The team members share the responsibility for the success of the product because they have had a shared vision, a jointly developed product, and a collective code ownership. However, in my experience, it is important for everyone to find a sub-area that is dear to their heart, they can feel responsible for and are willing to work on. The team members should openly discuss that. They should discuss in detail which sub-areas have captured their interest, and make it explicit.

A team member is interested in measuring and making product quality transparent using SonarQube? Fabulous, go ahead, the team can only gain from it. Another team member’s first concern is to implement fail-safe logging to avoid losing messages and to ensure messages can be traced? Go for it, it’s also good for everybody. The third team member is passionate about measuring how and how often users use certain functions of the application? Cool, that is also very much needed. It is important for the fourth co-worker to make the API of the system transparent? (S)he should definitely come up with and implement a good solution. Another team member is interested in a feature? The team can also gain from the continued development of the feature. Endless possibilities.

After determining jointly who is interested in which sub-area, you will, willingly or unwillingly, become the leader and credible expert of that sub-area, and your co-workers will turn to you for help in matters pertaining thereto. Because if you’re really interested in that area, you’re going to search for further information and different solutions to identified problems, to wish to develop further on upgrading your knowledge on this area, and eventually you will become an expert in that field. I believe that if a problem area or field is very important to you and you’re working in an open working environment, you’re going to find ways to convince others of the relevance of the given area. You have great enthusiasm for it, want to provide assistance to others in relating matters, and wish to involve them so that they can also help you.

It’s a great opportunity for you, as it can also contribute to your self-improvement and professional development. There is a sub-area for which you feel responsible and which is of particular importance to you, so after a while, you might want to ask yourself: ‘How can I make it important for others as well?’ You cannot fully appropriate a sub-area, because you as a member of a team in a company work on a product, together with a team, which is why you have no choice but to involve your co-workers. You should consider feedback from the others on ‘your own sub-area’ and also allow others ‘on your territory’.

You should also be able to convince the PO to include the issue in your sub-area in the next sprint and to allocate time to it. (Interestingly, when something is very important to a team, there is no need to create a task, somehow it will be completed in no time… In contrast, when a team is totally unmotivated, even a clear, simple little task must be included in a sprint, which could be done in five minutes.)

Conclusion

We as software developers have the opportunity to have an impact on the world through our work. We could reach out and add value to hundreds, thousands, millions or even billions of users. It is important from time to time to meet with end users and to maintain people-to-people contacts with them, but in fact, developed software, owing to its digital nature, makes it impossible for us to enjoy their acknowledgment or recognition regularly.

However, everyone needs recognition. Receiving sincere appreciation, as long as a person takes the time to express it in person, means for me that I matter, am valuable to somebody or several somebodies, and my work is good for anything in the world.

Although we don’t work in order to receive recognition, we need it pretty badly.

In agile organizations, self-organizing teams make decisions. If team members think of themselves as one unit and have a feeling of unity, well, that makes a team good. But team members should be encouraged to assign responsibilities — after finding their own playground, a special area of competence — to them or themselves. When team members alone assume responsibilities, it will only serve their growing and improving, and, of course, they will get appraisals from their co-workers for that.

In our everyday work, we as part of a self-organizing team can expect recognition mainly from our peers. Often, not our bosses give us directions, as they rarely have the actual insight into our work, given that we often ‘organise’ our own work. We should always remember that, and help our co-workers find sub-areas that hold the promise of leading to self-improvement.

We should lead each other.

About The Author:

Shuhbham Sharma, I’m currently working as Content Manager with Adreno Technologies. I have a great passion for digital marketing and I help small and medium-sized firms to improve their online presence and grow their revenue by formulating effective digital marketing strategies for them. Apart from Digital Marketing, I have a keen interest in Entrepreneurship, Software development outsourcing, Brand Management, Tech Consultancy, etc.