Skill sets

First of all, the skill sets that really are taken into consideration, are mostly technological. Like “Sally is a java programmer, Joe is database administrator specializing on Oracle and Harry is a tester while Sophia is a UI designer”. Someone has somehow calculated how many units of each resource type project needs and thus a project team is formed.

This model doesn’t take into account what kind of personality types the specific project needs. Should we take Sally the java programmer who is not comfortable with iterating but usually produces error-free code from decent design, or Scott the java programmer who is at his best at trying different things out but doesn’t want to wait for design to be finished? Should we take Sophia the UI designer, who is considered more senior and competent on her own but is unable to work with customers or should we take Chris the UI designer who shines with customers but who often gets to argue with other team members?

Furthermore, this model completely ignores the fact that a team is more than the sum of it’s parts. A team may vastly benefit from a person who is complete junior on every technological aspect but really makes the people work as a team.

If these decisions are not made consciously, the project will most probably meet unexpected challenges in getting into working effectively.

Productivity differences

In any given resource pool you have many people with similar skill sets. Are each of them similarly productive? We have significant evidence that between two programmers there can be 20-time (the multiplier varies from 10 to as far as 50 on different studies) difference in their productivity. Do you know the productivity characteristics of each member on your resource pools?

Team is more than a group of people

By assigning project teams merely resourcing each member from their respective pools you do not get an actual team. Instead you’ll just put up a group of people who are not enjoying the empowering effects of a well-working team. A team in which every member knows each other will have productivity that is far more than the sum of its each individual member.

Teams are not something that any single person can mandate to exists: a group of people decides to work as a team or the do not. Finally, if you happen to come up with a jelling team, resource pooling often breaks each team after every project. So you’ll face the team building phase on every project. It’s not the most efficient way of working.

So what to do about it?

1)       Forget resources

The first step into the right direction is to quit speaking of people as resources. Considering people as resources proposes the usage of resource pools and ignores the notion of a well-functioning team. Instead of focusing on setting up resource pools and optimizing individual utilization we should focus on building highly efficient teams that are capable of organizing themselves at all times. Teams should be big enough to allow assigning the best person to any given task but small enough so that the number of communication channels does not overwhelm the benefits of people knowing each other.

2)      Consider organizational structure

Do you have your workforce organized by functional expertise? Project management team, UI design team and development team, database team and testing team? This grouping doesn’t encourage self-organization and introduces many possible bottlenecks to your workflow. People working together should stay together and have a common organizatory goal.

3)      Let teams build themselves

A jelling team can typically consist of 10 or less people. Bigger than that and the communication channels get far too many and the diversity of the persons get in the way of efficient collaboration. You may have organization units that are bigger, but inside units you may have more teams. If you as a unit manager see some people getting along especially well, why not letting them work together as a team?

4)      Emphasize specializing generalists, not pure specialists

Each person who has strictly limited expertise is a bottleneck to productivity. Specialists need a well-defined role, they need a project that can use a specialist of his profession. When your people are capable, and willing, to act on a multitude of roles, your staffing problems get a lot easier.

A group of specialists can make – and usually do – products in which any given area is crafted well, but the product as a whole doesn’t work at all. To make anything remarkable you need a group of people who understand what others are doing, people who understand the product as a whole.

Surely you need the specializing part, too. A group of pure generalists will surely do something that works somehow, but it won’t shine on any aspect. The optimal situation is having a team full of generalists, each of which could carry any role in the project, but where each has her own specialty on top of good general knowledge.

=>  Sami’s first law of productivity: Productivity is directly proportional to the amount of overlap in team members’ skill-area / expertise-level –space.

But there are sub-stories also. In physics we have had Newtonian and Einsteinian stories, and these stories constantly change. In this post I urge you to think what are your stories of software development. There are at least three different types of stories that define you as a software developer.

What is software development at very high level -story

In the last decades of software development we have not been in lack of paradigms to choose from. Many have come, many have gone. And I agree, we still are trapped in nonfunctional paradigms. Here are a few different paradigms that Alistair Cockburn pointed out:

Of course, these are a bit philosophical paradigms from methodologists and as such do not define very strictly how you will behave in every situation. But it is a foundation on top of which the other stories build. Do you have a different metaphor for software development that describes your style better? Let me know!

What is a software project –story

This is the type of story that has caused most process wars, manifestos to be written, different schools of thought to be born and continuous flux on the science side.

