This document discusses different approaches to managing development teams, ranging from micromanagement to self-organization. It argues that teams need time and support to mature and become self-organizing. Junior project managers may start with micromanagement but should gradually shift towards encouraging self-organization as they gain experience. True self-organization is the goal of agile methodologies like Scrum, but organizations need to consciously support teams' development over the long term through this process rather than expecting immediate results. The optimal approach depends on factors like a team's experience level and an organization's culture.

1. The Magazine for Agile Developers and Agile Testers
Testing challenges for distributed team February 2012
www.agilerecord.com free digital version made in Germany ISSN 2191-1320 issue 9

2. Management of Development Team
by Piotr Trojanowski
The whole range of different approaches for Project Managers bers focus on individual tasks that get assigned to them. This
(PM) for managing development teams extends between two is very uncomfortable for individual team members as it signifi-
extremes: PM-centric micromanagement and PM encouraged cantly limits their natural need to make use of their intellectual
self-organization. One may expect that junior PMs tend to more potential. At the same time they focus less on the business goals
often start from the former one. Junior PMs stick strictly to con- that a product owner wants to achieve. They shift this responsibil-
trolling execution of all micro-tasks as a result of their lacking ity to the PM as s/he keeps it all under control. Some individuals
an appropriate level of trust and/or courage to delegate work to actually like this kind of set-up because it lets them stick to their
development teams. As time elapses and junior PMs gain more comfort zones. Others, however, do not like such set-ups as they,
experience, they gradually shift towards the latter option of mod- in some sense, feel uncomfortable about competing with the PM
eling self-organization of development teams facilitated by task for responsibility, especially if they feel they are in a better posi-
delegation and self-organization moderation techniques. The tion to handle a particular area of the project. Both cases are
difference between these two approaches boils down to the dif- harmful to the project. Such environments, created by an over-
ference between feeding starving people with fish or providing acting PM, seriously decrease the development team’s empower-
them with a fishing rod. A variety of intermediate approaches for ment and commitment. A team can never become more mature
managing development teams exist between these two extremes under the above circumstances – it is simply not given a chance
– the road to mastership takes time. to improve its maturity.
Let’s have a closer look at the two extreme approaches first be- This mode of PM work is called the micromanagement1 approach
fore switching to discussing Scrum’s built-in team management to development team management and project management
model and organizational aspects, which need to be considered in general. (In my opinion, Wikipedia takes it too extreme, refer-
when deciding on the appropriate approach of development ring to an obsessive-compulsive personality disorder as the root
management for a particular project. cause for micromanagement practices and behaviors). Person-
ally, I also call this approach PM-centric management as op-
Micromanagement posed to team-centric management. It is needless to say that
The first approach – micromanagement – focuses on address- micromanagement has destructive results in the long term, not
ing the current project’s and development team members’ needs only negative connotations. In fact, micromanagement is one of
and current matters. The PM is highly involved in all current is- the classic managerial anti-patterns.
sues irrespective of how minor they are. S/he tries to cover all as-
pects of a project and be involved in literally every activity within Please note that a need for micromanagement may originate not
the project. This is a natural approach for beginners who person- only from the PM, but also from the development team. Usually
ally commit to deliver a project. However, such an approach cre- this is the case with recently-created teams that are still pro-
ates handicaps for other participants of the project. First of all, it gressing on their way to establishing some initial self-organiza-
means that decision making gets fully centralized on the PM. As tion, or teams that expect to be micro-managed based on past
a result, the team will lack in motivation for proactive behavior, experience. The former case is pretty healthy – a development
as nothing is likely to happen without the PM’s knowledge and team can and should expect a PM to support them towards
decision. The team switches to a passive role and waits to be as- mature self-organization. After all, it is one of the major goals
signed successive technical tasks. The development team mem-
1 http://en.wikipedia.org/wiki/Micro-management
68 www.agilerecord.com

