Official Blog

Project fiascos usually have managerial consequences, and it was only a matter of time before the ripples from the great computer revolution produced a metamorphosis in the way large and complex IT projects are managed.

Luckily for us, this happened well before we were born.

That was back in a time when computers were the size of a truck. Beasts such as Univac and IBM 700s or on the other side a URAL-2 computer from the Soviet Union.

The invention of computers was closely followed by its Siamese twin: IT project failures. The history of information science is littered with such examples.  

Back in the fifties and sixties line managers would perform the work required by his line organization and then throw the “ball” over the fence hoping that someone from IT development would catch it. Once thrown over the fence the line manager would wash his hands off any responsibility. In case something went wrong because the ball was no longer in his yard. The IT people claimed that the requirements were subpar and threw the ball back. However, the real problem with this approach was that the actual customer had no single contact for their questions.  

This debate generated some notable books. One I like particularly is Fred Brooks’ “The Mythical Man-Month: Essays on Software Engineering”. It is based on his experiences at managing the IBM OS/360 project.  

Back in the nineties a couple of people started to look over the fence to Japanese product engineering and software development techniques. One such technique is called Sashimi. Out of this technique grew Scrum.

The basic issue with the traditional waterfall models of project management is their focus on quality and low cost. The scrum inventors realized that software projects need in addition speed and flexibility. And they observed that there are people actually doing the project work and there are others with a more casual interest in the project’s outcome:

A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed, but you'd only be involved." (Quelle)

The “pigs” are committed to building the software, while everyone else – “chickens” – is just interested but sort of indifferent to the outcome – they never committed themselves fully. This distinction plus the particular agile setup of the methodology are the distinctive marks of Scrum. Today a growing body of evidence suggests that agile methods greatly improve software quality and project success rates.

At local.ch we were using agile methods, building the platform in release cycles of about 4 weeks. Over time some teams started to use Scrum. At Nektoon we set out to apply Scrum fully right from the start.

How do we do it?

First we fixed late last year the strategic goals for 2009. These goals have been broken down into a roadmap for the year. Example: We fixed last year the goal of a beta release late spring. Today we’re one two-week sprint off this goal.

The next level is our product backlog. Here we write down the big tasks. We refer to them as stories. For each story we award a point on a scale from 1 to 5 as an indication of its complexity and difficulty.

Every other Monday morning we sit together and sort through this product backlog. First we prioritize and then in a second step we pick the stories for our next two-week sprint. In turn each story will be split into tasks. For each task we allocate an estimate on the number of hours required for completion. Then we go and work.

Important: We decided to do this not just for engineering stories but for business stories, too. Example: For marketing purposes we currently are producing a brief video clip. Thus we created a story “Video Clip”. This story and associated tasks are part of the current sprint.

Then there is the issue of controlling: Every morning we sit together and quickly go through three questions: What did I do yesterday, what will I do today, is there anything blocking me? To update everybody we create a status update in our Wiki (More on that in the next blog post).

At the end of each sprint we go through each story, demo the developed features or present the business related stories. This is important to get a feedback on overall progress.

You might say for a startup with just five people on its payroll, this is a bit too much. We think it isn’t. The pace and rhythm we set now for our company will be the pace and rhythm of our company in the future. We try to achieve a couple of simple things with this approach:

• Good visibility on what we work on right now and its specific contribution to the overall goal
• Equip our team with the tools necessary for success
• A clear system of communication
• And a clear focus on our primary goal

Next in the series how to build a scalable startup: Abolish MS Office.

Most smaller and larger organizations are stuffed with folks holding the title “project manager”. For starters: These jobs are probably the most essential jobs any company has. If your engineers aren’t good, you sure have erroneous code, but persistence will fix the issues. If your marketing folks aren’t good you sure will have a difficult time getting the message out, but a bit of external help will make up leeway. If management is no good, the board hopefully fixes this issue quickly. Yet if a project manager fails you’re in deep trouble. Why? She’s the one that holds together the strings of a project (1). If she’s good, things – aka projects – just happen. In case he holds the strings together poorly, the project will most likely end up an utter failure.

