Skip to content

Instantly share code, notes, and snippets.

@proffalken
Created March 15, 2019 11:00
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save proffalken/cc3f64a07c2bc52f320529dcd6fe4330 to your computer and use it in GitHub Desktop.
Save proffalken/cc3f64a07c2bc52f320529dcd6fe4330 to your computer and use it in GitHub Desktop.
Helpful Blog Posts

Five things your organisation can do to improve Collaborative Working

Collaborative working can be hard to get right, here's our top 5 tips to encourage a culture of success.

Building multi-discipinary teams is a great way to get the best out of your staff

“Collaborative Working is hard“. We’ve heard this from so many of our clients over the years, and often they really struggle with the conflict between Generalism vs. Specialism, and even how to start working in a collaborative manner.

If you go into hospital for a major operation you wouldn’t expect the ward receptionist to administer the anaesthetic, nor would you expect a nurse to carry out the procedure, or the surgeon to perform post-operative care – so why do we expect so many of our software engineers to be “full stack developers”, or our operations teams to have a complete understanding of everything that happens in the process before our product reaches them?

Start by analysing your product, working out which roles are important, and then build your team from there. If you work in the technology industry, then we’d recommend that a team contains at least one individual for each function of the following:

  • Someone who understands the culture of your organisation and can support the team through any transformation processes required
  • Gathering Customer Requirements
  • Security
  • Marketing/Sales
  • Software Development
  • Operations
  • Customer Support

A dedicated finance person to sign-off architectural decisions from a business perspective, or a dedicated Human Resources expert to help when the team needs to grow could also be excellent assets to the team, but ask them first, don’t just assume!

Make sure that each product team has at least one specialist from each discipline within your organisation and give them the space and the time to support each other, especially during an emergency.

Foster a “specialist support network” to improve collaborative working

Your organisation probably already uses Slack, HipChat, or a similar tool to collaborate within teams, but do you have channels dedicated to help on a particular subject?

Setup channels within Slack/HipChat/etc. for help with your cloud provider and invite the experts in your organisation to contribute useful blog posts or answer questions from others who are less advanced in their knowledge.

A channel on diversity and how it can be improved within your organisation, or other channels for those from under-represented groups to express how they feel working within your company could be a good place to start, but remember that diversity is a subject that needs to be handled with sensitivity – one approach could be to make sure that the people who are facilitating these channels have appropriate training and are able to address concerns as they arise.

Ensure that everyone knows what to do in the event of a major incident

The citizens of Hawaii were recently treated to a test of emergency procedures due to someone pressing the wrong button.

Your organisation probably isn’t facing the threat of attack by a nuclear rogue state however, if your office lost power, or there was a natural disaster that prevented your staff from getting to work, would your teams know what to do?

Make sure that you have a Disaster Recovery/Major Incident Plan in place that you can practice with, and make sure that you practice the steps in that document so it becomes second nature to your teams when an emergency or other disaster does befall your organisation.

Our blog post on writing Disaster Recovery/Major Incident Plans could be useful here.

Team Work

It sounds obvious, doesn’t it? In order to achieve better collaboration, we need to work together.

Unfortunately for many of our clients in the past a decision has been made to “work collaboratively” without much thought as to what this actually means, leading to loads of changes to the working environment (“conversation pods”, “breakout areas”, “collaboration zones”, and even talk of ball pits/zip wires!) without having any actual effect on the way in which the staff within those organisations work.

In an emergency services setting, it’s often an unwritten rule that the team leaves when the last person finishes their work, encouraging people to work together to ensure that everyone finishes by the end of the shift. This may not be appropriate in your organisation, however, it’s worth looking at how you interact with your colleagues on a day to day basis, and see if there is a way in which you can adjust the way you work in order to help them.

If everyone starts to think about the “knock-on” effects of their actions on their colleagues, you’ll have a far more collaborative workforce than if you install a beer fridge, and there’s more on this in the next section…

Keep social events inclusive

The office social has become a frequently used tool to bring people together, but have you thought about how inclusive your social gathering might be?

Many people on your team may not drink alcohol, eat meat, or have an interest in sporting events amongst other things, so before you setup an all you can eat steak night watching your local team play at their stadium, take time to consult the team on what they would like as part of a team social event.

It may be best to do this anonymously, invite them to send you a message, or drop by your desk to give you their ideas so that members of the team don’t feel pressured into accepting social conventions that put them in a difficult place.

“Do you remember when…”, “No, I didn’t go to that event because I felt uncomfortable attending due to…”, is a sure way to restrict the flow of conversation around the office, yet if the team feel that they have been consulted, and that the agreed event meets the needs of the group, then they are far more likely to take part and enjoy the event.

Successful collaboration is about culture…

The rise of DevOps has seen “Culture” become a key part of Digital Transformation programmes precisely because it encourages the kinds of collaboration that are required for successful teams. If that culture fails to be inclusive, or doesn’t take account of the needs and wants of your teams, then the culture of collaboration will be a lot harder to achieve.

If you’re interested in how Mockingbird Consulting can help your teams collaborate further, then please email info@mockingbirdconsulting.co.uk.

We’d like to especially thank all those who helped us with the diversity content of this post, it’s great to work with people who come from different backgrounds and can give a perspective we’d otherwise have missed.