3. of a PM’s work. The latter case, on the contrary, is a clear sign resolution of core managerial issues and process improvements.
of a malformed organization culture, and solving it is more of A PM’s mind is relieved of the burden of low-level detail and free
a matter of organizational effort that is required to change the to focus on core aspects of the work. Still, the PM remains 100%
existing culture. A PM should discuss the limitations s/he sees responsible for moderating the process of the development
in the current model and the proposals for change via the chan- team’s self-organization. See Mike Cohn’s book Succeeding with
nels and mechanisms existing in a company for these purposes, Agile2 in which the PM’s options to influence the team’s self-or-
rather than starting a lonely struggle with introducing the culture ganization are discussed.
change locally.
Scrum’s built-in approach
Notice that as long as the former PM’s approach will be perceived The agile methodologies rely deeply on the notion of self-organ-
well as a proactive action to building the company’s culture, the izing teams. In fact, self-organization is a core building block for
latter approach can be assessed as an individual battle against all of them. There is a clear shift of responsibility down to the in-
the rest of the world. Any attempts of a PM to change the culture dividual members of the development team. The world is not PM-
locally – exclusively in his projects – must be undertaken very driven and not PM-centric anymore – the world is team-driven
carefully, and will as a matter of fact have limited chances to be and team-centric. The PM is not a member of the team anymore.
successful. Such attempts may result in tensions between a PM This is only possible through the empowerment of individuals
and those development team members who have become used and acceptance of responsibility by them. As a result, the PM’s
to the prevailing reality. They will hide their impedance for change position is, by design, in the area of facilitating the above notions
and preference to stay in their comfort zone behind arguments more than anywhere else. Yes, Agile defines self-organization as
praising the value of existing processes and culture. For them it its built-in development team management model, not leaving
is more of a PM problem to adjust to the existing organization much space for PMs to choose their favorite development man-
culture. This is all understandable. Avoiding change is quite natu- agement model. Agile PMs fall into the PM-moderated/encour-
ral for some of us, and one of the quite reasonable approaches aged self-organization approach by the mere nature of things, or
to change management. My recommendation in such cases is should I say by the nature of the agile development management
to start work on altering organizational culture using existing model.
company channels dedicated for such purposes. The changes to
existing reality will be much easier to push through and commu- So far, so good – here comes the difficult part: Self-organization
nicated to teams by people / committees / bodies who are widely is not granted for free to every organization starting from day one;
recognized as accountable for an area of organization culture, Agile does not work out-of-the-box; one cannot switch from wa-
i.e., heads of departments or heads of project management, terfall to Agile with a single managerial decision. Why? Because
PMOs, etc. Agile needs mature teams that are ready to accept responsibility
as decisions will no longer be coming from the PM in a ready-
Self-organization of development team to-process form. Your development team may not be ready for
The second approach – PM encouraged or PM moderated self-or- this. For some reasons a development team may not be mature
ganization – is the complete opposite of the micromanagement enough to accept the challenge. The root cause may be either
approach. This is a team-centric approach. In this approach a PM some reason internal to the team, e.g. lack of experience, stick-
lets the development team take full ownership of technical as- ing to good-old habits, or equally well shortcomings of a PM not
pects of a project. The PM herself stays at a level of business re- fully facilitating agile management responsibilities.
quirements and not their technical solutions. In other words, the
PM’s duty is to answer question of what and when, and develop- One of my favorite quotations, originating from eastern culture
ment team’s duty is to answer questions of how. From the devel- says: Achieving your goal does not matter; it is getting there
opment team’s perspective, such an approach opens doors for which matters. The whole journey of getting there to the stage of
all the good things. It values the intelligence of individual team mature self-organization of development teams in its full extent
members and lets them reveal their intellectual potential. It gives starts from the team’s initial immaturity and complete reliance
individual team members a chance to become fully productive on a project manager. Getting there is a process that takes time
and empowered. At the same time, the ability to make decisions and needs sponsors, and as such getting there should be treated
leverages everybody’s commitment and responsibility to deliver as a long-term investment in the ability of the organization to de-
high quality software. liver quality software. There is no doubt about it – the way to a
mature team’s self-organization is a process that needs to take
The above work environment models a team’s world according place at the organization level and be conducted as a change of
to one of the key principles for managers to transform business organizational culture.
effectiveness given back in the 1980s by W. Edward Deming: it
removes barriers that rob people in engineering of their right to So before overeagerly claiming that your organization is agile, (as
pride of workmanship. too many organizations do nowadays), just because daily stand-
ups are implemented here and there, I recommend you to take
From a PM’s perspective, the team’s self-organization takes the
2 http://www.amazon.co.uk/Succeeding-Agile-Development-Addison-
PM’s thinking a few levels higher to a wider timescale perspec- Wesley-Signature/dp/0321579364/ref=sr_1_2?s=books&ie=UTF8&qid=13
tive which allows focusing attention to the systematic long-term 18024887&sr=1-2%29
www.agilerecord.com 69

