Example Conflicts or Contentious topics that teammates get into
- Contract first or Code first approach. See https://programming-notes.explorer436.com/posts/20231109100855-contract_first_approach_to_api_development/
- Iterative vs Functional approach to writing functions. See
- Some developers want to use React, some want to use Angular
Some developers want to use Bitbucket, some want to use GitHub Some developers want to use C#, some want to use Java Some people want to work from home, some want everyone to be in the office every day Some want to use the Google Style Guide, some want to use a bespoke guide Some want fewer meetings, some want more
- Spaces versus tabs, and how many spaces a tab is equal to. Spaces on the end of a line has a whole section in the Google style guide, and an automated test at checkin.
CamelCase versus lower_case versus CAPITALIZED variable names. Single return vs. early error return vs. multiple return To throw (exceptions) or not to throw And worst of all, the dreaded curly-brace placement wars (gasp) Techno-Religious strife: Language choice, SQL v. NoSQL, pretty much anything.
Real Engineering vs. “Agile,” vs. Faux “Agile” (e.g., Scrum).
Mac v. Windows v. *nix. Linux v. BSD. Distro Wars.
Chinese v. Pizza.
Superman v. Batman (maybe Superman v. Thor).
TODO
https://isocroft.medium.com/decisions-that-matter-broadly-in-software-development-8de6d1d19733
Conflict between teams with different responsibilities
https://forthefans.blog/2020/03/01/conflict-in-software-development-teams/
For example, there is often a program team, a digital team and an operations team. The purpose of these different strands is understandable.
The program team have a responsibility to ensure all stakeholders, whether that be suppliers, policy teams, legal teams, digital teams or operational teams, work together. The digital team have a responsibility for the digital product and also a responsibility to improve the end to end service. The operations team should be able to provide confidence to senior managers and users. They should ensure operational resource is being used effectively and that the project success will result in improved and more efficient ‘business as usual’ processes.
Conflict between these strands is normal and it can even be healthy when a project is set up in the correct way. I like to call this ‘strategic conflict’. However, when a project is managed poorly, it can become destructive and bleed into the atmosphere ‘on the ground’. Let’s take a look at the topic of conversation between the strands, and how this can result in conflict.
There may be disagreement between the Program Manager, Digital Director and Operations Director. This can be about the motive behind the decisions that are being made at a strategic level, with the digital product. It may also be about disruption to the end to end service and the cost behind running the teams.
There is often conflict between the Delivery Lead, the Implementation Lead and the Operations Lead. This will usually be about the quality, deliverability and the scope of the project, as well as the timescales that implementation is expected by. Specific conflict between the Delivery Lead and the Operations Lead may be on the use of operational resource, especially in regard to user research. More time invested in user research, is less time spent on day to day tasks. This is why gaining buy in early on is important.
In addition, there is likely to be conflict between the Product Owner and the Operations Lead, around the quality of the product. A lot of projects seem to have Product Owners sitting on the digital side. Conflict may be alleviated by ensuring they are sitting on the operational side, properly representing ‘the business’.
When you take the ‘strategic conflict’ down from an organisational level, to the team level, we go from conflict to collaboration. The program team, the digital team and the operational team understand the strategic concerns and try to dig through the detail in order to find a fit for purpose, common solution.
The reality is that no matter how hard the teams try, if the project is set up and run badly from the start, there is going to be a lot more conflict and many more problems to solve. Although we have collaboration between the different strands, program, digital and operations, within the teams themselves, there is likely to be further conflict. I can’t say that this is a fact for program and operational teams, but it certainly is for digital teams. I have witnessed it first-hand on countless occasions.
Due to a fixed deadline, as well as the lack of time to properly understand problems and user needs, there is a lot of pressure on the team. We get into a position where collaboration is hampered, and we start throwing work over the fence between the different roles. Typically, the last fence before development, leads to the garden of the Business Analyst (BA), where user stories are written, and acceptance criteria is finalised.
A lot of good work goes into a user story. If it is to be fit for purpose, it should address a user need. in order for it to do this, it must go through research and design iterations, which could take time. Unfortunately, we don’t have time, so we get into conflict. The BA tells the Designer that prototypes are taking too long, or the Researcher that user research is taking too long, is too detailed or out of scope. The design team is constantly reminded about the time pressure that the project faces and a blame culture emerges.
User stories are written and thrown over the fence to the Developers, sugar coated by half-arsed attempts at scrum ceremonies, such as Three Amigos, Backlog Refinement and Sprint Planning. Then in sprint, further conflict arises, this time between the BA and the development team. The Business Analyst feels that they don’t have time to answer the questions, so they tell the team just do what it says in the story!
The pressure that the development team face is phenomenal. They need to create working software, tested, deployed in a production environment, for every story that is passed their way. All in time for the final deadline. They are in fight or flight mode, constantly pushing back, estimating against nothing, solutioning before a requirement is handed their way. As a result, they face conflict with everyone in the team.
They tell the Business Analyst that the user story isn’t clear, the acceptance criteria doesn’t make sense, or the story needs splitting. They tell the designers that the design is flawed, and the solution is not fit for purpose. The User Researchers are told that ‘the user didn’t mean that’. Inevitably, the Delivery Manager is informed that they can’t deliver everything that has landed on their plate. Who can blame them?
The User Researcher is passionate, nobody on the team cares for the user in quite the same way. Yet the Researchers analysis is constantly questioned and often even mocked. They have no choice but to defend with ‘That’s what the users said’. They tell the team ‘You don’t care about the users’. User research sessions are often cancelled by the research participants, outside of the control of the User Researcher. Illnesses, hospital appointments, an increased workload or technology issues. Yet it feels like the blame falls on the User Researcher. What do you mean the participant cancelled again?
Let’s not forget the strategic conflict that is taking place at the same time, there are already questions being asked by operational directors about the length of time that User Research is taking and the loss of productivity from a business as usual perspective. The User Researcher feels devalued and unimportant, they ask, ‘why is user research being blocked?’ When user research goes ahead, every member of the team is supposed to show an interest and be involved for at least two hours every six weeks.
Now let’s take a look at conflict, in the shoes of a Designer this time. They feel the pressure, expected to churn out designs, often in interactive form, make iterations and cover the end to end user journey.
When the team asks for designs, they tell them ‘everything doesn’t have to be a prototype’. They are shown user stories before any research or designs are created and they ask, ‘ Why is the solution already in your stories?’ The User Researcher is told that the user meant something else by what they said and not what the research analysis or recommendations concluded.
The designer is excited to see their work in the digital product, but they don’t see anything of the sort, and they comment ‘that’s not what it looked like in the prototype’. We know that the Developers face time pressure and that is apparent when the Designer tells them ‘Don’t copy and paste my code! It’s not production ready!’
The Delivery Managers view can be summarised by these simple words ‘YOU’RE NOT DELIVERING’!
I hope I have been able to paint a picture of conflict at a strategic and organisational level when projects are delivered poorly. As well highlighting the knock-on impact it has on digital teams, jeopardising the collaboration that individual roles would typically expect to have with one another. In the next instalment of this series, I would like to discuss scope and how it can be used to make a lot of these problems go away, ensuring the deliverability of a project.