In my career, I had the chance to change teams, work through different processes multiple times, and experience some pain on the topic of team working.

Although some of these processes and teams claimed to be agile-oriented and with a certain kind of established processes, not all of them were successful in the basic goal of consistently delivering value to their stakeholders.

Some teams were inducing a degree of frustration in their members which led many times to problems in the code and made the working days just unbearable.

So I wanted to start a mini-series of posts on what I learned so far about “How to team” and how I think a software development team should look.

It takes care of itself

This team takes care of itself without expecting someone else external to do that.

This team values its independence and improves its way of working autonomously by using ingenuity and any other necessary instrument.

Such a team needs to have continuous, honest communication on what is important for its members and to be ready to let go the rest.

Some of the blocks that prevent a team from taking care of itself

• Keeping the client and its feedback far from the team slows down the self-improvement cycle
• Having external team management trying to control the teams’ activity
• Periodically splitting the team in order to distribute knowledge
• Imposing tools and practices because “that’s the way”

It’s honest with its clients/stakeholders and values their trust

Delivering consistently, reliably and taking care of its artifacts is the currency that the team spends for buying the client’s trust.

This also means that the team doesn’t commit to or promise something that cannot be realistically delivered, might be a date or a long-term plan, in order to not create expectations that cannot be maintained.

This team establishes a contract with its clients. It defines how to work with it, how to make requests, how to review its job, and so on.

It doesn’t have to hide its progress or be ashamed of its mistakes.

It’s a team that is open to observation but closed to influences that might damage the effectiveness of its process

What makes this difficult

• Not knowing the team’s velocity because it’s the only way to not under and overcommit.
• Accepting external estimates, delivery dates, or roadmaps
• Having team’s management that doesn’t consult with the team itself

Cares for its artifacts

This team considers quality as something important to every and each of its artifacts.

It establishes for itself which parts require more attention and when the quality is satisfying.

It tries to expose its artifacts to the client as soon as possible and receives and considers feedback in the same fashion.

It’s a team that tackles the creative process frustration and sharpens the tools of its art for preventing it

When this doesn’t happen

• When the team shares its workspace/codebase with too many different teams/individuals, which could bring a lack of sense of ownership.
• When the team doesn’t take ownership of the delivery.
• If the team is not considered responsible for the artifacts’ maintenance.
• The team is rushed towards delivery and is not trusted in its estimations

These, in my opinion, are the essentials on which everything could be built.

I’m aware that some of these points are quite general and could fit or be against potentially any situation.

I’ll come to something more pragmatic in a later post: “Team Smells”

Let me know your opinion in the comments (you need to accept the cookies in order to display the comments section) or in any other way you would like to share it.