The whole range of various approaches to managing development team extends
between two ends: PM-centric micromanagement and PM encouraged
self-organization. One may expect a tendency that junior PMs more often
start from the former one. Junior PMs stick strictly to controlling execution
of all micro-tasks as a result of their lack of appropriate level of trust
and/or courage to delegate work to development teams. As time elapses and
junior PMs gain more experience they gradually shift towards the latter option
of modelling self-organization of development teams facilitated by task
delegation and self-organization moderation techniques. The difference between
these two edge approaches boils down to a difference between feeding starving
people with fish and providing them with a fishing rod. Variety of intermediate
attitudes towards managing development teams exist between these two edge
approaches – the road to mastership takes time.
Let’s have a closer look into the two edge approaches first to then switch
to discussion of Scrum’s built-in team management model and organizational
aspects which need to be considered when deciding for appropriate approach of
development management for a particular project.
Micromanagement
The first approach – the micromanagement – focuses on addressing current
project’s and development team members’ needs and current matters. PM is highly
involved in all current issues irrespective of how minor they are. S/he tries
to cover all aspects of a project and be involved in literally every activity
within the project. This is a natural approach for beginners who personally
commit to deliver a project. However such an approach creates handicaps for
other participants of the project. First of all it means that decision making
gets fully centralized on the PM. A Team lacks motivation for proactive
behaviours as nothing can happen without PM's knowledge and decision. Thus the
Team switches to a passive mode of waiting to be assigned successive technical
tasks. Development team members focus on individual tasks that get assigned to
them. This is very uncomfortable for individual team members as it
significantly limits their natural need to make use of their intellectual potential.
At the same time they focus less on business goals a Product Owner wants to
achieve. They shift this responsibility to PM as s/he keeps it all under
control. Some individuals like such setups because these let them stick to
their comfort zones. Some others do not like such setups as they, in some
sense, feel uncomfortable to compete with the PM for responsibility even if
they feel they are in a better position to handle particular area of the
project. Both cases are harmful to the project. Such environment, created by
over-acting PM, seriously decreases development team’s empowerment and
commitment. A Team can never become more mature under the above circumstances –
it is simply not given a chance to grow its maturity.
This mode of PM work is called micromanagement approach to development team management and project management in general.
(BTW I think Wikipedia takes it to extreme referencing obsessive–compulsive
personality disorder as the root cause for micromanagement practices and
behaviours). Personally I also call this approach PM-centric management
as opposed to team centric management. It is needless to say that
micromanagement has destructive results in long term, not only negative
connotations. In fact micromanagement is one of the classic managerial
anti-patterns.
Please notice that a need for micromanagement may originate not only from
PM, but also from development team. Usually this is the case with just-created
teams that are still progressing on their way to establish initial
self-organization or teams that expect to be micro-managed based on past
experience. The former case is pretty healthy – development team can and should
expect a PM to support them towards mature self-organization. After all, it is
one of major goals of PM’s work. The latter case, on the contrary, is a clear
sign of malformed organization culture and solving it is more of a matter of
organizational effort to change the existing culture. A PM should discuss
limitations s/he sees in the current model and her proposals for change using
channels and mechanisms existing in a company for these purposes rather than
begin a lonely struggle with introducing the culture change locally.
Notice that as long as the former PM's approach will be perceived well as a
proactive action to building company’s culture, the latter approach can be
assessed as an individual battle against the rest of the world. Any attempts of
PM to change the culture locally – exclusively in his projects – must be
undertaken very carefully and as a matter of fact have limited chances to be
successful. Such attempts may result in tensions between a PM and those of
development team members who got used to the so-far reality. They will hide
their impedance for change and preference to stay in their comfort zone behind
arguments praising value of existing processes and culture. For them it is more
of a PM problem to adjust to the existing organization culture. This is all
understandable. Avoiding the change is quite natural for some of us and one of
quite reasonable approaches to change management ;). My recommendation in such
cases is to start work on altering organizational culture using existing
company’s channels dedicated for such purposes. The changes to existing reality
will be much easier pushed through and communicated to teams by people /
committees / bodies widely recognized as accountable for area of organization
culture, i.e. heads of practices or heads of project management, PMO, etc.
Self-organization of Development Team
The second approach – PM encouraged / moderated self-organization – is a
complete opposite of the micromanagement approach. This is a Team-centric
approach. In this approach a PM lets Development Team take full ownership of
technical aspects of a project. PM herself stays at a level of business
requirements and not their technical solutions. In other words PM’s duty is to
answer question What and When? and Development Team’s duty is to answer question
How? From the Development Team’s perspective such approach opens door for all
the goodness. It values intelligence of individual team members and lets them
reveal their intellectual potential. It lets individual team members gain a
chance to become fully productive and empowered. At the same time ability to
make decisions leverages everybody’s commitment and responsibility to deliver
high quality software.
The above work environment models a Team world according to one of the key
principles to managers for transforming business effectiveness given back in
1980s by W. Edward Deming - it removes barriers that rob people in engineering
of their right to pride of workmanship.
From a PM’s perspective Team's self-organization takes PM’s thinking a few
levels higher to a wider timescale perspective which allows focusing attention
to systematic long-term resolution of core managerial issues and process
improvements. A PM's mind is reliefed from the burden of low-level details and
free to focus on core aspects of her work. Still a PM remains 100% responsible
for moderating the process of development team self-organization. See Mike
Cohn’s Succeeding with Agile book for discussion on PM’s options to
influence Team’s self-organization.
Scrum’s built-in approach
The Agile methodologies rely deeply on the notion of self-organizing teams.
In fact, self-organization is a core building block for all of them. There is a
clear shift of responsibility down onto individual members of Development Team.
The world is not PM-driven and not PM-centric anymore - the world is Team-driven
and Team-centric. PM is not a member of a Team anymore. This is
only possible through empowerment of individuals and acceptance of
responsibility by them. As a result PM’s position is, by design, in the areas
facilitating the above notions more than anywhere else. Yes, Agile defines
self-organization as its built-in development team management model, not
leaving much space for PM to choose his favourite development management model.
Agile PMs fall into PM-moderated/encouraged self-organization approach by the
nature of things, or should I say by the nature of the Agile development
management model.
And here comes the difficult part – self-organization it is not granted for
free to every organization starting from day one – Agile does not work
out-of-the-box, one cannot switch from waterfall to Agile with a single
managerial decision. Why? Because Agile needs mature Teams that are ready to
accept responsibility as decisions will not be coming down from a PM in a
ready-to-process form any more. Your development team may not be ready for
this. For some reasons a development team may not be mature enough to accept
the challenge. This can have root cause in either some reason internal to the
team, e.g. lack of experience, sticking to good-old habits or equally well in
shortcomings of a PM not fully facilitating agile management responsibilities.
One of my favourite quotations, originating from eastern culture says: Achieving
your goal does not matter; it is getting there which matters. The whole
journey of getting there to the stage of mature self-organization of
development teams in its full extent starts from initial team’s immaturity and
complete reliance on a project manager. Getting there is a process that takes
time and needs sponsors and as such getting there should be treated as a
long-term investment in ability of the organization to deliver quality
software. There is no doubt about it - getting there to mature teams'
self-organization is a process that needs to take place on the organization
level and be conducted as a change of organizational culture.
So before overeagerly claiming your organization is Agile, as too many
organizations do nowadays, just because there are daily standups implemented
here and there I recommend you to take a conscious and responsible approach to
take a step back and see where you are. The first step is to accept the
fact that getting there needs practice towards reaching the state where
the self-organization has a chance to succeed.
Self-organizing Teams - preparation
It would be really optimistic to assume that the process of leading your
team to full maturity is your individual decision and that it can be happening
during project execution at arbitrary time of your choice. More realistically various
factors need to be taken into account. It matters whether you work for software
vendor or in an internal IT department of a non-IT company. It matters what
delivery model you are obliged to follow – this can be anything between Fixed
Price Fixed Time and Time & Material. Finally it matters who your sponsor
is and what his needs are. What is the sponsor’s level of awareness wrt goals
of the transformation? Is your sponsor ready to accept additional time and
money spend to go through the transformation process to pay off in a long-term
by increased ability of your team to deliver quality software? The key pre-requisite
factors of the transformation process that need to be agreed up-front are:
- recognition of the
transformation process as a long-term investment on the organizational
level
- conscious execution of
the transformation as a part of a particular carefully selected project
- project sponsors fully
aware of the attempt of the transformation
- well defined sponsors of
the transformation
- level of transformation
transparency agreed with project sponsors
In my opinion it takes very conscious and mature client to understand long-term
benefits of the transformation. It is even harder to find a sponsor who,
understanding the need, decides to go for it – very rarely sponsors themselves
are rewarded for long-term results. Speaking from my experience, after 10+
years of Scrum on the scene, it is still difficult to step across such mature
clients and organizations. Agile became attractive and well perceived as a sales item
in RFPs, but this is rarely reflected on project management level.
One other thing is worth noticing when considering the transformation – in the
aforementioned book Cohn is able to plot a diagram showing level of Scrum
Master’s involvement throughout a process of Team’s way to full maturity. As
one can expect the initial involvement starts on highest level to fall down to
lowest levels when the transformation is done.
Self-organizing Teams - Getting there
If you are given a chance to grow you team by project sponsors – take it –
it may not repeat for the second time. You may wish to make the change in
steps.
The classic Hersey’s and Blanchard’s team leadership model - Situational Leadership theory may be of help. The SL Model defines four
phases of team’s evolution and PM’s involvement in leadership:
· Telling – full Team reliance on PM and his instructions,
· Selling – PM gradually buys Individuals into the decisive process,
· Participating – shared decision making between PM and Team, and
· Delegation – Team fully responsible for decisions
As one can see Telling level corresponds to the micromanagement approach
while Delegation level corresponds to Agile’s PM encouraged self-organization
approach. Selling and Participating intermediate phases let you drive the
transformation more smoothly.
In parallel, Tuckman's stages of group development aka Forming-Storming-Norming-Performing model of group development may be of help. Again, the model is based on four phases in which the corresponding PM's role is defined:
- Forming - the forming of the team takes place; Supervisors of the team tend to need to be directive during this phase.
- Storming - different ideas compete for consideration; Supervisors of the team during this phase may be more accessible, but
tend to remain directive in their guidance of decision-making and
professional behavior.
- Norming - The team manages to have one goal and come to a mutual plan for the team at this stage.
- Performing - It is possible for some teams to reach the performing stage.
These high-performing teams are able to function as a unit as they find
ways to get the job done smoothly and effectively without inappropriate
conflict or the need for external supervision. By this time, they are
motivated and knowledgeable. The team members are now competent,
autonomous and able to handle the decision-making process without
supervision. Supervisors of the team during this phase are almost always participative. The team will make most of the necessary decisions.
Backbone idea driving the above models is that Team has a lifespan, it needs time to grow mature and it needs help on its way to maturity. Please notice that the kind of help they need has nothing to do with micromanagement. The process of growing mature is not driven by any sort of a PM -it is a natural process. All they need from a PM and Organization is encouragement, motivation, freedom, moderation and support.
During the transformation you need to constantly
take into account that getting there needs changes to organization’s culture as
well as mental changes of individuals. You may need organizational help in this
aspect.
Summary
Scrum,
as well as other Agile development methodologies, like Kanban, are based on
most mature Team organization level – delegation aka self-organization. The underlying
scientific model of the team maturity phases was created back in 1970s by
behavioral scientists. I will not be surprised if this is eye-opener for many
of you. It was for me too! One may ask: But wait, weren't I told that Agile is
a simplified version of managing development? That it is all lightweight and
straightforward to use?! Well, yes, I am sure you were told this all... I am
just not sure you were ever told about the work and time necessary to build
Team's maturity level high enough to fulfill Scrum's pre-requisites and most
importantly – how to get there.
I
personally believe that this work is only necessary because of bad-old habits -
the way organizations got used to work. For years people were told exactly the
opposite – to follow the instructions from one’s boss and not to think too much
about wider perspective - the exact copy from the Ford's production model.
Luckily some of you work in organizations understanding a need for continuous improvement
and willing to invest time and money in researching ways to improve business
effectiveness. If you are not that lucky - find some time to re-think your
current professional situation.
Side note 1: Planning management of development team in Organization
Having said that there exists the whole spectrum of approaches to managing
a development team, one needs to notice that every PM has its own preferred
approach to managing teams. This is something s/he has worked out throughout
her career. It is a very individual thing originating from a mixture of factors
characterizing an individual PM: domain knowledge, personality and experience
in terms of work environments, teams, methodologies, contractual models, etc.
On the other hand each organization has worked out its level of maturity
throughout the years of its existence. Again, it is quite individual thing
originating from a mixture of factors: how projects were executed in the past,
how mature teams are, and also the company’s culture.
Team’s maturity always reflects company’s maturity. The same is also true
for Team’s culture. There exist differences between individual teams, but the
correlation with company’s maturity and culture is always there.
So how should an organization plan management of development team in order
to execute a project successfully or at least in a controllable manner?
First one needs to select a development team management approach
corresponding to the assessed development team’s maturity level. Having
identified the match one then needs to find a PM capable of managing the
development team according to the above parameters.
Side note 2: Attempts of unification
As usually one needs to be careful and sustain temptation of making
assumption that projects are executed uniformly across the organization. I
think it is much safer and feasible to assume the opposite. A degree of
formalization of project management and software delivery methodologies does
not influence the uniformity of project execution much. Please notice that
except from the factors that can be uniformed like delivery methodologies there
exist factors of other natures that cannot be uniformed. I can see at least two
groups of these: 1. the above mentioned human nature specific factors
characterizing individual PM, and 2. variety of business domains and characteristics of clients
for which projects are executed.
Unification of project execution should focus on pointing a PMs the right
place on the whole spectrum of choices rather than on nailing down a list of
uniforming rules and / or processes. The approach to development management selected on
the scale of options should be the one most closely corresponding to company’s
reality at the current level of growth and maturity.
Notice that the not recommended approach of producing lists of uniforming
rules / processes is also based on assessment of the best matching project
execution model from the same spectrum of choices. However the assessment is
not done by a PM and is made implicit to a PM. Instead a PM is given a
hardcoded list of processes produced based on the implicit assessment. As a
result a PM does not have a chance to understand to full picture, and
underlying layers of logic, but is limited to follow the already processed
information. This can be and usually is quite misleading and what is worse
leads to nowhere in the long perspective.