4. a conscious and responsible approach to take a step back and The classic Hersey’s and Blanchard’s team leadership model –
see where you are. The first step is to accept the fact that getting Situational Leadership theory3 may be of help. The SL model de-
there needs practice towards reaching the state where the self- fines four phases of a team’s evolution and the PM’s involvement
organization has a chance to succeed. in leadership:
■ Telling – Team’s full reliance on PM and his instructions,
Self-organizing teams – preparation
It would be really optimistic to assume that the process of lead- ■ Selling – PM gradually buys individuals into the decision
ing your team to full maturity is your individual decision and that process,
it can happen during project execution at an arbitrary time of ■ Participating – shared decision making between PM and
your choice. More realistically, however, various factors need to team, and
be taken into account. It matters whether you work for a software
vendor or in an internal IT department of a non-IT company. It ■ Delegation – Team fully responsible for decisions
matters what delivery model you are obliged to follow; this can
be anything between “Fixed Price Fixed Time” and “Time & Mate- As one can see, the Telling level corresponds to the microman-
rial”. Finally, it matters who your sponsor is and what his needs agement approach while the Delegation level corresponds to
are. What is the sponsor’s level of awareness with regard to the Agile’s PM encouraged self-organization approach. Selling and
goals of the transformation? Is your sponsor ready to accept ad- Participating intermediate phases let you drive the transforma-
ditional time and money being spent to go through a transfor- tion more smoothly.
mation process that will pay off in the long term by increasing
the ability of your team to deliver quality software? The key pre- In parallel, Tuckman’s stages of group development, also known
requisite factors of the transformation process that need to be as Forming-Storming-Norming-Performing model4 of group devel-
agreed up-front are: opment, may be of help. Again, the model is based on four phas-
es in which the corresponding PM’s role is defined, as described
1. recognition of the transformation process as a long-term
at Wikipedia:
investment at the organizational level,
■ Forming – the forming of the team takes place; Supervi-
2. conscious execution of the transformation as part of a
sors of the team tend to need to be directive during this
particular carefully selected project,
phase.
3. project sponsors that are fully aware of the attempted
■ Storming – different ideas compete for consideration;
transformation,
Supervisors of the team during this phase may be more
4. well defined sponsors of the transformation, and accessible, but tend to remain directive in their guidance of
5. a level of transformation transparency that is agreed with decision-making and professional behavior.
project sponsors. ■ Norming – The team manages to have one goal and come
to a mutual plan for the team at this stage.
In my opinion, it takes a very conscious and mature client to
understand long-term benefits of the transformation. It is even ■ Performing – It is possible for some teams to reach the
harder to find a sponsor who, understanding the need, decides to performing stage. These high-performing teams are able
go for it; very rarely are the sponsors themselves rewarded with to function as a unit as they find ways to get the job done
long-term results. Speaking from my own experience, after 10+ smoothly and effectively without inappropriate conflict or
years of Scrum on the scene, it is still difficult to come across the need for external supervision. By this time, they are
such mature clients and organizations. Agile became attractive motivated and knowledgeable. The team members are now
and well perceived as a sales item in Requests for Proposals competent, autonomous and able to handle the decision-
(RFPs), but this is rarely reflected at project management level. making process without supervision. Supervisors of the
team during this phase are almost always participative. The
One other thing is worth noting as a side note when considering team will make most of the necessary decisions.
the transformation. In the aforementioned book, Cohn is able to
plot a diagram showing the level of a Scrum Master’s involve- The backbone idea driving the above models is that Team has a
ment throughout a process of the team’s way to full maturity. As lifespan: it needs time to grow mature and it needs help on its
one can expect, the initial involvement starts at the highest level way to maturity. Please note that the kind of help they need has
and falls down to the lowest levels when the transformation is nothing to do with micromanagement. The process of growing
done. mature is not driven by any sort of a PM – it is a natural process.
All they need from a PM and an Organization is encouragement,
Self-organizing teams – Getting there motivation, freedom, moderation and support.
If you are given a chance from project sponsors to grow your
team, take it; it may not occur a second time. You may wish to 3 http://en.wikipedia.org/wiki/Situational_leadership_theory
make the change in steps.
4 http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_develop-
ment
70 www.agilerecord.com

