In creating and running software project teams, organisations typically give a lot of attention to establishing business cases, determining deadlines and budget, recruiting/selecting staff, adopting a methodology, and selecting technology.
But in times of uncertainty or when the going gets tough will the team thrive and grow stronger?
Or will they self-implode through pessimism, frustration, avoidance and resentment?
In the domain of individual and community mental health, resilience is the term used to describe how someone adapts to challenges and stress, as well as how well they recover from setbacks. Applying this definition to software project teams, what are some of the key things which determine a project team’s resilience?
Do the team members have a shared goal and a shared vision of what success looks like?
Everyone in a software project team has the potential to be busy. You can be busy working on what you personally prioritise. You can be busy following process even though the outcomes are substandard. You can be busy trying to get moved to a better project or department. You can be busy just wading through everything which gets pushed your way in a typical working week.
However, being busy by itself isn’t enough to build resilience in individuals or teams. It is goals, in particular shared goals, which give us both individual purpose and shared buy-in across a team. Goals also provide the high-level direction which the team can use to prioritise work, steer decision making, and align the contributions of the individuals.
Having a purpose is a key contributor to individual resilience. Having a shared purpose is a key contributor to team resilience. Goals are an expression of purpose and a shared vision is way to ensure everyone has a similar interpretation of those goals.
Does the team have an agreed method for working through problems and conflict?
Working through opposing sides of an issue in order to come to the best available resolution is a key strength of the best project teams. Successful teams have a healthy approach to working through conflict together, reaching an agreement, and moving on.
In some cases, this is supported by the project methodology, for example the Agile-based methodologies which include a regular team retrospective. In other cases, it is supported by having well defined roles and responsibility for decision making, or perhaps a try-test-assess cycle for when the team works through and evaluates different options. More important than the team using any particular approach is that the team has at least one approach which they actually use in practice.
It’s not uncommon for members of software project teams to have conflict averse personalities, and a desire to fit in can often lead to people not wanting to be labelled ‘the troublemaker’. Encouraging a team to work through problems instead of ignoring them will provide a huge advantage in the long-term. Unaddressed problems tend to grow, accumulate, and become intertangled – leading to ‘Conflict Debt’, the sum of all the contentious issues which need to be addressed but remain unresolved.
Are roles which were historically independent now transitioned into a collaborative form?
Historically, software development did not encourage collaboration. Most tasks and assessments in undergraduate degrees were focused on individual work, with any evidence of collaboration being punishable, considered a form of plagiarism. The remaining tasks which were group work would typically be tackled using a divide and conquer approach, splitting up responsibilities and requiring only minimal effort from group members to maintain an overall consistency.
Most project roles have successfully transitioned over the last 20 years into a more collaborative form. Examples include developers allocating time to pair programming and code reviews, testers sharing the repository of defined tests, and business analysts transitioning from an external and senior role into an embedded role focused on facilitation as a team equal.
In my opinion the various software architecture roles still have the biggest transition left to make. Speaking with other roles on software development projects, the same issue is typically raised –many architects assigned to work with a project team continue to fully position themselves as an independent authority outside of the team. Rather than share the goals, responsibilities and deadlines of the project team they will choose to function as an adviser, a reviewer, a cross-project strategist, or a “ninja”. This behaviour is certainly not true of all architects, many have successfully utilised team building skills, interpersonal skills and servant leadership when they also function as project managers, scrum masters, or informal project deputy leaders.
Behaviours which create distance between the team members and undermine shared goals are also not restricted to architects. Other examples include Business Analysts who direct more attention to documentation then their team, and technical leads who fail to understand their responsibilities include building technical strength across the team members (not just the technical product).
The main point is that this behaviour exhibited by anyone working with a project team goes against the principles of creating success through collaboration and shared responsibility. It impacts not just their own contribution, but the extent to which other team members will chose to either collaborate or withdraw to a perceived sanctuary of independence.
Does the culture of the broader department and organisation value collaboration?
Many organisations will try to shape their culture through mission statements, a charter of values, and various PR-based advertising campaigns. However, organisation culture is best measured in actions and outcomes. In particular – what behaviours are visibly rewarded through promotion and the behaviours of managers.
An organisation can say that collaboration is a key part of their philosophy, but are they collaborating with other organisations beyond a customer and supplier arrangement? Do they recognise and reward teams who work together or do they recognise individuals who are deemed to be high performing solo players? If the behaviour of an organisation isn’t a reflection of how they try to portray themselves then they are at best inauthentic and at worst insincere.
Likewise, do managers exhibit the behaviours of resilience and collaboration? A manager who deals well with setbacks and failures as an individual is also setting an example for how their team should deal with their setbacks and failures. A manager who insists that they will not interact directly with internally placed contractors is signalling that collaboration is a gated activity only to occur between particular people. Most importantly, the promotion of a manager who is bad at dealing with people sends the message to everyone else in the organisation that how they deal with other people is not important.
The previous four aspects are just a starting point
There are many other considerations which impact how resilient a project team can become. The four above are a good starting point mainly because they provide an initial perspective from which other aspects can also be evaluated.
How should deadlines be arranged, and work effort aligned? How should estimates be prepared? Where should project management effort be directed? Who is making project decisions and how? How should project risks be managed? What’s the right level of detail for a project plan? How should defects be managed?
When determining and reviewing approaches for these aspects and many others, also consider looking at them from the perspective of the four points above. While it’s important to work towards success, it’s the frameworks and attributes that are needed during the tough times which will help the project team to keep on track and thrive.
Written by a Senior Consultant at Diversus
References, resources and further reading
Identifying useful actions to improve team resilience in information systems projects
António Amaral, Gabriela Fernandes, and João Varajão
https://www.sciencedirect.com/science/article/pii/S1877050915026848
(also browse selective through its 42 references and 29 citing articles)
Why Are We So Averse to Conflict? The Good Fight Explains Why
Dan Pontefract (reviewing the book by Liane Davey)
5 ways to increase resilience at work
Stephanie Overby
https://enterprisersproject.com/article/2019/5/resilience-5-ways-increase
How to Build Resilient Teams
John Cunningham
https://www.m3ssolutions.com/article/how-build-resilient-teams
Make the most of mistakes: Best practices for agile retrospectives, post-mortems
Tony Bradley
Bad Software Architecture is a People Problem
Kate Matsudaira
https://queue.acm.org/detail.cfm?id=2974011
A Checklist for Making Faster, Better Decisions
Erik Larson
https://hbr.org/2016/03/a-checklist-for-making-faster-better-decisions
(NB: Paywall, however HBR provides limited access to three free articles)
How to be a C.E.O., From a decade’s worth of them
Adam Bryant
https://www.merryck.com/asia/articles/c-e-o-decades-worth/
(in particular, the section on culture, values and promotion)