Environment for Agile Teams

How to create an environment that

supports agility
Andy Brandt
This book is for sale at
http://leanpub.com/environment_for_agile_teams
This version was published on 2014-06-02

This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean
Publishing is the act of publishing an in-progress ebook
using lightweight tools and many iterations to get reader
feedback, pivot until you have the right book and build
traction once you do.
2010-2014 Andy Brandt

Tweet This Book!

Please help Andy Brandt by spreading the word about this
book on Twitter!
The suggested tweet for this book is:
Just downloaded The Environment for Agile Teams by
@andybrandt
The suggested hashtag for this book is #agileenv.
Find out what other people are saying about the book by
clicking on this link to search for this hashtag on Twitter:
https://twitter.com/search?q=#agileenv

Contents
Introduction . . . . . . . . . . . . . . . . . . . . .

1 Principles . . . . . . . . . . . . . . . . . . . . .

2 Physical environment . . . . . .
2.1 Team spaces (war rooms)
2.2 The managers rooms . . .
2.3 Other useful areas . . . . .
Meeting rooms . . . . . . .
Kitchens . . . . . . . . . . .
Nap-Points . . . . . . . . . .
Silent Room . . . . . . . . .
Library . . . . . . . . . . . .
Toilets . . . . . . . . . . . .
Smoking place . . . . . . . .
2.4 Access to the office . . . . .
2.5 Final caveat . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

5
5
13
14
14
15
17
18
19
20
21
21
22

3 Management . . . . . . . . . . . . . . . . . . .
3.1 Advice for the manager . . . . . . . . . .

24
25

CONTENTS

General . . . . . . . . . .
Metrics, bonuses etc. . . .
Organization and structure
Hiring . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

25
30
38
45

Planned extensions . . . . . . . . . . . . . . . . .

48

About the author . . . . . . . . . . . . . . . . . .

49

Introduction
A lot has been said and written about how agile teams
should work. There is the Agile Manifesto outlining the
principles, there are various methods & methodologies
dealing with both the technical practices and the overall
process (like Scrum). And of course there is a growing
number of books - and an even faster growing number
of websites - on how to apply all those methods in different situations, contexts, industries even. Most of this
advice is either focused on the level of one team or on
the process itself. Right now the problem of scaling the
agile processes for large projects requiring many teams
seems to be quite popular. What I feel is largely missing,
though, is a discussion of the environment agile teams
need to flourish and actually deliver the promised benefits:
flexibility, productivity, quality, higher job satisfaction and above all frequent releases of working software.
By environment I mean all the elements that create the
space - both actual and figurative - within which the game
of software development is played and the team dynamics
occur. The way office is laid out, the equipment people get,
the way their day is structured and their work evaluated,
the way they relate to one another - all those elements
create an environment that will shape teams behavior in
Now means early 2013.

Introduction

ii

a powerful even if subtle way. I believe that elements of

such a good environment are similar and common across
companies and even industries, because as unique as each
of us is we are all human.
In this short work I will focus just on some aspects
of that environment only briefly touching the underlying
foundation of companys culture and managers/leaders
role in maintaining it.
Based on my experience, observations and input from
others I try to present practical advice, especially for those
who start new companies. I believe there is a much higher
probability of succeeding if you set up a good environment
from the start rather than try to transform a dysfunctional
one. I do hope, however, that those few words of advice
will be helpful for readers working in both startups and
established companies.
As with everything agile I dont pretend to lay out a
complete recipe to follow Im rather presenting here an
experience-based vision of what I believe is an ideal agile
environment. I hope it will inspire you as you create the
best possible environment for your company, teams and
projects.

I believe those terms are unnecessarily treated as contradictory. A good

leader is also a manager, because leadership is not just about strategy and vision.
A good manager must be something more than a mere administrator - a good
manager is also a leader.

1 Principles
Here are the principles that I think management of an Agile
company should follow in order to instill a culture that
will not only be supportive for agility, but also ethical and
humane.
People are not machines
Never ever think of (or refer to) people as resources.
This is not only unethical, but also inaccurate. Humans are nonlinear, multidimensional beings. Especially so those performing creative knowledge work.
It is not possible to objectively measure them with
a metric nor trully motivate with a KPI, it is not
possible to create a pipeline of them if you want great
results - not just passable mediocrity. You have to
embrace them for what they are - fellow humans.
The art must not suffer
If you want high quality work (meaning - good
products, good code, bright ideas) you must have this
attitude and make it part of the company culture.
What you aim for is a culture of craftsmen, artisans
who are rightly proud of their work and who help
each other on the constant quest for mastery in their
craft.
This is utterly incompatible with pressure to deliver
everything by Monday and especially telling your

Principles

teams ever I dont care how you do it, I want it

done by the end of the week. When having a tight
deadline you can say instead: Im very sorry I have
to ask you to do something below our professional
standards, but we need it by Monday. Well fix it
once this situation is over. - just be sure to actually
keep the promise!
Were not doing it just for the money
One of most powerful motivators is peoples yearning for their lives to have a meaning. Just earning
a living is not enough - especially if you feel you
have capacity to do more. Yes, people can do quality
work just for the pay because they are honest and
hardworking. However, again, if you want to move
beyond just good and produce things that will
astonish the world - or at least your clients - people
need to feel they do something more than just sell
their time in exchange for money. But that means the
whole organization must have some other purpose
than just generating revenue for its owners.
What good your time spent here brings? is a question we should ask ourselves, but as leaders we need
to provide that answer to those we lead. Look around
- great business leaders are (and were) doing just
that.
We respect those who fail pursuing innovation
This is rather obvious. I feel I shouldnt even have
to explain why this principle should be a part of any

Principles

healthy culture. If we dont appreciate those willing

to do risky things we will not innovate - or at least
not as much as others who do.
It is better to experiment and fail than to complain
and do nothing. should be not just a slogan, but a
practical part of the culture.
Hard truth is always better than a rosy lie
Again, I feel a bit uneasy about including something
this obvious. And yet, still, one of the complaints
I hear often from teams is that their management
wont accept hard truth forcing them to compromise
quality in order to deliver against unrealistic deadlines. Dont those managers understand that to make
good decisions they need to know the truth as soon
as possible?
It reads like a mini-manifesto and in fact it is. This is
what I believe in. I believe those principles are universal,
applicable to all organizations. I always followed these
principles in my work and I never regretted it. They seem
obvious, yet over and over again I see organizations built
on their exact opposites.
That is why I think startup founders should be especially aware of them. After all, isnt the desire to escape
typical, dysfunctional corporate culture part of the reason
why you are a startup founder? Shouldnt you at least strive
to create not only a better, innovative product/service, but
also a better work place for those that will work with you?

Principles

Isnt it part of your responsibility as the founder? I hope we