Yet, most organizations have way too many project managers on their payroll doing way too many futile things. This report, that chart, lots of meetings, more E-Mail. Their bottom line contribution: Zero, worse, probably negative.

Why? Let me explain.

Most organizations are led by business people (as opposed to engineers). Both groups tend to mingle mostly among like-minded people. It’s simply easier to find a common language. As a consequence business people tend to hire business people, i.e. ‘project managers’. And as most organizations have always lots of things to accomplish (not least to satisfy the egos of some higher ups), a lot of project managers get hired.

The outcome: an oversupply of project management folks. At the same time the number of engineers stays mostly the same (You know, focus on costs and headcount and all that…).

The result is an oversupply of project management resources compared to engineering resources. The following figure illustrates this point: disk A denotes the available project management resources. These generate a equally sized demand for engineering resources (this being the maximum load this project manager team is able to handle in terms of projects, tasks and workloads). Disk B represents the available engineering resources.

The effect is a significant oversupply of A versus B. In a market economy there are two possible solutions to this imbalance. Price and or quantities available in the market space will adapt until the market clears.

Unfortunately this is not the free market but the rather closed compound of a firm. So what will happen?

Each project manager has been given a specific set of goals. Yet the available engineering resources will not match the combined demand by all project mangers. The consequence is fierce political infighting over scarce resources (2). People start to focus on internal politics instead of external product value for your customer.

First observation: Too many project managers ensure internal feuding instead of external customer focus.

We tried to avoid such a situation at local.ch. We basically never employed a project manager. How did we do it

• In a team of 32 (3) of which 22 were engineers, we had two engineering directors. Their task was to ensure a smooth engineering operation. On the one hand they were the prime interlocutors for the business people with their requirements. Second, they were responsible for the overall engineering direction. This did involve only a minimal part of day-to-day project management.  
• As outlined in the previous post, we split the local.ch platform into several building blocks and assigned a team and team lead to each block (we had a frontend, a backend, a classifieds, a guide, a mobile, a mapping, a product, a sysadmin team, though a couple of people were in several teams).
• Each team was responsible for its own objectives, tasks and their timely execution. Each team was tasked to ensure that its individual plans would not collide with the plans of adjacent teams and their respective release plans.  
• We met every Thursday to commonly elaborate and agree the main release goals. We started with a general update on the progress of the entire platform, followed by a coordination meeting attended by all team leads plus whoever had an issue to raise. Once this overall release plan was agreed to, we delegated everything else to the teams. We tried hard to limit these Thursday discussions to the most top level items only, delegating all subsequent detail discussions and decision making to the parties directly involved. When I say “tried hard”: we tried to stay focused, but sometimes fell short (4). But who doesn’t occasionally?
• We relied extensively on agile development methods. More on that in the next post.

The result – with all shortcomings – were very dedicated teams. They rose to their responsibilities and started to own the issues. They took pride in getting things done quickly, efficiently and effectively without much management. Things just happened. And they happened quickly: In the frontend team we were on nearly a daily release cycles, in the backend team they were not far behind.

Second observation: true responsibility is a powerful motivator.

The basic recipe is a transparent split of building blocks and assigned responsibilities. Plus maximum delegation of decision-making combined with a set a set of simple and commonly shared ground rules. And then get out of the way and let excellent people do their job.

Next in the series how to build a scalable startup: Scrum.

_______ 

(1) For proponents of the Spider versus Starfish theme: Even a pretty self-organizing team, will need some time to re-calibrate if you take out the team leader.  

(2) There is another solution though: Reduce the number of project managers up to below available engineering resources. But then again, who wants to cut those project roadmaps to size?

(3) Of these 35 colleagues, 25 were on the local.ch payroll, long-term partner companies employed 7.

(4) For readers from local.ch and friends: I know, we all did live up to this better pre-Amundsen. For all other readers: Contact me for details.