Educated 90´s software development

Perhaps the most common story is what was teached at school in the 90´s, being a mixture of Meyer´s engineering, Humphrey´s discipline and Jacobson´s model building. This most often resulted in the traditional waterfall-development in which each activity is carried out sequentially by specialists of each phase.

This story encourages for big, upfront design, comprehensive documentation and project management as a separate task. And testing postponed to the end of the project.

Software project is a collaborative game

In many parts, this is the original way of writing software – that is doing an reincarnation in the names of lighter-weight methodologies. You basically take a cross-functional team (preferably small) of people and trust them to get the job done. This philosophy is behind the many agile methods that coming with varying set of practices, principles and rules on the game.

Usually this story comes with iterations, incremental development, continuous integration, behavior driven design and test driven development etc.

Alistair Cockburn has even composed a manifesto for this style:

“Software development is a (series of) cooperative game(s), in which people use markers and props to inform, remind and inspire themselves and each other in getting to the next move in the game. The endpoint of the game is an operating software system; the residue of the game is a set of markers to inform and assist the players of the next game. The next game is the alteration or replacement of the system, or creation of a neighboring system.”

Cowboys on the desert

In practice, many software teams are not willing – or capable of – carrying out monstrous project framework and processes that 90´s style requires. Further, they do not have the discipline neither responsibility that collaborative game needs. Instead they work like cowboys on an unknown land: without any idea where to go, they take each confronting sack, changing direction continuously and ultimately ending somewhere leaving a disastrous mess behind.

In software terms this means that there is a bunch of individuals who are not collaborating fluently, requirements drop unexpectedly from customer and there´s virtually no communication between the customer and developing team except what is absolutely required to hand off the requirements and at the end, deploying some piece of somehow working software.

Requirements change wildly and they are implemented right away without thinking the architecture and keeping the code clean.

Systems thinking

Some go as far as saying you should not have projects at all, but think development artifacts as products. Usually projects have up-front funding, scope fixed at the beginning and success is measured in terms of meeting the scope in given time at given cost. What´s worse, the team is often disbanded and each member goes on to new projects. A new team will step in and take care of the maintenance.

Alternatively, in systems thinking the development is funded incrementally, scope is expected to evolve along the way and success is measured in terms of market share and profitability. The same development team often stays with product.

What am I as a developer –story

Finally, after each person´s beliefs about development in general and reckoning about projects (or products) each still has a different attitude towards his work

Stonecutters, living earners and cathedral builders

There´s is a great story about three stonecutters in Kitchen Table Wisdom.

It’s a story offered by psychologist Roberto Assagioli, who tells of a man who goes to interview three stonecutters engaged in building a very large cathedral. When he asks the first stonecutter what he is doing, the man bitterly replies that he is cutting stones into blocks, a foot by a foot by three quarters of a foot. With frustration, he describes a life in which he has done this over and over, and expects to continue to do so until he dies.

The second stonecutter also says that he is cutting stones into blocks, a foot by a foot by three quarters of a foot, but he adds an important piece. He lets the man know that he is earning a living for his family; through his work his children will have clothes to keep them warm and food for them to grow strong, and that he and his wife will be able to maintain their home, which they built with so much love.

But it is the third man’s response that astounds the interviewer. In an enthusiastic voice, he tells the man how joyous and grateful he is to have the privilege of building a great cathedral, so strong that it will stand as a holy beacon for a thousand years.

http://clf.uua.org/quest/2008/12/janamanchi.html

Are you just typing some freakin´ code, putting up darned CSS styles, <put here your current day-to-day activity> or are you part of  team who is building an exciting new product? Or are you just doing whatever you´re told to do so that you can feed your kids? When you are annoyed by your job what do you do? Complain about it? Ignore it? Fix the problem?

Technology lovers, tool blamers and superheroes

Besides the overall attitude to your work there are some characterizing ministories that you may have absorbed.

Are you a superhero that often works night´n´days, sacrificing your own life because “it´s the only way to save the project”. Do you think the other people on your team are inferior and you are the only competent guy?

Or do you think that you and your team are perfectly competent and suitable for the project – except that the tools are always wrong. Be it the operating system, version control software, time-tracking software, internet browser… You are doing your job perfectly but the tool just prevents you to be productive. And there is nothing you can do about it.