agree on that.

2 Physical environment
Physical environment shapes human behavior. Most people work at least eight hours a day and they usually do it
together with others in an office. The way that office is laid
out and equipped has therefore a very deep influence on
how people will feel there and, consequently, on how they
will work. If the office will be laid out to alienate people
they will feel alienated. If it will be cold and impersonal
people will not consider it their space.
We want to avoid this and create a space that will
support the principles discussed above.

2.1 Team spaces (war rooms)

Agile teams are teams that interact a lot (Humans and
interactions over processes and tools is the first point
of the Agile Manifesto). They program in pairs, review
each others code, discuss designs and architecture, draw
diagrams, use different boards and play games together.
Above all they talk, chat and discuss their work - and
everything else. An agile company should therefore strive
to make direct interaction within teams as easy as possible.
Research shows clearly that the physical distance afSo called Allen curve see Thomas J. Allen, (1984) Managing the Flow
of Technology. Technology Transfer and the Dissemination of Technological
Information Within the R&D Organization, Cambridge, MA: MIT Press.

Physical environment

fects negatively the frequency of communication between

people and that recent technological advances in telecommunication havent changed this. This is why team members should sit together in one room or other designated
space visibly separated from other teams. In agile literature
such a place is frequently called a team war room.
Putting a group of people together in the same space
helps them develop bonds and perceive themselves as a
team. This happens whether it is intentional or not. Every
manager knows from experience that when a company
moves to a new office and the way people are divided into
rooms changes the overall team dynamics and relationships
within them change as well. What we want is to get this
influence of physical layout to work for our benefit.
Furthermore, since agile teams extensively use various
visual aids (backlogs, burndown charts, Kanban boards and
the like) having them visible for the teams at all times in
their rooms helps them maintain focus and commitment.
Finally, agile teams are cross-functional and created
around work to be done, not specialties or other artificial
organizational concepts of the past. That means teams
composition may change as the work being done changes.
Usually an agile team is created when there is a software
product to be created, it can then expand into a couple
of teams as work load on the product increases and then
contract again as the project nears completion. Support
teams are created as needed to support products/services,
their size and composition fluctuating as needs change
through the products/services life cycle.

Physical environment

Because of this I think the concept of someones permanent cubicle or desk has no place in a truly agile company.
Too often in traditional organizations those turn into office castles - places where people hide to survive their day
at work. Instead, each employee should sit with the team
he/she is a part of, in that teams war room and move to
another room when they change teams.
In an agile company team membership means being
physically together with other team members on a daily
basis in a designated space that team collectively owns.
This has profound psychological consequences, especially
over time.
We want therefore to create a space for each team,
one that is comfortable and inviting, but not necessarily
luxurious. We want to create a space that encourages
people to move around and interact with others.
All of those reasons and requirements translate into
following guidelines for setting up team rooms/spaces:
Each team should have its own space. Ideally it
should be a separate office/room with a door etc. so
that teams discussions and interactions would not
disrupt other teams. Walls make it easy to keep visual
aids close to the team, they also provide necessary
structural support for hanging heavier items like
LCD screens.
If that is not possible (eg. in the horrible open space
offices of the late 20th century) teams space should
be delimited with cubicle walls or any other material

Physical environment

you can find. Even makeshift walls made of recycled

cardboard will be better than leaving team members
scattered throughout the office, mixed with people
from other teams.

A team war room layout

Inside a war room everyone should sit around one

large table in the center of the team room. That
way everyone faces everyone, everyone can talk to
everyone and everyone is equal just like King
Arthurs knights. A team table can be one piece of
furniture, big and round, but it can also be modular,
made out of individual desks put together. Such a
modular approach is much better for situations
when projects and hence teams are likely to
change relatively frequently (more than once a year).
Reconfiguring the space for teams of different sizes

Physical environment

is then much easier - you just move some desks to

another room or to storage.
Each individual place at a team table should be
large enough to temporarily accommodate two people for discussions, code reviews, pair programming
etc.
Each individual place should be standardized and
equipped in the same way initially; teams will customize their space as needed as they go. A bare
minimum is a large screen, keyboard and a mouse
plus a docking station or a standard set of connectors
for team members laptops. A movable cabinet with
drawers under the desk for personal belongings can
be a welcome option.
All electric and network connections should be in
the team tables center. Cables should come to the
tables center under the floor or the ceiling to avoid
having them extended from the walls. That way
the remaining space is not unnecessarily cluttered
making it easy to move around the table.
Comfortable chairs are a must. People will spend
hours in them more than in any other piece of
furniture except maybe their beds. How well they
will feel, how fast they will tire depends on how
well they will sit. If your budget is tight save on
everything else and buy the best chairs you can
afford. Accommodate individual preferences if you
can as opposed to the desk (place in the office)
chairs can be individual. Remember to make sure

Physical environment

10

chairs are on wheels or light enough to be easily

carried around as needed.
Buy the largest whiteboards you can find and put
them on the walls around the team table. If you can
afford just one make sure it is as big as your budget
(and wall size) permits. Alternatively, you can paint
the walls with a special paint that turns any surface
into a whiteboard for dry-erase markers.
Add a cork board if you use card-based physical
backlog or Kanban board. Cards can be also pinned
to a typical whiteboard with magnets. Another type
of special paint can turn any flat surface into a
magnetic board.
If either is not possible (rented space with restrictive
landlord etc.) you can use a special Leitz foil that
works just like a whiteboard and sticks to walls with
an electrostatic charge leaving no marks on them. No
landlord can complain about those.
Add one smaller, mobile flipchart/whiteboard combo
per each room.
Some like working in brightly lit rooms. Others
prefer to work in darkness with a small desktop
lamp just enough to see their own keyboard and
notes. Since you shouldnt impose either way on
your teams make sure both types of lighting are
available in each team room. Make sure the ceiling
lighting is adequate, but also equip every individual
For example http://www.ideapaint.com/.

Physical environment

11

place around the team table with a small halogen

lamp. Teams will figure out how to use it all best.
For teams that definitely prefer to work in the dark
and at night adding a small lamp for the whiteboard
may be an additional help.
Sometimes surprise, surprise! developers also
do work in daylight hours. Make sure windows are
equipped with blinds/shutters to block the sun if it is
too bright or shines someone straight in the eyes.
If any additional equipment is needed in the team
room, like a printer, a build server, a screen serving
as an information radiator etc. put it on small tables
in team rooms corners or mount it to the walls.
If the team is not dispersed and there is no external
client to talk to there is no reason to have a landline,
stationary phone in the team room. Make sure it is
not there, it is just a potential source of distractions.
If, however, it is needed make sure teams have all the
equipment they need to stay connected.
Dont worry about the cell phones - each team will
create a working agreement about their usage on
its own. Usually team members will be required to
switch their phones to silent mode. The nice part is
that this will be a mutual agreement by colleagues,
not an imposition from a manager.
Heating/cooling this is something very basic, however ideally temperature controls should be in each
Very important with the silly fashion for glossy screens, that luckily seems
to receede.

