Photo by Designecologist from Pexels

I am convinced that the world needs more technical coaches. Practices like Refactoring and Test-Driven Development don’t just happen by themselves. It takes quite an investment in time and effort for most developers to see the point, and to realize how much it would help them to work this way. Then they need to put in some time and effort to become proficient using these skills, and a supportive team culture is essential. Having an experienced technical coach on hand can make all the difference for success. 

During 2021 one of the teams I coached was struggling to make progress in a large, complex codebase. We worked together in an ensemble which enabled them to pool their knowledge and get a grip on the code faster than before. We held several learning hours focused on test design which helped them to improve the unit tests and get better feedback on their changes. Everyone said afterwards they felt like working with the coach had helped them to work more effectively. I’d like more teams to experience this kind of progress. 

Samman is the method I use when I’m coaching software development teams. The two basic components are ensemble working – where you gather the whole team to work together on one programming task – and learning hours – where developers learn new skills and practice on exercises. 

I published my book “Technical Agile Coaching with the Samman method” in January 2021, because I wanted to help other technical coaches to use this coaching method and to promote agile ways of working. When I held this book in my hand for the first time it was somehow larger and heavier than I expected. I felt a huge sense of accomplishment! Since then, I’ve more and more realized the book was just the beginning. There are a lot of development teams out there and only a few technical coaches who really know how to help them.

The book generated quite a bit of interest and I’ve spent a large part of last year talking and writing even more. I was asked to contribute articles about Samman coaching for some of the biggest online magazines in our industry – Methods and Tools and InfoQ. I also had a steady stream of invitations to appear on podcasts. I just went through and counted them – eight were published in 2021! (I list them at the end of this article)

I was invited to give the keynote address to the ACCU conference. It’s always a huge honour to give a keynote and I spent many hours preparing this talk. For the second time in my career I was also invited to speak at the annual Agile conference organized by the Agile Alliance. It’s one of the biggest conferences in the software world – also a great honour to be asked to speak there.

For most of my career I’ve been part of the Agile, XP, DevOps, Testing, Python and Java communities within software development. Although I have previously done a fair amount of architecture work, this year I feel I also took a step into the Architecture community for the first time. I was invited by O’Reilly to be a judge in their Architectural Katas competitions. I see technical coaching as one aspect of the kind of technical leadership that architects usually bring in an organization. Through this competition, architects from all kinds of organizations can practice their skills and learn from each other. I’m really happy to have been involved.

Looking forward to 2022, I’m anticipating another year of hard work doing technical coaching with teams, but also more and more training others to do coaching. I’m getting a lot of enquiries from organizations who see a need for better technical practices. My colleagues and I have only so much time available to coach teams, so I usually suggest pair-coaching with people already in the organization. Most organizations already have architects and technical leaders and often those people would like to learn to coach teams using the Samman method. It’s for that reason that we’re ramping up the train-the-trainer programme offered by ProAgile. We have new courses on Ensemble Working and also on Learning Hour Design, two of the key activities for a technical coach using the Samman method.

I remain convinced that good technical coaching is essential for building up productive and happy development teams. I look forward to continuing to spread better ways of working and coding together with lots of great people in 2022. Happy new year!

Podcast appearances 2021:

  • DevOps Sauna – a lovely chat with Sofus Albertsen, a former colleague of mine.
  • Richard Kasperowski – we talked more about music than software I think!
  • Mob Mentality Show – Chris Lucian and Austin Chadwick were really friendly and easy to talk to.
  • Mosaic Works – Alex Bolboaca really knows his stuff and how to interview people
  • That Tech Show – I was really pleased to appear on this one which has such a varied lineup.
  • Arrested DevOps – Matt Stratton is a busy man, heavily invested in the DevOps community. Great to talk to him.
  • Maintainable – the theme of this podcast is making existing software more maintainable, something I can really get behind.
  • Making Tech Better – Clare Sudbury got me talking about Refactoring – a really important topic. 

