Image credit: Laura Ockel
The third phase of Tuckman’s (1977) revised model of team effectiveness is known as ‘Norming’. This is the point in a team’s lifecycle where early conflicts are overcome and processes start to feel familiar. The team settles into a steady working cadence – ‘business as usual’.
In this post, I’ll be reviewing our state of play from the perspective of team leader, and deciding whether I deem us to be in ‘norming’.
As a team, I feel that we are coming together well. Morale seems to be high, and we’ve had no significant conflicts yet. I’ve recently found myself considering the possibility that team members might not communicate points of frustration out of fear they might disrupt the status quo.
I find it both an interesting and uncomfortable thought that the high morale I want to celebrate could actually invoke Lencioni’s second dysfunction: fear of conflict (lenioni, 2002, 188-189).
To ensure this doesn’t become the case, I should find ways of promoting communication. I recognise that our approach to team meetings could be improved. In my week 2 post, I discussed allowing room for natural discourse in team meetings to encourage cathartic conversation. I now think that it is not enough for me to leave room for such conversation. I should actively promote it.
In the coming weeks, I will attempt an asynchronous retrospective. Suri Patel (2019) recorded how they handle asynchronous retrospectives at GitLab, and shared the following observation:
“asynch retros can serve as a dedicated place where people can quickly jot down their thoughts when they suddenly remember an experience, rather than be forced to remember everything during a dedicated call.”
The indirect nature of asynchronous communication may help to reduce any pressure my team members might feel to maintain the illusion that ‘everything is fine’. Alternatively everything may well be going fine, and holding a retrospective will confirm that.
With regards to our progress on the project itself, I am concerned that the UX, development and artistic efforts are yet to coverge. By this point in the module, I had hoped to have delivered a playable prototype that adhered to a delivered wireframe.
After some deliberation, I believe our productivity is hampered by our task management, or lack thereof. We have a task board in Microsoft teams, but the tasks listed there don’t lead to a deliverable product.
Amos Haniff (2016, 106-107) states the following:
“project scope management involves describing the product, service or result of the project, and identifying the activities that need to be achieved in order to deliver the expected final outcome… The process of defining the project, in terms of deliverables, objectives, requirements and detail, becomes the responsibility of the project manager.”
I fear that, within my role as team leader, I have neglected the responsibility of managing the project. The task management I have implemented does not sufficiently afford Haniff’s definition of scope management. As a result, it is not clear to each team member how they should spend their time.
In the coming week, I will dedicate time to identifying the activities required to deliver our concept. At least, I will identify the activities that I know are required. Where the requirements aren’t clear, I will add ‘spike’ tasks to allow time for identifying solutions (Scaled Agile, 2021).
References
AMOS, H. 2016. Project Management. Oxford: Goodfellow Publishers, 106-107.
LENCIONI, P.M. 2002. The Five Dysfunctions of a Team: A Leadership Fable. 1st edn. New Jersey: John Wiley & Sons, 188-189.
PATEL, S. 2019. ‘How GitLab handles retrospectives’. GitLab [online]. Available at: https://about.gitlab.com/blog/2019/12/19/how-gitlab-handles-retrospectives/ [accessed 23/08/2021].
SCALED AGILE, INC. 2021. ‘Spikes’. Scaled Agile Framework [online]. Available at: https://www.scaledagileframework.com/spikes/ [accessed 23/08/2021].
TUCKMAN, B.W. & JENSEN, M.A.C. 1977. ‘Stages of small-group development revisited’. Group & Organization Studies, 2(4), 419-427.
Skoobin Design 