Physical environment

12

team room so that each team can adjust their temperature to their own comfort level. Windows that
do open do help unless youre unlucky enough to be
located near a busy street.
It is important to understand that creating an office
space according to the guidelines above is not reserved
for cool Silicon Valley startups awash in investors money.
When setting up our first office at Code Sprinters back in
2007 we didnt have lots of money for equipment, so we
went for a budget approach. We used standard, cheap $34
IKEA VIKA AMON work desks put together to create as
large a team table as we needed. That table was of course
in the middle of the room. At the beginning everyone was
sitting around it. Once we had more people and more than
one project running at the same time we reconfigured it to
two tables and later on (once we moved and had more
rooms) to two tables, each in one of two larger rooms.
We also bought the biggest whiteboards we could find
for each room and we had additional flipchart/whiteboard
combinations that could be moved around (eg. between
team rooms and the meeting room). We didnt need elaborate digital information radiators, but we had a screen in
the room that displayed the build status for all projects (it
was going red if someone broke the build). We also had a
display showing the burndown chart from our Scrum tool,
the Banana Scrum, for the project that was being done in
that room. At first they were standing on the floor, then we
bought IKEA LACK coffee tables (@$10) and placed them
in room corners.

Physical environment

13

One advantage of using a commodity furniture like

IKEAs besides it being cheap is that it can be easily purchased again. If you need to expand or replace worn down
items it is easy to do so without breaking the consistency
of your offices look. Custom build, designer desks are cool
but will you be able to buy another pair in three years?

2.2 The managers rooms

Dont include separate offices for managers in your office.
A separate office, where the manager will sit alone most of
the day will serve only the purpose of alienating him or her
from the team(s). Instead of knowing what is happening
he will focus on managing KPIs and metrics and end up
completely disconnected from reality. Instead of being part
of the overall team he will become an authority figure, his
sudden presence among the troops will intimidate them.
To avoid this encourage managers (including yourself)
to roam between teams. It should be a custom that a
manager is free to join whatever team he wants if there is a
free desk there with his laptop and sit there doing his work.
They should be changing place almost every day, that way
the teams will be used to their presence and less likely to
be intimidated by it. This improves the chances of genuine,
honest discussions and feedback both ways.
If a manager needs some peace and quiet he can use a
Silent Room (see below), just like everyone else. If he has
to meet with someone to discuss a topic in private he can
use one of the meeting rooms. Just make sure no manager

Physical environment

14

will permanently occupy a meeting room or a Silent Room

turning it effectively into his office.

2.3 Other useful areas

An office usually has more than one room, one team or one
project and hence there are some other spaces. I believe
that agile approach reaches beyond workers desks, and
that a truly agile company is one that strives to create
friendly, inviting spaces that are pleasant to be in and also
encourage/facilitate collaboration beyond teams in their
rooms.
Here are some simple guidelines for setting up the rest
of your office so that it naturally complements the ideal
team war rooms described above.

Meeting rooms
Meeting rooms are very useful even for a company with
agile teams. While team war rooms are where teams work
every day (and all team meetings, like the ones prescribed
by Scrum, should take place here) there are other situations
where meeting rooms are necessary. Clients come to talk
about projects and contracts, new hires come for interviews
and so on.
Those guests should not be normally invited into team
rooms. The teams room is like your bedroom-cum-office
at home not a place you usually invite all your guests to,
rather preferring to meet them in your living room. Same
principle applies here.

Physical environment

15

Additionally, a larger meeting room may be needed to

gather more people that would fit in a single team war
room. And if your company uses expensive teleconferencing systems it may not be able to afford to put the necessary
equipment in each room.

Kitchens
Kitchens/coffee rooms are even more important than official meeting rooms. It has been known for ages that the
real social life of companies happens there over coffee and
communal meals (the proverbial programmers pizza).
Consequently much of the communication between teams
occurs there. Care should be taken to ensure those spaces
are adequately equipped and furnished. It should be a
place you would genuinely enjoy having a cup of coffee
in and also a place where a small group would be able to
comfortably eat. Therefore, a cushy sofa or two and a good
table with solid chairs are a must.
Make sure WiFi coverage extends there and power is
available.
Again, I want to stress that this doesnt mean spending
lots of money. You can buy designer sofas embroidered
with the company logo in golden thread, but you dont have
to. At Code Sprinters we had an extremely comfortable
sofa that I did get for free from my parents-in-law after
Communal meals are an important part of any culture. Each known
civilization and nation has its own set of rules and customs for eating together.
Eating together is a bonding ritual recommended for families and teams.

Physical environment

16

they have remodeled their living room. We just bought

a piece of nice cloth to cover it and make it look more
modern. Tables we did get cheaply from IKEA along with
cutlery, dishes and other utensils. An inexpensive espresso
machine bought on eBay complemented the furnishings
and a standard gas stove was already there. A couple of
decorative items made our kitchen more welcoming.
Overall weve spent about $400 and created a place
where you could reheat or even cook a meal, eat a pizza
or cookies, work or just relax over coffee.
A touchy issue is what kind of supplies to provide for
your team(s) in the kitchen. I think coffe, tea and milk (for
those unable to drink black coffee) are a bare minimum and
should always be provided. Sweets (chocolate bars, cookies
etc.), fruit or even meals can also be included - and in fact
are provided by many companies. Though everyone has
read (with envy) about gourmet chefs working at Google it
doesnt require a huge budget to provide meals for your
staff. A colleague of mine arranged for free lunches for
developers by contracting a lady to come to the office every
day and prepare a home-cooked meal for the teams. This
A few weeks later they started to miss their old sofa. The new one was
fancy and chic, but it was nowhere near as comfortable as the old clunker that
was already the teams favorite at the office.
For example, we did print out some photographs we have made and hanged
them framed on the walls. Cost? A couple of IKEA picture frames, a couple of
standard photo-prints, nails.
In some countries anything you provided for free to employees is seen
as their economic benefit and is thus taxed. Usually there are ways of legally
circumventing this idiocy, consult your accountant and/or lawyer to learn what
your situation is.

Physical environment

17

didnt cost the company much, was greatly appreciated and increased attendance at the office.
Whatever you decide to provide keep in mind that
it will be perceived by people as the normal, standard
situation - the way things should be. Should supplies of
anything cease it would be seen as a sign of companys
degradation affecting morale negatively (it would be explained as caused either by declining finances or increasing
greed on the part of the owners). Therefore make sure you
provide only goods that you can supply on a sustained
basis.

