The problem of being proud

“What are you really proud of?” asked the trainer the other day in a resilience seminar I attended. The room with the participant suddenly became quiet. Many seminar participants had obvious problems with the word “pride”. I recently experienced something similar in a coaching session. The coachee reported what he was proud of – only to take it back again right away. “You don’t say proud,” he muttered apologetically.

“I am proud to be a German” is what many spontaneously associate with the word “proud”. In connection with this saying, which is well known from the (Neo-) Nazi era, pride has a rather bad image. But in other cultures, too, pride tends to have a negative connotation. In Buddhism, for example, it is called “disturbance” and is mainly associated with material striving and immobility.¹

Why is it actually so “out” to be proud of something? And I don’t mean proud in the sense of “I am proud of my beautiful blue eyes” (which would be a lie anyway, because my eyes are not blue at all), but proud of something that you have achieved yourself and done well.

The two sides of being proud

It is a real pity that proud has such a bad lobby. Because, as the Duden writes, being proud does not necessarily mean being “arrogant and dismissive in your self-confidence”, but also that someone is “filled with self-confidence and joy over (…) an [own] achievement”.²

And pride in one’s own performance is immensely important. Not only when it comes to personal development, but also when it comes to the development of teams. Pride in something we have achieved and accomplished ourselves enables us to look more positively into the future. Because those who are aware that they have achieved great things in the past will also be able to face future challenges more courageously. And this brings us back to the keyword mentioned at the beginning: “resilience”. Who wouldn’t wish for a resilient team today? A team that is proud of its own performance and able to quickly regain its energy even after setbacks.

A team on the brink of depression

I would like to tell you a little story about this. Once upon a time, there was a software development team that had been working on an individual software for a large customer for some time. A so-called “green field project”. Recently, an important milestone was reached and the team received permission from the customer to continue developing the software. Actually the team could be proud of itself and what it has achieved …

… but if you look at it honestly, the milestone was only reached by hanging and choking. The fact that the customer even accepted this poor work status, with all the bugs in the software. Although many bugs have already been fixed, the number of bug tickets is still increasing. The developers don’t seem to be working really well, otherwise the number of bugs would actually have to decrease. But this is probably also due to the technology chosen, which is always putting a spoke in everyone’s wheel. Not to mention the “crashed” software architecture …

Pride helps out of the valley of mourning

How do you feel after reading the last paragraph? Do you also feel the despondency that speaks from these lines? And – attention, rhetorical question – do you believe that a team is still capable of great achievements in this deprivi-mode? – Of course not!

The team could see the whole situation differently. It could be proud that after months of hard work with lots of overtime and a few weekend shifts, it has reached the milestone. Proud that everyone worked so well together to achieve this goal. To be happy about the bugs that have been fixed and to acknowledge that there will always be more work than it can do and that there is simply no such thing as completely bug-free software. And to be proud that on the intimidating “green field” it has even managed to commit to a technology and have something like a recognisable (and to most team members familiar) software architecture.

There is always room for improvement, of course. And it is also important to identify improvement opportunities. But it is just as important to draw the energy from the positive appreciation of what has been achieved to tackle the improvements. If this does not happen, the team will eventually become anxious and stop moving. According to the motto “We have already messed up so much in the past, we’d rather stop trying to build anything at all”. The team no longer dares to do anything, its self-worth is at rock bottom.

Positive retrospectives with the little starfish

But even if a team is made up of convinced pessimists and cynics, it can get a more sympathetic view of its own work. For example by changing the format for sprint retrospectives.

In a team, we had previously always carried out the retrospective with the format “Mad, glad, sad”. In this format, slips of paper are assigned to one of three categories. In the first category “Mad”, the team members hang the notes with points that the team is really angry about. In the second category “Glad”, the things they were really happy about are placed. And in the “Sad” category, at the end, the team members hang the notes with points that have made the team sad.

One day there were hardly any notes in the “Glad” category in the retrospective. The presentation of the slips of paper became a real “vomiting round”. Positive energy: zero. And even if the common moaning is sometimes good, I decided to try a different format in the next retrospective.

We did the next retrospective with the Small Starfish format. We used three categories: “Start” for things that the team wants to start and try out, “Stop” for things that should not be done anymore, and “Continue” for everything that went well in the last sprint and should definitely be kept. Amazing what this actually small change did to the energy in the team. Suddenly many team members made constructive suggestions for improvements and praised the team’s performance! A bunch of “whiners” had suddenly turned into an independent team that was proud of its own work and wanted to take its fate into its own hands!

Burnup charts instead of burnout

In addition to a carefully chosen retrospective format, visualisations are another way to get a more positive view of the work done. The classic here is of course the Kanban Board, where development tickets move from the “To do” column to the “Done” column during the sprint. If at the end of the sprint many or maybe even all tickets are on the Kanban Board on the far right, that’s a good reason to be proud! Many teams use electronic Kanban boards, which is of course an advantage when teams are distributed. However, if the whole team is in the same place, a physical board is recommended. The haptic experience of dragging the board into the “done” column makes it even more conscious of what has been achieved.

Another and perhaps not so well-known way of making progress visible to the team is the so-called Burnup Chart. This chart puts the number of planned features / user stories in relation to the completed features / user stories and shows this relation over time. If such a chart is created and made centrally available, everyone can immediately see how the amount of software functionality is continuously growing.

Visualise the continuous growth in user stories

Comparison with oneself instead of with others

And if all this doesn’t work? Then it can help the team to consistently not compare themselves with others, but only with themselves. To simplify this, a “project diary” or “team chronicle” can be created. Then it is easier to remember together how it was, for example, at the start of the project: “Do you remember how we argued for weeks on end about how we should technically cut the software? Or how we couldn’t decide whether we should use technology A or B and even the external consultant didn’t know what to do?

The important thing is that the team appreciates their own learning progress in the project. The team can be proud if it has learned things it could not or did not know before. Whether it’s getting used to a new development tool, implementing a new design concept or simply realising that the chosen architectural approach does have some weaknesses and that it should be done a little differently next time.

And together they can look positively on the fact that, despite major start-up difficulties and adverse circumstances, they have perhaps been able to develop many functionalities that support users in their daily work.

Conclusion

Anyone who is proud of his or her own performance and development – whether as an individual or as a whole team – does not necessarily have to be arrogant and talk himself/herself into a good light, but usually has a positive self-image. And it is precisely this positive self-image that enables us to approach future tasks with confidence. This is a skill that should not be underestimated in today’s challenging (software project) world. In the best case scenario, colleagues will say to each other at the end of the day “I am proud to be a member of this team”.

Notes (in German):

[1] https://www.diamantweg-buddhismus.de/
[2] https://www.duden.de/rechtschreibung/stolz#Bedeutung1a

Kathrin Herrmann has published additional posts in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.