Succeeding in ensemble work

Developing software in an enterprise environment is complex work. Being successful in that work requires a ton of different skills and traits. Subject matter expertise, written and spoken communication, courage and leadership are few of those that are really in the heart of it.

Image source: Virta Ltd.

At Virta, we have been making use of ensemble programming for nearly two years. We started with pair programming when we were developing our OCPI integration and later added more people to the ensemble. This was a perfect way for us to share domain knowledge inside the team.

At first our interaction was a little cagey and perhaps overly polite. Once we got to know each other better, we became more open. There was a lot of high-fiving but also some good spirited but intense arguing. We talked a lot, sent programming articles to each other and experimented with code together. In this period we aligned on the design principles and workflows we value.

We develop, test and release the code together in our team. We usually have 2–4 developers working on a single development task. Nowadays it’s almost exclusively remote work, so we use screen sharing in a Slack call. We develop and test the software together with QA engineers, OPS specialists and business experts. This is currently mostly developer driven but we’ll include any expert required by just directly adding the needed person to the call. This helps a lot, because we can then focus on really completing a development before moving on.

We’ve just recently had new team members. We’re onboarding our new experts by pair and ensemble programming. This allows our new developers to start contributing immediately with the help of their team members. This has a very positive effect as it reduces the anxiety that comes with learning the new people, domain and code.

If you’re looking to try out this type of working then this post can help you get in to the right mindset.

Tools

Everybody has to have a development environment that enables productivity. Any problem with the environment MUST be addressed immediately. If it takes a full work day to setup everyone’s development environment, so be it. Solving problems that unlock productivity is not waste of time.

• Make sure everyone has their development environment setup and running.
• You have to be able to write, edit and commit code to version control.
• You have to be able to run tests, preferably through IDE.
• You have to be able to debug code using a debugger through IDE.

Focus

We’re working on this issue now, because we our self have determined it to be the most pressing thing to do now. We’ve accepted to dedicate time to work on this now, so let’s put our minds to it.

• First, build alignment on what problem we’re out to solve.
• Anyone can propose a solution. There is no leader.
• Try the solutions out as soon as possible and learn if the solution can actually work. If there’s many solutions, time box the experiment to 20 minutes or so. Avoid long discussions about the solutions. Find ways to prove them right or wrong quickly.
• Fight all distractions. If you get pinged on Slack, review the urgency and put a reminder to deal with it later if possible. What we’re working on now is the top priority we’ve set for ourselves. Completing this task comes before everything else. Obviously severe acute problems like production system problems have to be dealt with.
• Take breaks every hour or more often if you feel the need for it. Ensemble work is rewarding, but also consuming. No-one can go a full day being on their sharpest all the time.
• Use incremental approach to find waypoints in which you can integrate the code safely. The system must be working every time you reach this waypoint. Try to integrate the code at least once a day.

Teamwork

• Ensemble work brings out all the different strengths of its’ individual members. We can rely on someone who’s really good with databases, or writing tests, or coming up with solutions, etc. It’s an opportunity to learn from each other.
• Keep an open mind and listen to each other. Always allow a person to prove their solution can work.
• The person at the keyboard is commonly called THE DRIVER. Change drivers often. Every 15–20 minutes. Find out what works for you. But realize that longer the interval, the more likely other team mates will start getting disengaged.
• There’s no hierarchy in an ensemble. Nobody decides solely how a solution is going to be implemented. We’ll observe the cons and pros by experimenting with the solutions. “Show the code”. Nothing is more effective than actually trying a solution. If we cannot agree with something, then we will have a COMPROMISE. If you never compromise, this way of working will not suit you.

Communication

• Try to communicate effectively WHAT you’re going to do, WHY we’re doing it and WHAT is the expected end result.
• Keep the communication at the HIGHEST appropriate level. Humans can only deal with a limited amount of information every day. Make sure it’s relevant and not too low level.
• Use visual aids to help communicate thoughts effectively. Use a whiteboard or write it out in the open. This can turn into documentation too.
• If you simply cannot explain what can be done, ask others for patience while you SHOW them.