Nap-Points
A Nap-Point is my name for a place at the office where
one can take a nap.
Like many people I frequently experience a drop in my
energy level sometime in the afternoon. When this moment
comes I need a nap desperately and just 15 minutes on a
couch regenerate me for the rest of my day. I used to sleep
in many different places in the companies I worked for over
the years in my car on the parking lot, in unused offices in
an adjacent building, even in meeting rooms I reserved for
the purpose until the time came when I could implement
a Nap Point in my own office. As I expected I wasnt the
only one who appreciated it.
A Nap Point should be a quiet place with a couch or
As far as I know Google has Nap Points in their offices, though they dont
use this name. In their case it is usually a room with a couple of capsule-like beds
or couches.

Physical environment

18

a sofa one can lay on. If you have an office large enough
to be able to have a separate room for a Nap-Point it
would be ideally a small room far away from typical lines
of communication, kitchens, toilets and any other noisy
places, with good ventilation and blinds on the windows
or no windows at all.
A simple system for indicating a Nap-Point is occupied
(like an arrow pinned to the door pointing at either free or
occupied) or a reservation system would help with larger
teams.

Silent Room
While talking and being open to others is promoted in agile
people sometimes need some peace and quiet when they
work. As long as working alone is not becoming a rule
we should make it possible to escape the noise and chatter
of team war rooms by creating a refuge where you can
sit undisturbed in silence. Such a room ideally would be
just like any other team room, with standard desks and
standard equipment it just wont be assigned to one team
and there would be an agreement that whoever is in this
room keeps quiet. It will be definitely appreciated by the
teams.
If that is not possible due to space constraints teams
should consider including into their working agreements a
Inappropriate use may be a problem in some teams. Make sure youre not
liable as a company if this happens.
For readers of the Sherlock Holmes novels just one name will be enough to
describe the concept: The Diogenes Club.

Physical environment

19

rule that whoever has headphones on is not to be disturbed

by others. The company could even consider supplying the
headphones if it can afford it.

Library
Even in our digital age books are the main vehicle of
solid knowledge on everything from gardening to design of
algorithms. No matter what projects you work on chances
are your teams will need more than a couple of books on
relevant subjects. A library everyone can use is a must. It
can be just one cabinet with books in the silent room or
even the kitchen/day room, it can be a whole separate room
that depends on the size of your book collection. No need
to employ a librarian a self-managed system with a wiki
page listing all the titles should work perfectly for small and
mid-sized teams. Unless your books contain government
secrets employees should be free to take them home with
the agreement that they will a) mark each book as taken on
the Wiki and b) bring them back eventually.
Periodically ordering books people want will be very
appreciated by the teams. Again, letting teams know when
book orders go and how much money is allocated for purchases will help to make it more organized. Most probably
another Wiki page will be set up to list needed titles and
vote on them.
Steve Blank provides a great story about exactly this on his blog here.
If you are worried about theft you should consider this: so you dont trust
people not to steal books, but you trust them enough to create products for you
and know your trade secrets? Hm

Physical environment

20

The rising popularity of e-books means that more and

more people are having Kindles, Nooks or other e-readers
and may want to read books on them. The problem is,
however, that e-book vendors usually make it hard to
easily share books and their group use policies are rather
awkward and difficult to use (especially if you dont live
in the US). It is much easier to buy physical books that the
company can own outright and then share them with
the people than to try to share the e-books. There are,
however, ebooks that are free from those constraints (free
or published by independent vendors like LeanPub) and can
be shared in a company. Create a repository for them so
that anyone interested can upload them to their e-reader
of choice.

Toilets
Mentioning them here seems stupid, but they are important. Everyone will visit them a couple of times a day. All
your visitors (and prospective hires) will go there and most
probably judge your company based on what they see (and
smell) there. No need to make them fancy but keeping
them clean, fresh and stocked with the necessary supplies
is a must. As I said, it feels stupid I have to mention this, but
too often I have seen otherwise nice offices with positively
disgusting toilets.

Physical environment

21

Smoking place
Somehow in most of the teams Ive built and managed we
didnt have too many smokers. It seems that the percentage
of smokers among IT geeks is much lower than in the
general population. However, if you have a larger team
chances are you will have smokers amongst your people.
Find them a good place where they can indulge in their
addiction, otherwise they will find one themselves and
more often than not it will cause discomfort to others.

2.4 Access to the office

I believe that everyone should have access to the office at
all times. While working at weird hours or days shouldnt
be encouraged or become a norm people should have the
ability to occasionally do so if they wish.
There are many good reasons why someone may want
to work at the office on a particular Sunday or night.
Reviewing such a request every time and granting access
based on the case presented doesnt make sense it is better
to give everyone access and then let the teams figure out
how to make the best use of it.
In one company I worked at smokers had no designated room so they
smoked outside. Naturally, they were smoking in a group near the front door.
Everyone coming into the office had to go through a cloud of tobacco smoke.
Later on when winter came they moved into the basement now the smoke was
traveling up through the staircase causing discomfort for everyone. In the end
smoking was banned altogether smokers moved into toilets and again outside.
Wouldnt it be better if they had a designated room or better a plexiglas cage like
the ones installed in the airports - to smoke in peace without disturbing others?

Physical environment

22

Implementing this principle is quite easy you can do it

with all kinds of digital locks (from code-locks to proximity
card readers) or even with the most traditional locks using
metal keys. If digital locks are used I suggest that each
worker be granted access at least to his/her team room plus
all the common areas.
During the normal work hours team rooms shouldnt
be locked to encourage inter-team collaboration, but in
some places locking them down at night for security of
personal items left behind may be a good idea. You know
where you live, so youll know best what path to follow.
When renting an office make sure general building
rules will not interfere here. There are still office buildings
where you cant access your own office at night check
ahead and avoid them.

2.5 Final caveat

One very important remark: make sure it is OK for teams
to customize their space. Ive seen designer offices that
looked great, but felt cold and sterile because clearly no one
was allowed to change anything, hang their own posters or
pictures on the walls etc.
It is, of course, normal for the company to be concerned about the impression their office makes on visitors,
including clients. Thats why I think visitors shouldnt be
normally invited into team rooms, but rather should see
a reception area and a meeting room. Of course, if a client
knows the industry enough not to be fooled with the image

Physical environment

23

that mistakes software development with clean-lab work

on semiconductors they can be invited in and experience
the creative disorder of team rooms.