Five ways to get value from your retrospective

How do your retrospectives leave you feeling? Refreshed, or just wondering why nothing seems to move forward? This post outlines five of the most useful activities that we suggest to our clients to help them get value from their retrospectives.

1. Establish Trust

If you do not have the trust of your team, then a retrospective will never provide value.

At the start of your retrospective, hand out paper and pens that are identical to the entire team – this is important as it ensures anonymity. Ask everyone to score how safe they feel about being honest in the current retrospective on a scale of 0 – 9 (after all, we’re software engineers, cardinality is important!), then get them to fold the paper and put it into a closed box.

Making sure that the poll remains anonymous, take the papers out and quickly tot up the total to work out how honest people feel they can be.

If there is a clear issue with honesty within the team, ask the members of the team if they would be willing to talk about any trust issues on a one-to-one basis outside the retrospective process.

Continue with your retrospective, ensuring that you take the trust level in the room into account when writing up your notes.

DO NOT DISCLOSE THE NUMBERS THAT WERE WRITTEN DOWN, NOR THE FINAL TOTAL. You need to be trusted by the team in order for this to work in future.

2. If the last sprint was a … then it would be …

Help your team think about their work in a completely different light by asking questions that encourage comparisons with films, songs, tv programmes, books, cars, or any other category that you can think of.

Make sure that you keep the category to one that will be inclusive for your team – for example, “If the last sprint was a football team, then it would be…” immediately alienates anyone who doesn’t like football.

We’ve had some great answers to this, including one participant who started lamenting the fact that the project management went so well, only for someone to destroy the entire product at the end of the sprint, just like the Death Star in Star Wars!

3. Stop, Start, Continue

A favourite of pretty much every Agile coach around the globe, “Stop, Start, Continue” is a great way to find out what your team enjoys, or what they would rather stop doing.

Create a grid on a whiteboard with three columns headed “Start”, “Stop”, and “Continue”, then hand out the pens and the post-it notes and ask the team to start filling the columns with their thoughts.

Make it clear that this could be about the work they have undertaken, the way in which they are working, or even how they communicate with other departments – there are no wrong answers, this is just the starting point for a discussion.

After ten minutes, invite the team to vote on the top three things they want to discuss by marking those post-it notes with their pen. Group the post-it’s by the number of votes, then set aside at least 10 minutes for each subject.

Convert the output of the discussion into action points, and make sure they are tracked and implemented.

4. What do they think of us?

How you interact with other teams is vital to your success. This exercise helps you think about how other teams might consider your team.

Inform your team that the notes from this session will be shared anonymously with the other teams.

Ask the team to write down all the other teams that they interact with on a daily basis, and put them up on the whiteboard.

Group the notes so that you have a list of the most common teams you all interact with and then go through each team in turn, asking those in the retrospective to write down what they feel the other team thinks about your team and their interactions.

Find a way to group the notes around each of the other teams, and then run a “Start, Stop, Continue”, or “If our interactions with team … were a … then they would be…” exercise and collate all the results.

Take time to talk to the other teams and provide them with the feeling within your team – where did you agree? Where did your team get the relationship wrong? Was the feedback received positively?

Ask permission from the other teams to feed back their responses to your team. This may be a painful process however, it will help encourage better communication and honesty in future.

5. Hi! I’m new here!

Does everyone in your team understand what the others do? Do they understand their own roles? How do new starters know who to approach for help on a particular issue?

When starting this exercise, make it clear that you are focusing on the role within the team, not the individual.

A picture depicting how the whiteboard might be arranged during the "Hi, I'm new here" exercise

An idea of what the whiteboard might look like

Pretend that it is your first day at the company, and interview each member of the team for a maximum of two minutes on what their role is.  Whilst you are doing this, the rest of the team will write down their comments on their view of the role.

Create a grid on the whiteboard with the roles across the top, then ask the team to stick their comments to the board in the appropriate column.

Set a time limit of 5 minutes per role, and discuss the responses. Where is there overlap between roles? Are there particular roles that are completely misunderstood? Is there a duplication of effort, or even gaps in the skills that the team needs?

Feedback is important

Take ten minutes at the end of each retrospective to talk through with the team how they feel about what they’ve just done. Upload a summary of the notes to a wiki, and ask the team to comment on the document confirming or disputing its content. that they agree

Make it clear to the team that you are happy to discuss issues raised during the retrospective on a one-to-one basis if required – some of these exercises can be mentally exhausting and will need a degree of after-care in some situations.

Honesty is key

We started this article talking about honesty, and we’d like to end with it as well.

Addressing issues of trust and honesty within your team is vital in order for your retrospectives to provide value.

Building trust within teams is a subject that many others have written about however, we have found that conversations (often with a trained mediator) are frequently the best way to resolve any seriously difficult issues.

Above all, retrospectives should be honest, open, and frank discussions about the current state of your team culture and the work they carry out.

Getting value from your retrospectives

Retrospectives are one of the most important parts of the Agile development process, as they enable you to see where you have come from and how to improve.

We see a large number of clients focusing on what they did and not how they did it, meaning that they never address the cultural issues that are preventing their teams from performing the best they can..

If you would like further help on your retrospectives, our team are more than happy to facilitate or provide advice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment