Project managers in IT departments have well-established ways of describing the different phases of a development project, depending on the methodology. It all looks very scientific, but forgets the fact that project teams are just groups of people that, like any other human group, don’t always behave in rational ways. This has been well-known to the psycho-dynamic psychologists who studied group behavior, such as Kurt Lewin , Bruce Tuckerman and Wilfred Bion. The group dynamic of working teams, they noticed, tends to run in phases. (eg. Forming, Storming, Norming, Performing , Adjourning. Tuckerman 1965<\/i>). When groups are under pressure, these phases are different, and much less adaptive.<\/p>\n
I’ve had plenty of experience, both as members of IT teams, and managing them, and it has convinced me over the years that the group dynamics of a development team under pressure are neglected at your peril: Even a well-led task-oriented group has to be very carefully ‘facilitated’. You may, as a project manager have got ticks in all the boxes, and the team that does the development may, as individuals, be perfectly sane and well-adjusted, but the group can, when set to a task for up to 60 hours a week in difficult conditions, go completely barking mad.<\/p>\n
A development team that is being poorly led, facilitated and directed seems to me to revert so something more like pack behavior, and tends to go through the following phases, led usually by the pack members exhibiting the most ‘alpha-male’ characteristics. <\/p>\n
The excitement of a project infects the group. Developers flirt with new frameworks and technologies; everything seems possible and the timescales seem ridiculously generous. Beautiful, crafted objects and routines are designed, full of comments. Standards that conform to the industry’s best practices are decided, and resolutions about meticulous testing are made. Savvy business managers always choose this phase to introduce extra scope into the project. It will be embraced by the participants.<\/p>\n
This is a brief phrase: so brief that its existence is controversial, like the Quark. The first seeds of doubt resound around the group with positive feedback, and the celebratory Gluhwein flush suddenly leaves the cheeks. The sheer angle of the project path home sinks in, and suddenly confidence collapses. <\/p>\n
The mood of the group has flipped suddenly, and despair grips the team. The natural competitiveness within the group focuses on the race to come up with the most doom-laden predictions for the project. Developers mutter amongst their colleagues about the utter shambles of the state of the project. Testers get over-excited when they find bugs, and make huge lists, wringing their hands like Ancient Greek professional mourners. There is much puzzlement over the increase in the projects’ scope. (See: Festinger’s concept of Cognitive Dissonance)<\/p>\n
This is the phase of the project where a mob consciousness takes over. The mob thrashes around looking for someone to blame for their state of despair and doom. (cf Lloyd Demaus’s classic analysis of the Nixon Tapes). The obvious candidates are those developers who have got on quietly despite the excitement around them and consequentially done the most work, as they, logically, have created the most bugs. The DBA usually makes a good candidate too, as they will have been reluctant to have supported the radical domain-specific data-model that had been proposed by the developers when heady with euphoria, and will be viewed by the group as being reactionary. Sacrifices to the fates are planned to assuage their anger. Anyone with an urge for professional assassination of their colleagues does well to choose this phase; a negative remark always hurts most when delivered mid project.<\/p>\n
After the switchback ride of elation and despair, reality breaks in. Depending on the nature of the reality, this could be more uncomfortable for the group than the previous psychotic despair. They weep for the lost opportunities of the euphoric phase, and tremble at the closeness of the deadlines. The taste for retribution vanishes.<\/p>\n
With all creative energies now spent, the group decides that fate has decreed a long trudge to project completion, and there is a weary acceptance of this fact. Even realistic and helpful technical solutions are shrugged off, since their doom seems inevitable and inescapable. They develop a touching but misguided faith in technologies of their youth and innocence, as they become more introspective and passive, in final acceptance of their fate.<\/p>\n
Most likely, at some stage in the death-march, the entire project will be put out of its’ misery by IT management. If, however, the survivors reach home base, then the bitter recriminations will start as to whose fault the debacle was. This seems to be a cleansing process since there is no longer any taste for retribution for anyone perceived to be guilty. In fact the cleansing process is so effective that the participants develop a curious amnesia about the mistakes of the project, and the delusions they suffered. The developers are ready for the next project where, in the first heady stage, euphoria will once again grip the team.<\/p>\n
When we, as an industry, develop a new development methodology, I always hope, vainly, that the basic lessons of successful team working have percolated to the IT industry. It is always a bitter disappointment to me to discover that we continue to ignore the basic pressure points that prevent people in groups from working productively together, even when all the participants have the best of intentions.<\/p>\n
See: <\/p>\n
Project managers in IT departments have well-established ways of describing the different phases of a development project, depending on the methodology. It all looks very scientific, but forgets the fact that project teams are just groups of people that, like any other human group, don’t always behave in rational ways. This has been well-known to……<\/p>\n","protected":false},"author":154613,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"coauthors":[],"class_list":["post-2969","post","type-post","status-publish","format-standard","hentry","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/2969","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/154613"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=2969"}],"version-history":[{"count":2,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/2969\/revisions"}],"predecessor-version":[{"id":41840,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/2969\/revisions\/41840"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=2969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=2969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=2969"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=2969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}