You may also have fallen in love with technology. Be it all the new technology in general or any given brand that has dazzled you. Anything you think is from the point of view of the newest technology.

Different types of developers

Alex Love has written a nice overview of different types of developers. Do you recognize one of the types to describe yourself?

Afterthoughts

While it may be hard to find a single story that works for you all the times, it´s important to understand your own way of thinking. Equally important is to understand the stories that your team mates carry with them. Conscious team leaders make up teams that consist of people with compatible inner stories.

Have you noticed different types of stories that define software developers? Feedback is welcome!

During the 50 years of software development we have seen a plethora of software development methods. Every ten years comes a new methodology, a new solution, to the same old problems we have been fighting for the whole 50 years. And will be fighting, dare I say, the next 50 years. One weapon used in the war is development methodologies. But what really is the essence of a methodology?

A lone coder

Imagine you are developing software alone for yourself. You know perfectly well, WHAT it is you want to achieve. You are effectively a business analyst. Also, you alone specify HOW you are going to implement the software. Naturally you write the code and test the solution yourself.

I bet anyone who has wrote any non-trivial software for himself, did find some opportunities to make the software better than originally thought. When you work alone it’s usually not a problem, you change your mind and are happy with that.

You don’t need much ceremony for this to work.

Enter external client

Things get a lot more difficult when another person comes into the game. Especially if the other guy is your client who is going to tell you WHAT to do.

When two or more people work together (you are working together, aren’t you?) they need a way to coordinate their work, share knowledge and find a way to make decisions.

This comes extremely important when you need to agree on WHAT to build.

Bigger team, more roles

Usually as one person turns to an organization and projects grow bigger, more roles become involved in the game. Most often first person to enter is an hybrid of project manager and analyst taking care of the client and telling the developer WHAT to do. What effectively occurs, is more loss of information (according to many studies ca. 50% of information gets lost on a handoff).

Next people to come into an project are architects, designers (telling developer HOW to do) and testers (trying to validate whether the developers did what the analyst told them to do, no matter is it what the client wants, no matter was it done how designer thought). More coders. More clients with conflicting ideas on WHAT to do. More problems. Many methodologies have been born to solve these questions, many theories about teamwork have existed many decades, so we are perfectly suited for a successful project?

Each new person presents new demands for the development methodology.

And the ultimate question is…

So now we have a team of people (without going into discussion on what is the essence of a team) consisting of many specialists perfectly suited to do their own craft. And the team has a client who has a business process to be improved using software. The only remaining problem is that the team should produce what the client needs. And it needs answering the ultimate question WHY. Why is the software being developed? Why is client asking for what she asks? Why is designer proposing a given solution?

To answer that question (and also to further specify the WHAT) business processes are modeled and various diagrams are drawn.

The problem

Developers have their own methods, business has it’s own methods and IT operations has it’s own methods. Unluckily, there’s very little common ground between the different stakeholders. There are huge gaps between the different sides. And after a few thoughts, we find that our specialists-driven team has also many gaps: designer doesn’t understand what each decision means development-wise, developer doesn’t understand the UI designer etc.

We need something to help us bridge the gap or even better, remove them totally.

The solution

Each project has it’s very own characteristics: it has a unique combination of skills, unique value definitions, unique scheduling, unique state of the world and – what’s most important – unique human beings. This means that the project needs to find a way to work effectively together under these unique circumstances.

I have written before on cross-functional teams. But it doesn’t stop on the software development team. We need a cross-functional business development team. Most software is written because of business change, and as business changes continuously, so do software.

For any project to succeed it needs all the stakeholders speaking the same language, sharing objectives, collaboration, building trust and enabling business agility. Real methodologies always try to find practices that bridge the gaps between end users and client, between client and analyst, between members of development team etc.

“The essence of Lean is thinking in context” someone said. I couldn’t agree more. Thinking in context is the very essence of software development. We have come too far in determining readymade methodologies. Think in context, define your own methodology for your project and bridge the gaps.

Afterthought

A football team consists of highly trained specialists. They have goalkeeper, defensemen, middle-field and the forwards. Each one is focusing primarily on his role. What is the difference between a football team and a typical software development team? Each member on a football team know how to play football! Every single player can kick the ball, they know the strategy, the are able to serve the ball, they know how to tackle the opponent etc.

Typically on a software development team you find testers who can’t write code, you have designers who can’t write code, you have coders who know nothing about user interfaces (or even the users…). Why is that?