5. During the transformation you need to constantly take into ac- turity level. Having identified the match, one then needs to find a
count that getting there needs changes to the organization’s PM capable of managing the development team according to the
culture as well as mental changes of individuals. You may need above parameters.
organizational help in this aspect.
Side note 2: Attempts of unification
Summary As usual, one needs to be careful and resist the temptation of
Scrum as well as other agile development methodologies, like assuming that projects are executed uniformly across the or-
Kanban, are based on the most mature team development ganization. I think it is much safer and feasible to assume the
phase. The underlying scientific models of the team evolution opposite. A degree of formalization of project management and
were created back in the 1970s by behavioral scientists. I would software delivery methodologies does not influence the uniform-
not be surprised if this is an eye-opener for many of you. I must ity of project execution much. Except from the factors that can
say, it was for me! One may ask: But wait, weren’t we told that be made uniform like delivery methodologies, there are other
Agile is a simplified version of managing development? That it is factors that cannot be made uniform. I can see at least three
all lightweight and straightforward to use?! Well, yes, I am sure different groups: 1. The above-mentioned human nature specific
you were told all this... I am just not sure you were ever told about factors characterizing individual PMs, 2. Human nature specific
the work and time necessary to build a team’s maturity level high factors characterizing individual team members, and 3. A variety
enough to fulfill Scrum’s pre-requisites, and – most importantly of business domains and characteristics of clients for which pro-
– how to get there. jects are executed.
I personally believe that this work is only necessary because of Unification of project execution should focus on pointing PMs in
bad-old habits – the way organizations got used to working. For the right place on the whole spectrum of choices rather than on
years people were told exactly the opposite – to follow the in- nailing down a list of uniform rules and / or processes. The ap-
structions of the boss and not to think too much about the wider proach to development management selected on the scale of op-
perspective – the exact copy from Ford’s production model. Luck- tions should be the one most closely corresponding to the com-
ily, some of you work in organizations which understand the need pany’s reality at the current level of growth and maturity.
for continuous improvement and are willing to invest time and
money in researching ways to improve business effectiveness. Note that the approach of producing lists of uniform rules / pro-
If you are not that lucky, find some time to re-think your current cesses that is not recommended is also based on an assessment
professional situation. of the best matching project execution model from the same
spectrum of choices. However, the assessment is not done by
Side note 1: Planning management of development team in a PM and is made implicit to a PM. Instead, the PM is given a
an organization hardcoded list of processes produced based on the implicit as-
Having said that there is a whole spectrum of approaches to man- sessment. As a result, the PM does not have a chance to grasp
aging a development team, one needs to bear in mind that every the full picture and underlying layers of logic, but is limited to fol-
PM has his/her own preferred approach to managing teams. This lowing the already processed information. This can be and usu-
is something s/he has worked out throughout his/her career. It is ally is quite misleading and, even worse, leads to nowhere in the
a very individual thing originating from a mixture of factors char- long term.
acterizing an individual PM: domain knowledge, personality and
experience in terms of work environments, teams, methodolo-
gies, contractual models, etc.
> About the author
On the other hand each organization has worked out its level of
maturity throughout the years of its existence. Again, it is quite Piotr Trojanowski
an individual thing originating from a mixture of factors: how pro- has been leading agile
jects were executed in the past, how mature teams are, and also software projects for 4
the company’s culture. years. As Scrum practition-
er (since 2006) and CSM
A team’s maturity always reflects the company’s maturity. The (since 2009), he special-
same is also true for a team’s culture. There are differences be- izes in agile software devel-
tween individual teams, but the correlation with the company’s opment management and
maturity and culture is always there. agile project management.
He authors a popular blog
So how should an organization plan the management of develop- on agile software project
ment teams in order to execute projects successfully or at least management: http://agile-software-management.
in a controllable manner? blogspot.com. You may contact him at piotrtrojanow-
ski@gmail.com.
First, one needs to select a development team management ap-
proach corresponding to the assessed development team’s ma-
www.agilerecord.com 71