Recognised roles

Any project needs all sorts of expertise. In the picture 1 I have illustrated a typical, yet simple, scenario where the project needs some management, architecture, user interface design, development and it operations. The easiest and arguably most common solution is to assign one or more people into each expertise.

Person per role

This seems obvious: if we have a work to do, we need a person to do it. But this leads to problems well known: people are not collaborating effectively, they have their own silos, most of the decisions need to be done upfront which leads to waterfallish development no matter what your official methodology is. Most challenges in real world have cross-cutting concerns. Solving any such problem needs broad understanding of many aspects and in this setup this means you need many people work together. Collaboration is not bad in itself, but when you have two specialists who don’t understand each other’s expertise, it is not as efficient as it should be.

The solution to this problem has been examined before (see for example my problems in current resourcing). But as I see this one of the major hurdles to efficient (dare I say, agile?) development and I don’t see it being handled properly I need to keep refreshing on it. So, what we should aim for?

Person per gap between role: 10 required

Instead of using simple “person(s) per expertise” -method, we should probably use “minimal number of people that is enough to fill all the gaps between silos” –method. First you need to identify all the expertise areas that are needed to accomplish the desired end result. Then you need to find such persons that fulfill every gap between any two expertise areas. In our example, we had identified the five expertise areas so we have 10 gaps to fulfill.

Again, each of these gaps does not directly map into one person. Soon it becomes evident that if each team member only has one or two areas she is comfortable working in, you have a problem. Should each member have only two areas of competence, you’d really need 10 people. But, if even one of them possesses three different skills, the number of required people counts down to 8. If you have one “superstar” that is competent in four areas, you need only two people to fulfill every gap.

Persons with overlapping skills: only 3 required!

In any real-life project you have probably more than just 5 types of expertise needed: concept design, usability design, graphic design, requirements gathering, database programming, UI programming, testing, it operations, mathematical analysis, domain-specific knowledge etc. And as we know, the more people there are in the project, the more demanding the communication. And communication happens to be one of the most important aspects of any project, especially one of software deveopment (see: software development as a cooperative game). This reminds us about the importance of multi-competence.

So as a summary, the suggested method to project staffing is:

• identify the required expertise areas
• find the least amount of people that cover all the required areas
• if you need more firepower into any area, only then can you add a specialist

=> Sami’s rule of project staffing: Build the project on top of generalists, only add specialists if needed.

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!

The most important thing that customers expect from the sales of their it-partner is the understanding of customer’s business. They want to be treated well and salesmen should be active. Customers are usually willing to listen the opinions of it-suppliers. The biggest expenses usually come from massive customizations that are often done to fulfill all the listed requirements from customers’ side. But most often these are not absolutely necessary. Suppliers should be interested in knowing what are the real needs of customers – and how they can be reached with minimum cost.

In the long run customers want that their supplier can fulfill their contemporary requirements. You should always solve the today’s problem, not tomorrows. And the solutions of today should always scale both up and down according to changes in customers’ business.

One of the biggest problem (from the customers’ side) it-suppliers have is their lack of decent account management. A good account manager is not a salesman, but a person that understands customer’s business and problems thoroughly and is able to suggest solutions. Add to that the fact that usually sales and supply organizations are separate, it’s no wonder that suppliers most often supply solutions that the customers are not satisfied with.

A surprising fact was to hear that now that the economy is low, the actual quality of sales work has lowered significantly! That is wrong direction: when the are less customers and less cases to compete on, suppliers should especially concentrate on the quality of their sales.

For real partnership to break out, suppliers must commit to improve customer’s operation. Suppliers must be willing to take some responsibility from the results.

There’s no free lunch

Of course, these services are not free and are often the first things to cut when customers want to lower prices. Way too often new projects are tendered and the lowest bidder gets chosen. And after one supplier gets chosen, usually it has only one incentive: to maximize the profits from the project.

So what eventually happens is that the supplier cannot enjoy the long-term profits from whole lifecycle and the customer suffers from inferior service. One could say: you get what you pay for. Real partnership is always most profiting to supplier and best serving method to customer. Why is it so hard to form real partnership these days? Toyota found it out on 70′s that it is most useful to count on real partnership instead of tendering all the suppliers every year.