I’ve known the author for many years and actually did some remote pair programming with him in early 2020 which we published as a video. I’m confident Adrian is very skilled at both pair programming and working with distributed development teams. I was pleased when he asked me to review this book and, (full disclosure), the publisher sent me a free copy.

Adrian’s advice is detailed, specific, and as the title implies, intensely practical. I won’t relate all of his advice here, of course, but a couple of things stuck out to me. 

Many of us these days work in cross functional teams and any given feature might need both some Java code and some Javascript code to be written. If you have a Java programmer and a Javascript programmer, they can pair together on a Javascript task, and after an initial slowdown while the Java programmer learns some Javascript, you can expect the overall team productivity on Javascript tasks to increase. He estimates it could take 2-3 weeks of daily pair programming sessions for that to happen. Over time you can build a truly cross-functional, flexible team.

Another situation where pairing can give superior results is when you have a rather complex programming task which two senior developers work on together. If they are skilled at pair programming they will likely be able to complete this complex task faster and with higher quality than either would alone.

As a technical coach, I was particularly interested that Adrian recommends any team starting out with pair programming to have a trainer/facilitator or coach to help them. He is clearly experienced in taking that role himself. He mentions that some programmers like working alone and don’t want to pair program at all. In that case you need a good coach who will create a safe space to try it and with tact and patience make it possible for all kinds of people to learn the necessary skills and techniques. He does note that some people never take to it though. I would have liked a few more words there about what (if anything) you can do about that.

The book is structured into three parts, the first part is about pair programming generally and the second part is about remote pair programming. The third part is a kind of appendix with lots of detail about tools. When I read the first chapter in part 2 I suddenly felt like it should have been the first chapter of the whole book. It gives a good summary of almost all the topics that appear elsewhere. This was where he was persuasive about all the good reasons to do pair programming, along with strategies for when to use specific styles and techniques. I found this was the most useful part. It gave me a kind of index for looking up interesting information in the rest of the book.

Some of the detailed advice in subsequent chapters didn’t interest me very much. There was really a huge amount of advice about setting up lighting and sound and remote collaboration tools. I would have preferred Adrian to spend more time illustrating the various pairing styles and techniques. I’m still a little hazy about the difference between the Pairing-Trainee technique and the Beginner-Advanced technique. That seems to me to be advice that will still be useful and relevant when the differences between Zoom and Google Meet in early 2021 are long forgotten.

My personal advice – read chapter 4 to find out Adrian’s overall approach. Read chapter 6 to find out more about remote styles and techniques. Refer to chapter 3 for more detail on any techniques you’re less familiar with. Chapters 1 and 2 have relevant background information about pair programming in general. Read the last section before the ‘summary’ in chapter 5 and marvel at the sheer amount of technology and hardware that Adrian prefers for his personal remote pair programming setup, then read any more of chapter 5 and 7 that you need to achieve the equivalent for yourself. 

Originally published on ProAgile’s blog

That was the question I posed on Twitter yesterday. I got a huge pile of answers, some of them surprised me! This article is my way of thanking everyone for sharing their ideas.

You can see the whole picture in this pdf which you are free to download.

Of course I asked this question mostly because I was curious whether anyone else would say the same things as me. I primed the discussion with my personal list, asked people to ”like” any responses they agreed with and reply with their own additions.

I was really pleased with how many people took the trouble to write something. Some of the things I hadn’t thought of at all.

I went through all the replies and summarized the main ideas on postit notes. (I didn’t try to transcribe every one). Then I grouped them by area and added some colours and headlines. The picture above is what I came up with in the end. Eight areas that emerged:

  • Human needs
  • Teamwork
  • Learning and professional development
  • Making progress and achieving a Flow state
  • Meaningful relationship with end users and customers
  • Building something important
  • Good code and coding environment
  • Shared coding rules and architecture

Some ideas would fit in more than one area of course, in which case I tried to put them near the boundary.

The main point that surprised me was the number of people who wanted peace and quiet – long stretches of uninterrupted time. I interpret that as a desire to reach the ’flow’ state that you get when you become so absorbed in what you’re doing that you are no longer conscious of time passing. It’s a wonderfully rewarding state to be in. I guess I never found silence to be a prerequisite for that, I get it in a pair or ensemble too.

The most popular kinds of ideas, that got the most likes, were mostly around the ’human needs’ category. We’re all people, including software developers 🙂

I’m interested in this question not only from idle curiosity. I regularly give talks at conferences and company events attended by lots of software developers. I want to understand the kinds of challenges developers have in their daily work and connect that to the things I can help them with. I don’t want to just cause additional boring meetings taking people away from fun coding!

Thanks to everyone who contributed to the discussion on Twitter. I think I learnt something from it, I hope you like my summary.

By Emily Bache

There’s a frank discussion going on in the software industry at the moment about the words we use and the history behind them. Perhaps now is a good time to reconsider some of our terminology. For example, I’ve noticed we have several terms that describe essentially the same kind of testing:

  • Golden Master
  • Snapshot
  • Characterization
  • Approval

I think it’s time to completely drop the first one of these. In addition, if we could all agree on just one term it could make communication easier. My preferred choice is ‘Approval Testing’. As an industry, as a community of software professionals, can we agree to change the words we use?

What kind of testing are we referring to?

The common mechanism for ‘Golden Master’, ‘Snapshot’, ‘Characterization’ and ‘Approval’ testing is that you run the software, gather the output and store it. The combination of (a) exactly how you set up and ran the software and (b) the stored output, forms the basis of a test case. 

When you subsequently run the software with the same set up, you again gather the output. You then compare it against the version you previously stored in the test case. Any difference fails the test.

There are a number of testing frameworks that support this style of testing. Some open source examples:

 Full disclosure: I am a contributor to both Approvals and TextTest.

Reasons for choosing the term ‘Approval Testing’

Test cases are designed by people. You decide how to run the software and what output is good enough to store and compare against later. That step where you ‘approve’ the output is crucial to the success of the test case later on. If you make a poor judgement the test might not contain all the essential aspects you want to check for, or it might contain irrelevant details. In the former situation, it might continue to pass even when the software is broken. In the latter situation, the test might fail frequently for no good reason, causing you to mistrust or even ignore it. 

I like to describe this style of testing with a term that puts human design decisions front and center.

Comments on the alternative terms

Snapshot

This term draws your attention to the fact that the output you have gathered and stored for later comparison in the test is transient. It’s correct today, but it may not be correct tomorrow. That’s pretty agile – we expect the behaviour of our system to change and we want our tests to be able to keep up. 

The problem with this term is that it doesn’t imply any duty of care towards the contents of the snapshot. If a test fails unexpectedly I might just assume nothing is wrong – my snapshot is simply out of date. I can replace it with the newer one. After all, I expect a snapshot to change frequently. Did I just miss finding a bug though?

I prefer to use a word that emphasizes the human judgement involved in deciding what to keep in that snapshot.

Characterization

This is a better term because it draws your attention to the content of the output you store: that it should characterize the program behaviour. You want to ensure that all the essential aspects are included, so your test will check for them. This is clearly an important part of designing the test case. 

On the other hand, this term primarily describes tests written after the system is already working and finished. It doesn’t invite you to consider what the system should do or what you or others would like it to do. Approval testing is a much more iterative process where you approve what’s good enough today and expect to approve something better in the future.

Golden Master

This term comes from the record industry where the original audio for a song or album was stored on a golden disk in a special archive. All the copies in the shops were derived from it. The term implies  that once you’ve decided on the correct output, and stored it in a test, it should never change. It’s so precious we should store it in a special ‘golden’ archive. It has been likened to ‘pouring concrete on your software’. That is the complete opposite of agile! 

In my experience, what is correct program behaviour today will not necessarily be correct program behaviour tomorrow, and we need to update our understanding and our tests. We need to be able to ‘approve’ a new version of the output and see that as a normal part of our work.

This seems to me to be a strong enough argument for dropping the term ‘Golden Master’. If you’ve been following the recent announcement from Github around renaming the default branch to ‘main’, you’ll also be aware there are further objections to the term ‘master’. I would like to be able to communicate with all kinds of people in a respectful and friendly manner. If a particular word is problematic and a good alternative exists, I think it’s a good idea to switch.

In conclusion

Our job is literally about writing words in code and imbuing them with meaning. Using the same words to describe the same thing helps everyone to communicate better. Will you please join me in using the words ‘Approval Testing’ as an umbrella term referring to a particular style of testing? Words matter. We should choose them carefully. 

A book for managers, about architecture

Ruth Malan re-stated Conway’s law like this: “If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”. As a technical leader, that really caught my attention. The sphere of things I should be able to influence in order to do my job well just grew! 

Team Topologies book on my desk with some post-its around it

I read that quote in the book “Team Topologies” by Matthew Skelton and Manuel Pais. I think it’s a really interesting book and introduces several ideas that were new to me at least. They deserve a wide audience within the software industry. In this article I’ll give you some highlights, and hopefully tempt you to read the book for yourself.

This first idea perhaps isn’t so novel, but it is the basis for the rest, so worth mentioning first. You should use the team as the fundamental building block for your organization. Rather than thinking about hierarchies or departments that get re-organized from time to time, think about building close-knit, long-lived teams. Adopt a team structure that is aligned to the business and adapts and evolves over time. 

Conway’s law

When designing a team structure for your organization you should take into account Conway’s law. Your team structure and your software architecture are strongly linked. You should design team responsibilities and communication pathways. Skelton and Pais suggest there are four fundamental team topologies, ie kinds of team. The main one is ‘business stream-aligned’, the other three have supporting roles. The way they describe a stream-aligned team seems familiar to me. It’s like a DevOps team or a feature team. I think the name is better though. It’s a team that’s aligned to a single, valuable stream of work. They do everything needed to deliver valuable software to customers, gather feedback from how it’s used, and improve the way they work.

The other three kinds of team exist to reduce the burden on those stream-aligned teams. Skelton and Pais introduce the idea that good organization design requires restricting the amount of ‘cognitive load’ each team is expected to handle. Software systems can become large and complex and can require an overwhelming amount of detailed knowledge to work on them. This really resonated with me. I’ve worked on teams where the amount of software we had to look after was just too much to cope with. Important work was delayed or missed because we were overburdened.

The other three types of team are: 

  • Platform 
  • Complicated Subsystem
  • Enabling

There is a fuller description of each in the book of course, but to summarize – platform teams provide a self-service tool, API or software service. Enabling teams support other teams with specialized knowledge in particular techniques and business domains. Complicated subsystem teams look after a particular component of the software that needs specialized knowledge, like an optimizer or a machine learning algorithm. 

Following from the idea of Conway’s law in particular, is the idea that you should have only three ‘interaction modes’ between teams. Restrict the communication pathways to get the architecture you want, and to avoid unnecessary team cognitive load. Skelton and Pais suggest teams should work together in one of three ways:

  • Collaborate
  • Facilitate
  • Provide X-as-a-Service

Collaboration means two teams work closely together, have a common goal, and only need to work this closely for a limited time. (Otherwise the teams would merge!) Facilitation is about one team clearing impediments that are holding back the other team. X-as-a-service is a much looser collaboration, where one team provides something like a software library or api to another team. The way teams interact with one another will evolve over time, and consequently your organization will also evolve.

I thought it was a good sign that I could imagine how my own work would fit into an organization designed this way. I think I would fit well into an Enabling team that would support stream-aligned teams through facilitation. We would work with several teams over time. My particular role is to facilitate a team to clear impediments around technical debt and code quality, and learn skills like Test-Driven Development. 

Team Topologies really does make organizational design feel like you’re doing architecture. Skelton and Pais have pretty diagrams throughout their book with colours and patterns and lines and boxes describing various organizational designs. It’s all very attractive to a software developer like me. I think the intended audience is managers though. People who are designing organizations today. I really hope some of them read this book and are inspired to involve technical people in important organizational decisions.