3 Management
The physical environment is of course not enough to support an agile company. A culture compatible with agile
methods and principles is even more important.
Since agile approaches are rooted in empirical process
control a culture that supports transparency is essential.
Without it the inspect & adapt loops driving the empirical
process will not work. Good decisions can be made only
based on correct information. In other words, truth must
be one of key values. In order for that to be possible trust
necessary for people to tell the truth must be fostered.
Finally, openness to change is also an important element
of a healthy company culture.
Creating and sustaining such a culture on all levels
is the primary responsibility of the management - and
in a startup of its founders. Managers are the leaders
shaping the culture in the team(s) and the whole company.
And companys founders are even more important - the
company they create is built in their likeness, as all creation
it is infused with its creators character.
How those leaders interact with the team, clients and
other stakeholders serves as a blueprint for everyone else
as well as indicator of what is acceptable, desirable - and
what is not. They also create and sustain a supportive
environment for the teams to thrive in.

Management

25

3.1 Advice for the manager

If you are a manager - a company founder or a department
head - here is my advice for you. It is based primarily on
my own experience as a manager who created teams from
scratch a number of times (including a couple of times in a
startup) as well as observations made as a consultant and
coach in different companies.

General
Abstain from telling people what to do
Since your goal is to develop teams that will not require
constant supervision, teams that can be trusted to do the
best work possible, you must help your teams develop a
level of autonomy and self-organization. Telling people
outright what to do inhibits that development. People
routinely told what to do (and - even worse - then judged
based on how closely they followed their marching orders)
become disassociated from the work and its purpose. Instead of thinking how to deliver the best result (product,
service) they at best wait for orders and then strive to
execute them to the letter.
It is important to be aware that this negative dynamic
occurs regardless of the orders correctness. Yes, if you are
a brilliant genius and your decisions and solutions are often
right people may resent being bossed around less - but
it will make them passive all the same if not more. Why
should they strive to invent their own solutions if they
know one (probably even better than their own) would be

Management

26

handed down to them?

So, as a rule, you should hand teams problems to be
solved with just an outline of expected end results not a
solution to be executed.
And of course there will be exceptions - moments,
when you will say do this & that for different reasons.
This is not a problem as long as those are indeed exceptions.
Please also note that this doesnt mean you should
avoid making decisions. On the contrary - sometimes it is
your responsibility as a manager to decide, often quickly
and with incomplete knowledge. Just make sure you listened to different points of view and explained why you
decided the way you did. No on expects to be right every time, but people like to understand why you decided
against their advice.
So, you have to strike a balance between decisiveness
when needed and gentle direction-giving most of the time.
It is hard to describe what proportions are right, so much
of this is contextual and driven by experience. However, I
hope the sole awareness of the need for this balance will
help you find the right spot.
Leave developers as much freedom as possible to
work the way they choose
That means ensuring there is as little formalism, as few
procedures and standards as possible - and those that are
I understand developers exactly as the Ken Schwaber and Jeff Sutherland
defined them when describing the Development Team in the Scrum Guide:
professionals who do the work of delivering the [] product. In other words
that means everyone who directly contributes work in the development process
- programmers, testers & other specialties.

Management

27

in place are developed by the staff themselves rather than

handed down from above. It is for example much better to
suggest there should be a definition of done or a release
checklist then to impose one.
I specifically underlined developers here for a reason
- people doing other things in your company, like for
example accounting, sales, administrative and customer
service staff can actually benefit from clear procedures
ordering their work. This is so not only because their work
is less creative and much more repetitive than software
development. More consistency is needed in those areas too
- expenditures should be classified the same way always,
clients should get same service every time they call with a
typical request etc.
Practice empiricism
Outside of the realm of things that are obvious we are
dealing mostly with unknowns.
We think we know what will happen if we do this
or that, but for the most part those are just more or less
probable hypotheses based on our experience. There are
two solutions to this problem - clairvoyance or empiricism.
I am no expert on the first - to be honest, I have zero
experience in that field - so I am always advocating the
second.
Joking aside empiricism is based on assuming everything is an experiment to be watched closely. If it strays
outside of what we deem desirable we will readjust its parameters. In other words use of empiricism means moving
ahead in small steps with what we think at the moment

Management

28

is the best course of action but being ready to change

direction as soon as we stray off course or (what is more
likely) the goal moves.
The practical application of this is that you shouldnt
fear testing out new ideas, ways of working or organizing
work. Go for what you feel is right, but watch closely and
be ready to adjust - or even abandon your idea if it turns
out that it doesnt work.
A good example of this is a story I heard from one of
the gurus of Agile about how he & his teams discovered
the best way to estimate the product backlog. He had about
eight teams and all of those teams tried something different
in their estimation every month, then shared and compared
the results at the end. This allowed them to test up to eight
different ideas every month and pretty soon evolve a way
of estimating the product backlog that worked for all of
them.
You can do the same for almost all aspects of your
organization. Each unit of time, each team, is a chance to
see what could be improved, what could be working better.
Remember this is a process
Whether you are building a new development organization (or a whole company) from scratch or attempting to
transform an old one this is always a process. That means
different approaches are needed at different stages.
For example when introducing agility to teams you
need to be more prescriptive, sometimes even mandate
things like daily standups or strict sprints. With time this
should be less and less needed as teams mature, as people

Management

29

get used to having more control and responsibility.

It is much easier when things are built from scratch as
in a startup. The challenge here is less the seeding stage,
but rather how to keep that spirit and way of working
that seemed natural at the beginning from degenerating as
number of people and level of complexity grow. This may
require sometimes more direct approach than what I am
describing here as the desirable, normal state.
No matter where you started there is one other important thing to be aware of: this process never ends. You can
never say it is done, we are agile, we are superb, there
is nothing we could improve. It would never be true. Your
goodness is always relative to the environment - and that
environment changes. People change - they both leave and
others come in, also those that stay in your ranks change
as they age and mature. Once you achieve a certain level in
anything both individually and collectively a new peak to
climb usually reveals itself, a new barrier to tackle is met,
another impossibility to outsmart reveals itself.
And this is good news actually. Isnt it motivating,
energizing even, to be aware the story never ends? In
any case empiricism is your guide, your navigator in this
voyage.
Be pragmatic
Dont cling mentally too much to best practices,
methodologies, labels and names - including those that the
Agile movement has produced. There will be cases when
a best practice doesnt work for you or when the best
At least for me.

Management

30

methodology fails you. That is normal. Just move ahead

doing what you feel is right within the boundaries set by
the basic principles.
This pragmatism has also another dimension: the methods, the management and communication style must be
adjusted depending on people and work they perform. People are different, some are more autonomous and resilient,
other more depended on the group, some exhibit more
initiative while others are good at keeping things running
along the known tracks. This is why a good leader has a
different tone in his message for people he (or she) works
with.
Never treat people as resources
I have mentioned that already in the Principles section, but I want to underline that message here: you work
with people, not with resources. Your task it is not to acquire resources, overlook their exploitation and subsequent
disposal. You want to change a bunch of individuals into a
team - a sum greater than its parts, an environment where
each of them will develop, each will have a chance to excel
at the same time contributing to the success of the team as
a whole.

