Month: August 2017

 

 

If two are better than one, a small team is better than two then a big team is definitely better than a small one. No?

Intuitively it seems that the more people you have, the better.

For a software team, this is just not true and not because they are mostly introverts.

In the entry, what to consider when growing a software team, I hinted you should consider limiting your team size.

In this entry, I define a big team as one having more than 10 members. These kinds of teams come with their own set of challenges.

Communication over head

Have you ever tried to organize an unscheduled all hands meeting?

Getting schedules to match is almost impossible even with oversight into what is going on in the entire organization.

Now imagine an individual developer trying to get her blockers worked on in a 10+ person team!

What ends up happening is she spends most her time communicating with other people trying to get work done instead of you know, getting the actual work done!

This is not the perfect picture of effectiveness.

Individual effort lags

Maybe it’s because people feel less attached to others in big teams I am not sure. What is certain is less work gets done per person in teams.

It is natural to assume that someone else will do the work. In small teams, this assumption comes into sharp contrast. If you are not doing the work then who is?

Sluggish behaviour is likely to be more quickly noticed by the rest of the team.

As the Poppendiecks say:

Peer pressure is far more effective than the concept of a boss and much more powerful

In big teams, no one has the cranial capacity to keep up with what everyone else is doing so they just assume they are slacking off and do the same themselves.

Collective ownership goes down the drain

Just as there is individual skill, I believe there are also team skills which need to be nurtured.

When teams are large, the production line becomes the most effective way to organize work.

This is fine if your work can be broken down into small sub tasks which can be easily tested for completion.

Software projects are the antithesis of such work. To be successful it’s critical that all team members have a shared mental model of the product they are building and have a clear understanding of its value to the customer.

The negative effects of hand over will get to you before any Taylorian benefits flow.

There is no direct line between team and individual success

We are all the centre of our own universe. If I have pulled off several all nighters on a project (I don’t recommend this) then I want to see myself acknowledged when the product is launched or another similar success event happens.

If my individual effort will never be recognised anyway, then why bother putting in more effort than is expected?

In small teams, what each individual did can be clearly seen in the work output. This makes the work personal and meaningful with the effect that everyone is now more committed to it.

How big are the teams in your own organization? Talk to me in the comment section below or on my twitter @jchex

 

 

 

Recently, we were sharing our experiences with my friend. He mentioned a statement his boss used to tell him when he worked at craft silicon.

I would rather hire three average developers than one rockstar developer. Within six months they will have delivered more.

Obviously, this rings true to my team orientated mind.

Yet such delivery does not just happen automatically. In the same way, individuals need to learn, so do teams.

Anita et al describe why some teams are smarter than others

In this entry, I will be looking at what you can do to stimulate learning in your own developer teams.

Break down communication barriers

As companies grow, the amount of paper work grows as well. This is not necessarily a bad thing, it implies the organization is codifying its knowledge thereby reducing rework.

For example, if you are hiring 8 – 10 developers every month it probably makes a lot of sense to have the on boarding process in a document.

The problem comes when communication happens primarily via documents.

The key here is to challenge yourself not to create a policy every time something goes wrong. Policies are only useful when the situation reoccurs many times within the course of your business.

You maybe intimately aware of agile’s face to face communication principle, yet the allure of beautifully detailed dashboard is guaranteed to get to any manager.

Don’t get carried away, there is such a thing as, over collaboration, constant communication also disrupts creative work.

If you do manage to hit the balance between process and communication the next biggest challenge is to ensure the team is kept intact and members are learning each other’s vocabulary

Build whole team responsibility

I find it surprising some people deliberately pigeonhole themselves with meaningless titles; “PHP developer”, “Python developer” etc. Of what use is your language to the business?

Clients care about having their problems solved. This means everyone in the team is a problem solver first then whatever other titles they chose.

In this mindset, everyone owns the outcome, not just the tasks they are working on. This means if as an individual you do everything right but the project still failed, then you also failed!

The more everyone has been involved in everything the more responsibility they will feel towards its success.

Lynda Gratton puts it as:

    working with other people was never more exciting and exhilarating and when you knew deep in your heart that what you were jointly achieving was important and purposeful

Capture useful knowledge

Let’s start with some timeless advice from Seneca

It is the mind which is tranquil and free from care which can roam through all the stages of its life: the minds of the preoccupied, as if harnessed in a yoke, cannot turn round and look behind them. So their lives vanish into an abyss; and just as it is no use pouring any amount of liquid into a container without a bottom to catch and hold it, so it does not matter how much time we are given if there is nowhere for it to settle; it escapes through the cracks and holes of the mind.

Here he was referring to the people who waste their time. But I feel it equally applies to those who waste their experience.

Whenever you work on a project, there is always something new to learn. Maybe you just figured out the lighting in meeting room A does not allow for easy projection. How do you capture this knowledge? How do you ensure no one else does a client demo in that room? If you encounter a rare bug in one of your core libraries, what do you do about it?

Reconciliation is a useful concept in this regard. Whenever you are done with a sprint, a project or even a day. Consider what did you expect to happen vs what actually happened.

How do you foster team learning in your own organization?  Talk to me in the comment section below or on my twitter @jchex