Management of Development Team


Published on

Management of Development Team - an article published in Agile Record, issue #9, Feb, 2012

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Management of Development Team

  1. 1. The Magazine for Agile Developers and Agile TestersTesting challenges for distributed team February free digital version made in Germany ISSN 2191-1320 issue 9
  2. 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
  3. 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 freea 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 developmentin the current model and the proposals for change via the chan- team’s self-organization. See Mike Cohn’s book Succeeding withnels 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 approachNotice 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 forlatter 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-drivencarefully, 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 individualsand those development team members who have become used and acceptance of responsibility by them. As a result, the PM’sto the prevailing reality. They will hide their impedance for change position is, by design, in the area of facilitating the above notionsand preference to stay in their comfort zone behind arguments more than anywhere else. Yes, Agile defines self-organization aspraising the value of existing processes and culture. For them it its built-in development team management model, not leavingis 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, orto change management. My recommendation in such cases is should I say by the nature of the agile development managementto start work on altering organizational culture using existing channels dedicated for such purposes. The changes toexisting reality will be much easier to push through and commu- So far, so good – here comes the difficult part: Self-organizationnicated 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? BecausePMOs, 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 forThe second approach – PM encouraged or PM moderated self-or- this. For some reasons a development team may not be matureganization – is the complete opposite of the micromanagement enough to accept the challenge. The root cause may be eitherapproach. 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 notpects 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, thePM’s duty is to answer question of what and when, and develop- One of my favorite quotations, originating from eastern culturement team’s duty is to answer questions of how. From the devel- says: Achieving your goal does not matter; it is getting thereopment team’s perspective, such an approach opens doors for which matters. The whole journey of getting there to the stage ofall the good things. It values the intelligence of individual team mature self-organization of development teams in its full extentmembers and lets them reveal their intellectual potential. It gives starts from the team’s initial immaturity and complete relianceindividual team members a chance to become fully productive on a project manager. Getting there is a process that takes timeand empowered. At the same time, the ability to make decisions and needs sponsors, and as such getting there should be treatedleverages 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 takeThe above work environment models a team’s world according place at the organization level and be conducted as a change ofto one of the key principles for managers to transform business organizational culture.effectiveness given back in the 1980s by W. Edward Deming: itremoves barriers that rob people in engineering of their right to So before overeagerly claiming that your organization is agile, (aspride of workmanship. too many organizations do nowadays), just because daily stand- ups are implemented here and there, I recommend you to takeFrom a PM’s perspective, the team’s self-organization takes the 2’s thinking a few levels higher to a wider timescale perspec- Wesley-Signature/dp/0321579364/ref=sr_1_2?s=books&ie=UTF8&qid=13tive which allows focusing attention to the systematic long-term 18024887&sr=1-2%29 69
  4. 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 make the change in steps. 4 ment70
  5. 5. During the transformation you need to constantly take into ac- turity level. Having identified the match, one then needs to find acount that getting there needs changes to the organization’s PM capable of managing the development team according to theculture as well as mental changes of individuals. You may need above parameters.organizational help in this aspect. Side note 2: Attempts of unificationSummary As usual, one needs to be careful and resist the temptation ofScrum 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 thephase. The underlying scientific models of the team evolution opposite. A degree of formalization of project management andwere 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 cansay, it was for me! One may ask: But wait, weren’t we told that be made uniform like delivery methodologies, there are otherAgile is a simplified version of managing development? That it is factors that cannot be made uniform. I can see at least threeall lightweight and straightforward to use?! Well, yes, I am sure different groups: 1. The above-mentioned human nature specificyou were told all this... I am just not sure you were ever told about factors characterizing individual PMs, 2. Human nature specificthe work and time necessary to build a team’s maturity level high factors characterizing individual team members, and 3. A varietyenough 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 inbad-old habits – the way organizations got used to working. For the right place on the whole spectrum of choices rather than onyears 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 andmoney 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 assessmentprofessional situation. of the best matching project execution model from the same spectrum of choices. However, the assessment is not done bySide note 1: Planning management of development team in a PM and is made implicit to a PM. Instead, the PM is given aan 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 graspaging 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 thea very individual thing originating from a mixture of factors char- long term.acterizing an individual PM: domain knowledge, personality andexperience in terms of work environments, teams, methodolo-gies, contractual models, etc. > About the authorOn the other hand each organization has worked out its level ofmaturity throughout the years of its existence. Again, it is quite Piotr Trojanowskian individual thing originating from a mixture of factors: how pro- has been leading agilejects were executed in the past, how mature teams are, and also software projects for 4the company’s culture. years. As Scrum practition- er (since 2006) and CSMA 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 andmaturity and culture is always there. agile project management. He authors a popular blogSo how should an organization plan the management of develop- on agile software projectment teams in order to execute projects successfully or at least management: a controllable manner? You may contact him at piotrtrojanow-, one needs to select a development team management ap-proach corresponding to the assessed development team’s ma- 71