Metrics, bonuses etc.

Dont count hours
One of the most nonsensical activities many managers
engage in is counting hours registering hours worked and
judging people based on how many hours they spent bent
over their keyboards at the office.

Management

31

The worst approach here is of course paying by the

hour. It not only gives people an incentive to work slow
- it practically forces them to cheat.
The official work day is 8 hours, but it is virtually
impossible to be really working all that time. Plus when
you work as a software developer it may be really challenging to count time appropriately - does thinking about
an algorithm in the restroom count? How about searching
the net randomly looking for inspiration? Is e-mail work or
not? How to measure time spent on context switching after
being interrupted with a phone call, a colleague asking a
question and so on?
If you have ever filled in time sheets in your life you
know yourself how much they are worth. The information
contained there is at best inaccurate. Of course, people
dont cheat to the point of reporting they have been in the
office when they were absent. They just make sure hours
reported add up to what is required and expected. And
indeed this is accepted by most employers. But it makes
it ok to color the reality a bit, stretch the truth and this is
introducing an element of dishonesty that I object to here.
But apart from that the number of hours worked is a
completely useless metric for creative work of any kind
- and especially creative team work. Since hour is incomparable to hour and work is non-linear, not easily
measurable (how to measure how good a piece of code
is?) this number doesnt give any usable information about
your organization.
It is actually a legacy of the industrial age and punch

Management

32

clocks used to measure time spent by workers on factory

floor. Back then it made sense, since the worker was
actually an extension of a machine installed in the factory
supplying intelligence the machine lacked. The problems
he was solving were simple and limited to what was
needed to perform well the task the machine was built
for. Therefore the workers productivity was zero once he
walked away from his machine.
This logic is not applicable to software development.
Contrary to what people unfamiliar with it may think it
is not the computer that is the primary development tool.
It is the developers brain. Most of the work is done there,
typing on the keyboard is merely a consequence, a result of
the thinking going on inside. Therefore, a developer can be
sitting in front of his computer completely unproductive and he can be also thinking hard about a problem when
driving home, in the gym or in the shower. Measuring
hours spent in the office serves no real purpose then,
because we cant externally distinguish productive from
unproductive hours.
Be careful with metrics
Something I see in many managers I work with as a
coach is the urge to objectively measure, preferably with
some metrics that a software tool could automatically
compute (because those seem objective). This I think stems
from the famous phrase You cant manage what you cant
measure being hammered into the heads of prospective

Management

33

managers for years now.

While this may be true for some aspects of running a
business - like for example the crucial element of managing
your money - it definitely is not applicable to working
with people, especially ones engaging in creative work in a
highly complex domain.
This urge to measure works on two levels. One is the
desire to know how good your development team - or
whole development organization - is overall. The second
- and I think much worse - is the desire to be able to objectively measure how each individual developer is working
then compare that over time and to other developers
performance.
The problem here is that it is very hard to define
good code. While it is fairly easy to measure some simple
qualities of the code - like for example how many lines
there are, how many function points there are or even
(with more recent tools) how well it adheres to some coding
standard - none of them really say whether a piece of code
is good or not. Those metrics can not tell you if the code
is an elegant, effective solution to the problem at hand.
Or how easy it will be to understand and change it in the
future. In order to know that you need an expert - another
programmer - that would read the code and then give you
It is amazing this phrase is still repeated and held as true by many despite
leading experts of management science consistently opposing it. For example W.
Edwards Deming expressly condemned the practice of running a company on
visible figures alone as one of deadly diseases. Ironically, the phrase itself is
commonly incorrectly attributed to him.

Management

34

an opinion.
Of course, you can start measuring things like test coverage (especially unit test coverage) or number of defects
(bugs) discovered on different stages of the process. This is
a much better indicator of quality, but is still just a proxy of
it and can be misleading. Unit tests can be working and pass
- and still be useless. Number of bugs discovered, especially
by end users, is a pretty good metric, however it is possible
to keep this number down for a long time and still produce
low quality code.
The problem becomes even greater if you want to try
and measure developers as individuals. Who is better - a
developer when can churn out tons of working code in
an afternoon or someone who slowly and carefully crafts
code that is elegant, beautiful even? Who is more valuable
in a team - someone who can mathematically solve a
problem creating a low-cost algorithm or someone who can
optimize the code using his knowledge of the way in which
the compiler and the execution environment works? Even
if we knew the answers, what metrics could tell us?
Add to that the fact that we want teams, that means
we need different minds, each with its different baggage of
experiences and skills that supplement each other. Peoples
value for a team can be quite obvious for an experienced
observer yet almost impossible to capture with metrics.
A story I always tell when discussing this problem
This is the basic idea behind the practice of code reviews. If other developer
can read and understand the code now chances are someone else will be able to
understand it in the future.

Management

35

is that of a developer I once had in a company where I

managed the technical department. He was frequently late
with his code and sometimes that code wasnt very good
- it usually needed some polishing by a more experienced
team member. Was he an asset or a problem for this team?
Based on this information many people jump at conclusion
that indeed he was a drag. However, his value in that team
lied in his talent for stirring up and moderating discussions
as well as ability to quickly grasp new, unfamiliar concepts.
He was the one getting the team gathered around the
whiteboard discussing solutions and he was frequently able
to understand ambiguous client requirements faster than
others.
The summary: metrics are useful, but be careful with
them. They never tell the full story, so they can only be a
general indicator of how things go. If they move something
is going on in your team(s), it may be totally benign
or completely catastrophic - you will never know from
metrics themselves. They will never help you tell which
of the people working with you is better.
Be even more careful with bonuses
Bonuses are one more thing to be careful with. I have
spent about a decade on my private quest to come up with
a system of bonuses for developers that would be at the
same time motivating and fair, transparent and objective.
This is very hard considering how difficult it is to measure
the software development work, especially on the level of
each individual team member (as was discussed above). I
tried different approaches until I reached the epiphany that

Management

36

there is no such thing as a good bonus system for software

developer.
The best approach is to have no bonuses at all. Just pay
people enough so that they wont be thinking about the
money anymore. This is usually slightly above the level
that solves all the operational problems of everyday life.
This is best achieved by paying people slightly less than
what they asked when they start working for you and
then raising the wages gradually within the first two-three
years. From that moment on what you want is to at least
keep up with purchasing power and market conditions.
A better approach is to tie the pay rises to how well the
company is doing - if it is growing and doing well it is a
healthy thing to share some of that with people that work
for it.
If you feel the approach of having no bonuses is too
radical then best bonuses are discretionary ones given by
a good, experienced manager who is still close enough
to the teams to be able to see and appreciate individual
contributions. Of course, such a person must also be as
objective as humanly possible, not giving in to personal
likes and dislikes which is hard but possible.
You can also tie bonuses to companys profit, which
is again healthy, but not particularly motivating if what a
person does is not directly linked to that profit.
The absolutely worst option is to tie in any bonuses to
any metrics or KPIs. This will almost always lead to unintended side effects as people will naturally work towards
maximizing that particular metric or KPI at the expense

