Professional Documents
Culture Documents
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
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
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
Principles
Principles
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.
Physical environment
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
Physical environment
Physical environment
10
Physical environment
11
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
Physical environment
14
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
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
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
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
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.
Physical environment
22
Physical environment
23
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
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
Management
27
Management
28
Management
29
Management
30
Management
31
Management
32
Management
33
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
Management
36
Management
37
Management
38
Management
39
Management
40
Management
41
Management
42
Management
43
Management
44
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
Management
47
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.
http://pragmaticleader.net