Development Team management

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: 

1. recognition of the transformation process as a long-term investment on the organizational level
2. conscious execution of the transformation as a part of a particular carefully selected project
3. project sponsors fully aware of the attempt of the transformation
4. well defined sponsors of the transformation
5. 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.