Management

37

of other aspects of their work. Some organizations try to

cope with that by creating complex formulas based on
different weighted metrics and KPIs. This however fails
to achieve the purpose of being a motivator, because the
more complex the formula the less people understand it and then they start treat the bonus as a lottery win.
Again, one caveat - this discussion is applicable to
software development teams and probably anyone else
who does complex, creative work which by its very nature
is multi-dimensional and hard to measure objectively. Stuff
like sales etc. may be better served with some form of KPI/metric based bonuses, though based on my own limited
experience in those other fields I would be still quite careful
when designing them.
Work with people not numbers
As one friend of mine said you cant manage people
through Excel spreadsheets. Depressingly many managers
still try to do just that. Dont be one of them. Dont try
to seal yourself off with reports, tables and charts. Talk to
people, not to your computer.
Which is why I am strongly suggesting that you dont
have an office where you would be sitting comfortably
and thus loose contact with your people and naturally turn
to reports to make up for this. Instead roam the whole office
freely, be a nomad joining this or that team, working in the
kitchen or other communal area so that you can be always

Management

38

immersed in the vibe of your teams.

This, obviously, works only until your team(s) is around
40-50 people. Above that limit it would be next to impossible to stay connected with your teams directly. Yes, you
still should roam around, smell the air and listen to the buzz
of your office but by necessity you will be more distanced
from most. In this case delegate wisely and try to be in
touch with your reports daily.
As a side note it is worth mentioning that many managers experiences a sense of loss when their teams get so
big they have to delegate and therefore be in close contact
only with a smaller subgroup. This sense of loss can be
sometimes quite acute. It is worth talking about it with
someone else - like a coach or mentor - who will help you
get over it.

Organization and structure

Dont impose strict working hours
Since hours are a useless metric imposing strict working hours makes also no sense whatsoever. Make sure
everyone can access office whenever they want and leave it
at that. Any additional rules would be set up by the teams.
Again, of course we are aiming for a balance here. We
want people to come to the office and work together as a
team. So we should be concerned if they are nowhere to be
seen - however, we want to achieve it primarily not through
Just like everyone you will need some time alone. It is better to go to a
coffee shop, use the quiet room or even work from home for a day than to have
an office. The temptation to go and lock yourself there will be too great.

Management

39

coercion but attraction. The aim is to make people want to

come to work. Plus the subtle pressure to come should come
primarily from the team, not from the boss.
Usually people are not used to this kind of approach. In
the teams I was managing a new hire was usually coming to
me sooner or later to tell that he would come late tomorrow
for whatever reason. I would usually look at him with
utmost surprise and then say something like: Hey, why
you bother me with this? You have keys, you can come
whenever you want. Go and talk to your teammates if they
wont miss you on the standup. All I care for is the product
you build and how good your contribution is. Developers
are smart, so usually once was enough.
Keep in mind though that you dont want just any
kind of balance you want a healthy balance. If you
notice someone working long hours, coming to the office
on Saturdays (or - worse - also Sundays), consistently
checking code in at weird hours etc. it may be a good idea
to have a word with that person in private. It is a delicate
topic and you can discover things that may be hard to deal
with, but it is a good idea to express concern and ask what
is going on since that person is clearly on a path to quick
burn out and that doesnt help the company in the long run.
Keep the structures simple
As long as you have just one small team there is no
Once during such a conversation I discovered a developer just got dumped
by his girlfriend and that was his way of getting over it. This was of course not
the worst choice he could make - drinking heavily etc. would have been much
worse - so for a while it was ok, but if he continued like this for more than a
month or two I would try to find some help for him.

Management

40

need for any structure. With more teams structures are a

necessity. However, they come at a cost. Keep them simple.
Elaborate structures of traditional organizations serve
the purpose of breaking down ideas conceived on the top
and turning them into precise marching orders for the
troops once those ideas filter down the hierarchy. In Agile
we want teams to figure out answers to clients needs and
problems through empiricism and in close contact with
the clients and users. Therefore the need for an elaborate
structure is largely gone.
However, if we have more than a handful of teams
(somewhere above 40-50 developers) some structure becomes necessary for the work to proceed in an organized
fashion.
While the detailed discussion of scaling agile methods
is beyond the scope of this book it is worth noting that the
scaling problem has three key dimensions:
product - ensuring the product works at the end of
each iteration,
communication - ensuring the teams talk to one
another while working, discovering and negotiating
away any overlaps in their work,
requirements - ensuring all teams get requirements
that result in a valuable working product at the end
of each iteration.
Two first dimensions have very simple solutions. Continuous Integration (or even Continuous Deployment) is
the only way to ensure the product stays working (tested,

Management

41

integrated). Fostering communication through different

types of inter-team meetings or soft structures (guilds,
competence groups, Scrum of Scrums etc.) is the way to
solve the challenges of the communication dimension.
The key problem of Agile scaling is in the third
dimension - that of managing requirements. All different
solutions available on the market of ideas fall into two
broad categories:
autonomy - teams are fairly independent (autonomous)
within a part of the product, having end-to-end repeatability for it technically and lots of responsibility
for it in terms of functionality and other aspects of
user experience,
hierarchy - a hierarchy of people responsible for analyzing (understanding, decomposing) requirements
and making key technical decisions (eg. which module/area to implement given feature in and how) is
feeding teams with fairly detailed descriptions of
what to do, teams can only decide implementation
details within their realm of competence.
There is absolutely no doubt in my mind that it is first autonomous - approach that is more agile. It better employs
everyones intelligence and knowledge, it leads to products
that are superior not only technologically but also in terms
of meeting clients/users needs.
Unfortunately, autonomy it is usually not possible for
older companies with legacy products - the ones usually
trying to undergo an agile transformation. It is not only

Management

42

hard culturally for people used to a wholly different way

of living their work lives. Usually the product itself - its
architecture, quality and composition - is a much more
limiting factor. If the product is monolithic, with lots of
dependencies, poor or non-existent delineation between
layers etc. it may be close to impossible to be able to work
independently on its functional slices at the same time
keeping the whole integrated, tested and releasable.
If that is the case some level of hierarchy is necessary.
Despite all the problems it brings (and the inherent risk
of being potentially a sprout of waterfall command-andcontrol re-emerging) it is usually an improvement.
A startup - or a newly created part of a larger organization - starting a new (green field) product doesnt
have those limitations. It can from the start choose product
architecture and team organization that will support agility
and wont become a hindrance further down the road.
Make the team the primary unit of your structure
If we want people to work collaboratively in teams then
the team must be the primary unit of the organizational
structure. It is the team that should have responsibility for
a clearly defined part of the product, it is the team that
should be assessed and rewarded, it is the team that should
have its physical space - and maybe even a name.
Of course, some other structures will be needed too,
but the team that actually works together on a chunk of
product should be the primary allegiance of all involved.
Encourage internal knowledge sharing
One common reservation about putting emphasis so

Management

43

much on the teams is that this would hinder intra-team

communication therefore limiting knowledge sharing and
impeding keeping standards. This is a very real, valid concern. Active efforts must be undertaken to prevent teams
from drifting too far apart from each other.
Apart from ensuring the are areas in the office where
inter-team collaboration could occur following techniques
may help:
horizontal specialty teams - while the primary unit
for everyone is the team the work in on a part of
the product everyone could be a member of another
team, one grouping specialists in one field (like C++
or testing or databases etc.). That secondary team
is responsible for technical standards that should
be applied across teams (prime example would be
the coding style/standard) as well as professional
development of its member.
internal mini-lectures - people should be encouraged
to share what they learn with others, for example by
leading a mini-lecture. This can be practiced within
specialty teams or independently. At Code Sprinters it was customary that someone would deliver a
small, 30 mins. talk every month followed by a Q&A.
This not only helped spreading knowledge, but also
allowed developers to exercise presenting skills in a
friendly environment.
internal un-conferences - in bigger organizations a
biannual or at least annual company-wide informal

Management

44

conference (a day with lectures, workshops and some

time for socializing) is an excellent idea.
Encourage community involvement
Involvement of developers (and other professionals
in the company) in wider communities related to their
specialty and technology used should be supported by
the company. People should be encouraged to present
at conferences and contribute to open-source and other
community projects.
This serves three purposes:
increased motivation - ability to be perceived as a
master among peers as well as show off accomplishments is a powerful, positive motivator,
sustaining positive image - the company perceived
primarily through its products and services, but its
perception amongst professionals is also influenced
by conference talks, open-source and other community contributions etc. For example, Google is seen as
a cool place not just because of its perks and famous
products, but also because of its contributions to the
overall development of software engineering,
paying off debt - with open-source and other communitydeveloped projects being now used in almost every
software products there is a moral obligation, especially on successful companies, to pay back for what
they have been given primarily by contributing.

Management

45

Hiring
Hire people based on attitude first and skills second
This is I think one of the most important learnings from
my career as a manager and entrepreneur: it always paid
off to choose young, talented people motivated to learn and
grow over seasoned professionals.
In my experience skills are overrated and diplomas &
certificates are almost worthless. What counts is the mental
ability to understand the complexity inherent in software
development and the will to use that capacity. With enough
will all skills can be learned, without it all skills are useless.
Of course if someone is claiming to posses this or that
skill or experience it is worth checking it. But what you
are checking mostly is the persons honesty and accuracy
of their self-assessment. This part is best left to the team
- they have a current understanding of technologies used
and skills needed, something a boss - even if he was a
Recently I have tested this principle on salesmen. We first engaged an HR
agency and tried to find a professional sales person to drive the sales of our agile
training/coaching services. After going through a number of potential candidates
and even hiring two (and wasting a lot of money on their wages during their trial
months) we decided to employ a guy who was still studying, was willing to work
for a small salary and was intelligent. Within a year he sold more than any of
the professionals.
I always hired smart people with diverse interests and wide knowledge in
the field (in fact, to be honest, most of developers who worked with me were way
smarter than me), so it was hard to pretend you know something without it being
discovered on the interviews. I remember a guy who claimed in the CV that he
is an Erlang enthusiast (he actually listed that as one of his interests). Unluckily
for him one of the interviewing developers was indeed an Erlang aficionado so
with genuine joy at having met another fan of this exotic language he started:
I see you too like Erlang, so you will surely tell us how . I just could see the
candidates face getting long. Of course we didnt hire him.

Management

46

programmer in his past - would usually not have.

As for the experience it is of course a positive thing,
especially the general life experience. People who are more
mature are usually better at interacting with others having
practiced that for a longer time. I cant now recall where
I did see it, but I remember one company that openly
said that they prefer to hire adults. This may be difficult
nowadays when so many people want to be teenagers as
long as possible, but a certain level of maturity is definitely
something to look for.
Technical experience can be less valuable, not only
because technology changes, but also because there is a risk
of falling into ruts of same patterns.
Keep the team balanced
By balanced I dont mean just balanced in terms of
skills. Your development team is not a code-producing
machine but a group of humans. And both research and
anecdotal evidence show that teams that are more diverse
while sharing certain common values are more innovative,
productive and stable than teams built of similar people.
For example I have always striven to have some developers on the team who were not typical geeks. It is also
great to have women on the team, the problem is that there
are so few of them in the industry they are quite hard to
find. If you have a chance to have someone from a different
country/culture - go for it too (just make sure they speak
This doesnt exactly translate into age. I have worked with a guy who was
almost 30 and still just an older teenager and I work with a fellow who is only
23 yet is much more serious and mature.

Management

47

your language well enough for the communication in the

team to flow unhindered).

Planned extensions
This book is still in progress - in true LeanPub spirit it is
being changed and updated all the time. Further fate of this
work depends on feedback I will receive. If it turns out those
ramblings are of any use for at least some people/teams,
then I will expand further including following sections:
Building from scratch - how to build your first team,
basically a story based on my experiences when
building teams,
Growing up - some musings on approaches to keeping things agile and humane as your company - and
your teams - grow.
If you have any feedback (positive or negative) please
do me a favor and invest 10 minutes of your time to send
it to me under akbrandt@gmail.com.

About the author

Andy Brandt is a manager and technology team leader with
more than two decades of experience in the IT and telecoms
sectors. His diverse experience includes both work for large
multinationals and involvement in five startups ranging
from a computer magazine to software company.
Empathy and collaboration form the crucible of Brandts
teachings on technology. His focus was always highly motivated, engaged teams of various IT professionals - ranging
from network administrators to software developers.
Brandt has been involved in the Agile movement since
2006. He achieved national recognition as the first certified Professional Scrum Trainer in Poland and has been
instrumental in popularizing Scrum in that country. In
2007 Brandt founded Code Sprinters, an Agile software
development company which is now the leading provider
in Poland of training&consulting in Agile methods.
Above all, Brandts greatest joys are his wife and young
daughter. He is a prolific writer and you can find his most
recent articles on his blog, The Pragmatic Leader.

http://pragmaticleader.net