When team members are not used to or want to show humility within the confines of their team’s space, then they are not functioning as a team. That’s where we can and should help. Until that starts to happen, any new learning is an uphill battle.

I spent some time two years ago with a team group who asked me about delays in reviewing their pull requests, and I recall the central issue lay in a lack of self-confidence, resulting in not wanting to criticize someone else’s work.

I would love to reduce the latent stress in the mob, but just saying “There is no stress” is visibly not enough!

Even though we do “technical” coaching, collaboration skills can make or break our work! Most of us have coaching stories that support that. Situations where horrible teamwork made it impossible to pass anything to a team! Or teams with newly emerging technical skills but turning into super-performing thanks to collaboration! The impact of collaboration and teamwork is incredible!

Bad teamwork and collaboration also block mobbing and pairing coaching sessions. How can we help teams to improve collaboration so that coaching becomes effective?

Wouldn’t it be great if we could coach teamwork and collaboration by example? So that all the rest followed?

Let’s grow our collaboration skills first!

Coaching by example, aka walking your talk, is a fundamental coaching technique. By improving our communication and collaboration skills, we’ll showcase good teamwork. As a result, we’ll inspire our coachees to follow suit!

Before jumping into how to do that, let’s see why it works.

Why is team collaboration essential?

No matter how it looks at first, it’s always a people problem. (Jerry Weinberg)

Demarco and Lister demonstrate that the major issues of software development are human, not technical. Their answers aren’t easy–just incredibly successful. (Back-cover of the seminal Peopleware: Productive Projects and Teams)

Junior programmer’s bookshelf: 90% APIs and programming languages; Senior programmer’s bookshelf: 80% applied psychology. (J.B. Rainsberger)

I’m not the only one saying that team collaboration is paramount to success!

It’s not only what people say. The Aristotle project at Google concluded that psychological safety is the main factor in team performance. Psychological safety makes it OK to take risks and show vulnerability in front of others. Here again, human interactions come out as critical to team performance.

It’s clueless to coach a team without dealing with teamwork!

Communication Skills Are Contagious

Communication and collaboration skills are contagious. Good communication is inspiring, and leading by example is a powerful coaching tool:

Demonstrate through your own actions, your responses, the way you conduct yourself, the sort of mindset you are trying bring out in them and their teammates. That’s all. Not rocket science, but sometimes very challenging. (Bob Allen on WeDoTDD slack)

Be the change you want to see in the world (misattributed to Gandhi)

Some collaboration practices will help. For example, Liberating Structures, a set of facilitation techniques, are viral by design. Participating in a liberating structure is usually enough to facilitate it later!

Here is another example. Someone good at negotiation and conflict resolution can protect a whole team!

Finally, as we improve our collaboration, we will become better facilitators. As a result, we will run more effective workshops, which will have more impact on the teams we coach.

Your collaboration practices might spread to the CEO! (cf Local Action, Global Impact)

Better communication will make us happier!

Not only will investing in collaboration make you a better coach. Improving your communication and collaboration skills also makes you happier!

• A Harvard study revealed that the quality of relationships is the #1 factor for happiness! Any communication technique will improve some aspects of relationships. The communication skills we grow for work will also serve us in our personal lives. So, improving our collaboration skills for tech coaching will make us happier humans!
• Relationships at work are crucial to job performance and job satisfaction. Having a bully at work can make your life miserable. The opposite is also true! Gallup studies demonstrated that having friends at work improves performance and job satisfaction. Other research states that at work, relationships make us happier than purpose!

And… As communication skills are contagious, we will also impact the lives of our coachees!

Always bet on communication skills! Not only for your coaching gigs but for your general well-being.

I hope you understand how vital communication skills are. Let’s see a few “Communication skills.”

My collaboration skills journey

I was not born a good communicator… and I’m still learning! I remain shy and usually feel awkward in social situations. Yet, it feels way easier than it used to be. In particular, I manage well at work and with my close ones.

Here is the “story” of the communication techniques that impacted my life most. It’s not an exhaustive list of everything that exists. But you might find something that spikes your curiosity!

Code Like Prose

When I started as a programmer, solo coding felt safe and relaxing. There was only the logic of the program to deal with.

However, I had to change my mind after a few months in my first job. I understood that my career would not be the “introvert paradise” I had envisioned. Programmers need to communicate a lot! And the primary way programmers communicate is through code! With time, I learned that writing Code Like Prose made my colleagues and future self much happier.

💡The Refactoring and Growing Object Oriented Software Guided By Tests books were essential to my learning.

🤣 Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability. (John F. Woods)

Visual Management

As I read more about TDD and refactoring, I became interested in the agile literature. I discovered how Visual Management can reduce the painful boss-subordinate relationship. Visualizing work and progress enhances team alignment, transparency, autonomy, and self-responsibility. Let’s not take Visual Management for granted! It still could be used more.

💡 Reading the Kanban book was an eye-opener on this one.

Pair Programming

We often look at Pair Programming through the lens of code quality and productivity. Yet, it is also an incredible workout for communication skills. My pair programming years made my listening, negotiation, and self-awareness skills soar.

💡I wrote a lot about pairing, but my first advice to get better at it would be to start attending (or creating) a coding dojo.

Facilitation

As I became “the agile guy,” my teammates asked me to facilitate retrospectives. I learned the facilitation posture: a communication catalyst with a touch of mediation. Good facilitation will directly improve teamwork. Facilitation provides the incredible leverage of collective intelligence to tackle complex tasks.

💡The Agile Retrospectives: Making Good Teams Great was invaluable to get me started. (Note: They are working on a second edition!)

Writing

I started this blog as “Notes to my future self.” The first posts were rough drafts. I’m still no Hemingway, but my writing skills have improved a lot since then. Writing is an overlooked skill for developers. There is a motto that says “Writing is Thinking”! Writing skills yield more readable code, helpful documentation, and fewer email back-and-forths. Full-remote companies like Basecamp use writing skills as hiring criteria! Also, it does not matter where you start: I used to have abyssal grades in writing at school…

💡To improve your writing skills, start writing a blog or taking notes. You can also study classic books like Elements of Style. Finally, apps like Hemingway and Grammarly have helped me a lot to improve on my mistakes.

Living Documentation

Living Documentation is what you get when you combine TDD with Writing. The initial idea is to use human-readable text to write domain-oriented tests. The goal is to involve non-developers. It’s all about communication. Used well, Fit, Cucumber, or literate programming can transform collaboration with stakeholders. Who’s never wasted time building the wrong thing right?

💡I first learned about Living Documentation with the now-outdated Fit book. Since then, I have enjoyed:

• Specifications by Example
• Writing Great Specifications
• The Cucumber book
• And Living Documentation.

Remote Pairing

We were all forced into remote work during the Covid pandemic. Yet, I had already been doing regular remote pair programming for a few years. This experience proved full of lessons. Remote work forces us to make a lot of the implicit communication explicit. The same goes for remote pairing. Remote pairing makes us aware of how we communicate and allows us to improve on our flaws.

💡I remember enjoying the Remote Pairing book. Otherwise, I recommend learning the git-handover mechanism to get started with remote pairing. It’s also a good idea to run daily ‘mini-retros’ with your pair to fine-tune your pairing.

Non Violent Communication

🤣 No, Non-Violent Communication is not a rehab program for bullies…

The company I work for, Murex, has a Non-Violent Communication course in its catalog! I was lucky to attend one session a few years ago. NVC lessons can be life-changing:

• The difference between facts, feelings, and needs
• The fact that we are all responsible for our state of mind
• How to give non-violent feedback

Don’t expect an overnight change, though. NVC is a straightforward idea that takes years to master. Yet, the sooner you start this path, the better. The more we improve our NVC skills, the less conflict we will see around us!

💡If you have the chance, attend a course, an immersion retreat, or try to attend a regular practice group. If you prefer books, Language of Life is the reference. Kent Beck also mentioned The Language of Emotions, which connects to the topic.

Event Storming and Collaborative Design Workshops

Team-wide collaborative design is challenging even with workshop facilitation and software design skills. I struggled with that for a few years when I stumbled on Event Storming. I was immediately hooked. Collaborative design is a way to do just enough design up-front in a few days. It also ensures everyone contributes, understands, and aligns on the direction! It has a tremendous impact on the motivation and productivity of a team.

💡I learned about Event Storming from Alberto Brandolini’s work-in-progress book. Matthieu Tournemire and I are also currently blogging The 1-hour Event Storming book. Other standard collaborative design workshops include Example Mapping, Domain Storytelling, User Story Mapping, and Impact Mapping…

Visual Facilitation

We say that a drawing is worth a thousand words. It’s incredible how a few drawings make presentations more engaging. Sketching also saves a lot of time. The audience will get the idea faster. And you’ll save time scribbling rather than writing or talking. You can use sketches in your notes, presentations, workshops, and documentation. The surprise is that you don’t need to be good at drawing to do visual facilitation!

💡If you have the chance, attend a training on Visual Facilitation. But you can also start sketch-noting right now: you only need a pad and a pencil. I began by combining:

• Cornell’s note-taking system
• With mind maps 
• And small drawings to decorate ideas.

Mob Programming

Mob Programming is extreme pairing. As a coach, mobbing has proven much more time-effective than pairing. We can exchange practices with the whole team instead of a single coachee. More than that, we can also observe and work on team dynamics! Mobbing will test many of your communication and collaboration skills: listening, facilitation, self-awareness, negotiation, collaborative design…

💡You can practice mob programming by running team coding dojos with strong style pairing. After a while, coachees might suggest trying it with production code. A Mob Programming code retreat is also a safe and quick way to experiment with various flavors.

Public Speaking

Public speaking is about impacting an audience in a limited time. This is useful to nudge management or a team into healthier work habits. Public speaking is also an occasion to get out of our comfort zones and master stress. I know developers who have used public speaking as self-therapy against shyness. Being able to stay calm in stressful situations is a communication superpower!

💡Ask a local or remote meetup if you could do a short presentation. The audience is usually friendly, and the entry bar is low. Then, learn how to answer a Call For Presentations (CFP) and try your luck in more significant events. The Present! A Techie’s Guide to Public Speaking book also has good reviews, but I must warn you that I did not read it.

Verbal Aikido

A few years ago, I started attending a weekly Verbal Aikido dojo. The goal of Verbal Aikido is to transform conflicts into constructive conversations. Conflicts tend to shut our neocortex off and trigger our reptilian brain to freeze, fight, or flee. Regular real-world conflict practice taught me to deal with difficult situations more peacefully.

💡To try Verbal Aikido, join the online dojo every Monday. I will also give intro workshops for developers at public events—for example, XCraft Lyon and XPDays Benelux in November 2023.

Non-Violent Code Reviews

(Bully) Why do you do that? (Author) … (Bully) No, I mean, as a job.

I wouldn’t say I like code reviews. Whenever I can, I replace them with pairing. Yet, Matthieu Tournemire and I are writing “The 1-hour Event Storming Book” together. We don’t have overlapping writing time slots, so we resorted to text reviews. Like code reviews, it was a collaboration challenge. How can we give valuable reviews while keeping the author’s intrinsic motivation? The Non-Violent Communication pattern of observation, feeling, need, and suggestion does wonders for reviews. Guess what? It also works like a charm for code reviews!

• It does not trigger conflict.
• It gives autonomy to the author to improve the code and learn.

As a complement, Verbal Aikido techniques are great for de-escalating harsh reviews!

💡Try it! Next time you give a review, for example, in a coaching session, use the NVC pattern to express your point. There are NVC cheat sheets for feelings and needs! Remember also that suggestions are only suggestions!

Liberating Structures

Liberating Structures were developed by Henri Lipmanowicz and Keith McCandless. Liberating Structures are licensed under a Creative Commons License.

I had the chance to learn Liberating Structures during an Immersion Workshop. It was a transformative experience. Liberating Structures are facilitation bricks to create inclusive and engaging experiences. It transformed all the collective interactions I have. Liberating Structures are the best tool I know to leverage collective intelligence. They also scale very well to large groups. They have made all my meetings and workshops shorter and more effective. Even my public conferences now rely on Liberating Structures!

💡To get started, try to join a local user group or register for an immersion workshop. You can also check the Slow Code Retreat. It has detailed instructions and can serve as a Liberating Structure Immersion Workshop.

Communication Dojos (In progress)

We are getting to my current ongoing initiatives. As I wrote above, some skills, like NVC or Verbal Aikido, take time to master. The key, though, is practice. The more we practice, the better we get at them. I am currently experimenting with communication dojos. The idea is to regularly and safely practice real collaboration or communication issues. It could be a harsh code review, a pushy salesperson, or making the case for refactoring. I hypothesize that a team could protect itself against a stressful environment!

💡The Improv Prototyping liberating structure is the perfect fit to run such events. Getting someone with experience in NVC or Verbal Aikido would also greatly benefit the group. I’ll keep you updated as I learn more from this practice.

Open Space Architecture (In Progress)

Event Storming is the only collaborative design workshop I know that works with more than ten people. Unfortunately, it is not the answer to all architectural questions and challenges. Fortunately, Liberating Structures also scale very well to large groups. I am experimenting with combining liberating structures to run large collaborative architecture workshops. Such workshops should yield better results in less time. If I am right, it will scale engagement, understanding, motivation, and alignment to large audiences!

💡I will give a workshop on this topic at XPDays Benelux 2023. I’ll keep you updated as I learn more.

Core Protocols (In Progress)

Core Protocols are not new, but I never took the time to look into them. I have lately been reading and collecting feedback from real users. I’d like to see how I can combine them with other practices. In particular, I’m thinking of Liberating Structures, Verbal Aikido, and mob programming. Could Core Protocols boot a better team dynamic in a short time?

💡Software For Your Head is the reference book about Core Protocols, but it is said to be a challenging read. Core Protocols experts say the best way to learn is to attend a course or a “boot camp.” So my best advice would be to find a trainer!

Combine and Compound

An interesting aspect of communication techniques is that we can innovate by combining them. For example:

• I replaced all my “gathering” with Liberating Structures.
• Improving my writing showed everywhere, from code to emails.
• Inspired by Core Protocols, I designed “mobbing cards” to silently express common reactions in the mob. (Note: I might write more about that later).
• My team and I are also experimenting with “1-2-4-all-Design!” to ‘pause’ the mob for 1 or 2 rounds of introvert-friendly design time.

Almost every day, I spot times when my communication could have been better. And I’m sure my list will continue to grow! The better our communication skills, the more we can combine them to create beautiful experiences for us and those around us. Every new technique we learn does not add to our impact; it multiplies it!

Always bet on communication!

Team collaboration and communication can make or break technical coaching! We can coach by example and fix broken teamwork by being good collaborators. It starts with us!

There is an almost infinite list of communication techniques we can learn:

• From deep listening and connection, with practices like Non-Violent Communication and Verbal Aikido
• To disruptive group collaboration with Event Storming and Liberating Structures!

Whatever your interest and need, there is a fun way to grow your collaboration skills! Select a topic, start learning, experiment, and share your experiences.

PS: I am thinking of writing a book about communication and collaboration activities for teams. The title could be “Collaboration Activities to Fix Software Problems.” It would link collaboration techniques to common software problems and provide step-by-step fixes. I’d love to know what you think of the idea.

After discussing with a few participants, we would like to spread this workshop. Could you come to run meetups in the area where I live?

I liked how you made us go around the room and meet each other.

The facilitation was excellent, better than anything I have seen before!

Previously, I introduced the Slow Code Retreat against their never-ending backlog of tasks.

I recently ran the Slow Code Retreat at Devoxx Paris, Newcrafts, and DDD Europe. Feedback has been great. Some people even wanted to run the workshop in their communities and teams! Unfortunately, the workshop may seem challenging to facilitate at first.

I want to facilitate the slow code retreat workshop myself. Wouldn’t it be great if I could grow my facilitation skills simultaneously?

Detailed Instructions for Facilitating the Slow Code Retreat Workshop

Matthieu Cans was an enthusiastic participant in the workshop at Newcrafts. After the session, he asked me if he could re-run the workshop at Alpes Craft the week after. With the slides, Matthieu ran the workshop both at Alpes Craft and at his company with his co-workers. He received similar feedback as I did. Again, some participants said they wanted to spread this wider.

We need to re-run this workshop in our communities, companies, and other conferences!

Here is a detailed PowerPoint presentation (.pptx). The presenter notes include step-by-step facilitation instructions. I licensed the slides under Creative Commons. You can freely use and adapt them as long as you mention the source and keep the same license.

Spread Slow-Code AND learn Liberating Structures

I prepared the Slow Code Retreat with the Liberating Structures facilitation system. The workshop’s goal is to help developers achieve a sustainable pace. But as a bonus, it will also teach you how to facilitate using Liberating Structures!

You are safe: your audience will love the slow-code-retreat

The feedback from workshop participants has been consistently positive. Many expressed how the workshop has had a profound impact on their work.

I will take his advice and start doing the things he taught us. It will make me a happier and more calm engineer. - Participant at DDD Europe

Big impact! How to look at development as a training system. - Participant at DDD Europe

Thanks a lot for this workshop. It had a real impact on my way of working. - Participant at NewCrafts

😂 I attended the Slow Code Retreat because I wanted to ‘commit’ to a more sustainable coding lifestyle! - A joke by Chat GPT

This workshop is particularly well-received by experienced developers. Juniors may not be ready to embrace that there will always be more work than time 😱 ! Consider your audience to determine if this workshop is the right fit for them.

You can do it: the slow-code-retreat is reusable by design.

)

The workshop is a string of Liberating Structures:

1. Get in the mood with Spiral Journal (in english)
2. Meet and share with Impromptu Networking
3. 5 minutes of storytelling to explain how I came up with this idea of Slow Coding
4. Sharing what Slow Coding is with Gallery Walk (in english)
5. Experiment with different flavors of Slow Coding using Improv Prototyping
   • Live coding demonstration
   • Setting up groups and development environments
   • Approximately 30 minutes of slow coding
   • Retrospective using 1-2-4-All
   • You can start with an optional solo round if time allows
6. 5 minutes of storytelling to explain what I have learned with Slow Coding
7. Takeaways with 15% Solutions

If you have a co-facilitator, you can even replace the two storytelling steps with a Celebrity Interview, which would be a 7th Liberating Structure.

Liberating Structures create high-quality and reusable workshops. For proof, other facilitators ran the Slow Code Retreat with success.

You will learn: the slow-code-retreat is a Liberating Structures training.

We typically learn Liberating Structures through practice. The idiomatic Liberating Structures training is a 2 or 3 days Immersion Workshop. The Slow Code Retreat can act as a mini immersion workshop.

💡 Run the Slow Code Retreat and get a taste of the surprising power of Liberating Structures!

I first heard of Liberating Structures at XPDays Benelux 4 or 5 years ago. They looked interesting, but I classified them as “yet more facilitation activities.” As a result, they always ended up at the bottom of my learning list. I understood my mistake when we looked at how to train Murexians to workshop facilitation.

🤣 Am I becoming a Liberating Structures fanboy?

So, why should you learn Liberating Structures instead of other facilitation techniques? Liberating Structures are a disruptive language for collaboration. They radically shift how people work together!

• They encourage contributions from everyone.
• They thrive in complex and diverse environments.
• They have a viral aspect, and they propagate and spread by design.
• They can scale to accommodate groups of 100 or more.

The Slow Code Retreat workshop is mostly a sequence of Liberating Structures. That is why facilitating this workshop will teach you your first Liberating Structures.

As written above, Liberating Structures are viral. So you are likely to see some of the participants reuse 1-2-4-all in a later meeting!

Run the Slow Code Retreat and Incorporate Liberating Structures in Your Workshops

Like Matthieu Cans, run the workshop, and spread slow coding while becoming a better facilitator!

Find your audience and send an invitation! Before the session:

1. Check the slides’ notes for the invitation and purpose of each structure.
2. Read the official descriptions of these Liberating Structures.
3. Observe how they are adapted to the Slow Code Retreat. That should give you the knack of Liberating Structures.

In your future workshops, add high return-on-investment structures such as:

• 1-2-4-All
• Impromptu Networking
• 15% Solutions

These structures are excellent starting points to enhance your facilitation skills. Once you are at ease with those, pick another in the Liberating Structures menu.

Finally, if you improve the slow code retreat, please contribute back through Github. This way, we will get the workshop better together.

Other posts that might interest you:

• Learn why you would want to run a slow code retreat: A “Slow Code Retreat” to be less in a hurry.
• Another workshop guide: A Quality View Workshop to Discuss Technical Excellence.
• And another: A complete workshop for your team to see what’s a good test strategy.
• 5 Whole-Team Workshops To Increase Developers’ Role In Sprint Planning.
• A guide to run TCR sessions code katas: How to make TCR evolutionary design practice sessions irresistible.

The average Scrum “installation” is not delivering what it could for the organization, and quite often making the lives of the people at the code face worse. I also believe that the practices and understanding of what was called XP can help developers with that, if only we could reach them.

It may be true that Scrum’s customers like Scrum. I believe that by and large, Scrum’s users quite often do not.

We may need to literally form a new “anti-Agile” community to support these ideas, abandoning the word “Agile” to the many ways it has been watered down and perverted.

As a technical Agile coach, working with a team that bad Scrum or Agile practices have hurt can be challenging. These negative experiences can lead to skepticism and resistance towards anything “agile” related. As a result, gaining their trust and engaging them in XP practices becomes challenging.

🤣 Regardless of what the SAD MF says, there is no need for training the resources since everything is readily available on the SAD website. Management probably also forgot possible training expenses in their YSVIBAICS. (Satiric Transition to Scale Agile DevOps Maturity Model. Check it out for a good laugh)

I’ve had my share of failures when working with teams that had been imposed an Agile-Method™. They were viewing all agile stuff, me included, as:

• At best: useless bureaucracy
• Or worst: a sneaky way to spy on them and ensure they remained busy and productive 100% of the time

Wouldn’t it be great if we had ways to connect with developers without mentioning Agile or Scrum?

What can we do?

Let’s talk about Baby Steps.

XP or TDD might be associated with traditional Agile and Scrum, which often leave a sour taste for the team. However, we can bridge the gap and rebuild trust by starting discussions around the Baby-Steps programming. By focusing on Baby Steps, you can introduce technical practices from a neutral point of view.

🤣 90% of Scrum or Agile implementations are crap! (My adaptation of Sturgeon’s Law to Agile)

Just highlight the practical benefits of small, manageable changes to the code:

• Baby steps allow developers to learn on the way, adjust, and steadily build new features.
• Baby steps make decisions reversible. Baby Steps save developers from being dragged by previous choices.
• Team members will regain a sense of control and autonomy over their work.
• With time, they will understand that Baby Steps also apply outside the codebase.

Baby Steps are not a rigid recipe! Instead, baby Steps are about continuous learning, adaptation, and delivery at a steady pace.

My experience at Devoxx

I recently had the opportunity to present a talk on Baby Steps at Devoxx Paris 2023. While preparing for the session, I searched for the most effective ways to pass a message through. I picked advice from How Minds Change and combined them with Liberating Structures. My goal was to create an interactive but also engaging session! The talk triggered a lot of exchanges and storytelling. (Note: Tell me if you want me to share more about this talk recipe in a new post). Here are some of the feedback I got:

Nice format that made the wide applicability of baby steps emerge

I liked the participatory format, which was original”

This approach could work with your team as well! It encourages active participation so that developers express their concerns, challenges, and aspirations.

After the talk, some people asked me how to take Baby Steps within their teams. Some even shared personal blockages about Baby Steps and sought advice. The fact that people are ready to share personal stories is a clue. “Listening and storytelling” is a powerful strategy to interest teams in Baby Steps!

What you can do

How to fix bad Agile?

Are you doing technical coaching with a team that bad Scrum or Agile has hurt? Try to talk and exchange about Baby Steps instead of trying to persuade them about Agile or Scrum.

Baby Steps are more ‘neutral’ and will make developers more open and receptive. Focus on the practical benefits of Baby Steps on continuous code improvement. In the long term, developers will transpose continuous improvement to teamwork and processes. That’s how they will finally overcome the negative connotations of traditional methodologies.

Feel free to use my sketch notes as visual support in your discussions.

Let’s embrace the power of small and incremental steps! Baby Steps can empower developers to work with confidence and clarity!

Here are other posts that might interest you:

• How to coach a team that has been burnt by bad TDD
• How to handle “TDD does not work in real life” during code katas
• A surprising way to teach evolutionary design
• How to make TCR evolutionary design practice sessions irresistible
• Make Testing Legacy Code Viral: Mikado Method and Test Data Builders
• Incremental Software Development Strategies for Large-Scale Refactoring #2 : Baby Steps

The main problem is not agreeing that technical excellence is essential for the success of the delivery. Corporate culture is 100% focused on feature factory, delivering features at the expense of technical excellence.

Tools have taken over the meaning. I need to chant “The card is a token for an ongoing conversation” over and over.

The devs had no say in what stories went into the sprint.

Developers are often stuck in their development roles. They are rarely involved in product management decisions. Non-technical people are usually not aware of the importance of technical practices.

Without the required technical work, code degrades, and maintenance increases. Eventually, work becomes less sustainable.

As coaches, we see teams and developers suffering from this situation. From experience, we understand where this is coming from. Yet, we are often at a loss about how to make the business care about agile technical excellence! Without enough attention, trying too hard will make us disillusioned and rebellious!

Wouldn’t it be great if you had a trick to make people collaborate? So that they found solutions to deliver features with technical excellence in engineering?

Quality Views could be this trick! Let’s see:

1. How I began to work with Quality Views
2. A workshop guide to collaboratively build a Quality View
3. What to do after the workshop

Quality Views as a trigger for discussions

The company I work at, Murex, has been and is still hiring a lot. Therefore, onboarding of new developers is a critical topic. New joiners have a lot to learn:

• Technical skills
• The financial domain
• And a few inevitable obscure pieces of code.

Some teams asked if my team and I could help them to onboard new team members. We had heard how Colin Breck used Quality Views to tackle technical debt. We had the idea to use Quality Views in a workshop to get the whole team to discuss how to speed up onboarding.

I think the most valuable aspects of employing Quality Views are in the discussions that take place in forming the quality dimensions, evaluating the various components, and prioritizing the work. (Colin Breck - Reflections on Using Quality Views)

Our goal was to trigger onboarding discussions between developers and non-technical stakeholders. It should lead to knowledge-sharing or onboarding-time-reduction actions being prioritized.

To learn more about Quality Views, I highly recommend you to read these two posts from Colin Breck:

• Using Quality Views to Communicate Software Quality and Evolution
• Reflections on Using Quality Views

If you prefer videos, you can also check his QCon talk.

We came up with a workshop involving the whole team, including Product Owner. Here is the skeleton:

1. Developers collaboratively build a Quality View of their codebase.
2. They annotate it with their capability to work in the different modules.
3. Then, the view is decorated with the expected impact of upcoming features.
4. With this complete Quality View, participants agree on the hotspots to work on.
5. Finally, they come up with concrete actions to make onboarding easier.

Different teams did the workshop. Here is the feedback we collected a few months later:

The graph output helps to iterate and can be used repeatedly to inform decisions. (A Product Owner)

What I liked the most about the workshop was the interaction between all the team members (A Tech Lead)

Following the workshop, we did some actions regarding documentation and API simplification. (A Tech Lead)

Building a Quality View as a team is an occasion to discuss crucial yet overlooked topics.

Technical excellence in engineering falls in this class of topics! In our case, the starting point was onboarding, but people talked about:

• Business risks
• Technical debt management
• Workload, stress, and sustainable pace.

A whole-team workshop to create a Quality View

Tech-Leads have a pretty good knowledge of their codebase. So they could draw an accurate Quality View by themselves. Through our coach’s goggles, though, this is a missed opportunity for collaboration!

People and collaboration over processes and tools (Agile Manifesto)

That’s why it’s better to build the Quality View together. Below are detailed steps to collaboratively draw a Quality View.

I usually run workshops in a series of 90 minutes sessions:

• It’s a sustainable pace for remote.
• And it leaves time for people to do “homework” or data gathering between sessions.

Two sessions are usually enough, but your mileage may vary.

1. Define your quality characteristics

First, before the workshop, define the quality characteristics you will be using. You can select them alone as a workshop designer if they are obvious. You can also have a short brainstorming and voting session if it makes more sense.

The categories that I developed are not prescriptive—the categories were simply the most important aspects to my team at the time. (Colin Breck - Reflections on using Quality Views)

Here are the characteristics we used for a team working within a legacy monolith:

• Size of module
• Code complexity
• Testing
• Number of bugs in the last six months
• The capability of team members to work in a module

2. Homework

Before the workshop, ask people to collect data on the quality characteristics.

If you have read Colin Breck’s posts, you might be thinking: “Wait! That’s not what Colin said!”:

Objective measures are no panacea. It is not hard to envision a component with exhaustive unit-test coverage, that is difficult to evolve and deploy, and fails to meet business requirements in terms of performance, high-availability, or security. This is why quality needs to be represented more comprehensively, often with qualitative measures. (Colin Breck - Reflections on using Quality Views)

Metrics are great conversation triggers. Ask different people to collect different metrics. This way, data will serve as a basis for discussion but will only weigh a little. As you’ll see later, visualization will remain very qualitative.

3. Prepare a formalism

To collaboratively design a Quality View of a codebase, people need to agree on how to represent it. Of course, you can do this alone as a workshop designer, but I encourage you to get as much feedback from the team as you do.

This visual representation can become even richer, however, with the addition of information related to software quality and how the system is evolving. (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

Here is what we used in our example:

• Boxes for code modules
• Size of the box for the size of the module
• Color of the box for the code quality
• Weather icons to represent the testing
• Lines between boxes for dependencies.
• Bug icons for bugs in a module
• Colored avatars for the capability to work in a module
• Alien icons to tag modules that are not owned by the team

The goal is not to have a formal design document. But you must have something visual that creates shared understanding and triggers conversations.

4. Overall view

I wanted to experiment with extending it to combine 1) our architecture diagram with 2) Tufte’s dense visual presentation of information and 3) my colleague’s stacked bar-graph approach, to show both the quality of the components and the evolution of our system. (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

Let’s start the workshop finally! The first step is to draft the system, using only boxes for modules and lines for dependencies. So use plenty of stickies or an online whiteboard (Miro, Mural, Powerpoint online, or Google Slides…).

Lines don’t need to be oriented. Rough dependency visualization is good enough to have a conversation.

The 1-2-4-all scheme does wonders:

• Everyone gets 5 minutes of solo work to roughly draft the system.
• 10 minutes in pairs to merge their draft
• 20 minutes in groups of four to merge further
• 20 to 30 minutes to merge with the whole team

If the group cannot agree, either redo a round or stop the session and ask for homework to clear things out.

Note: if you are running the workshop remotely, use 1-3-all instead of 1-2-4-all. It’s much easier to manage with breakout rooms.

5. Size of modules

You now have an agreement on the high-level design. So, do another round of 1-2-4-all to resize the boxes according to the size of the modules. This step is faster than the previous one, so shorten the timings for the 1-2-4-all steps.

In remote, it’s easy to clone the model from the previous step so that everyone can have their own.

If co-located, pick a mid-sized module and agree on it as the standard. Then ask participants to draw modules of relative sizes on paper. They don’t need to replicate the dependencies.

Some participants will know the exact number of lines of code. Others will use their intuition. This will generate interesting discussions.

It is the qualitative aspects, involving our intuition and experience, that are more valuable than any set of quantitative metrics. (Colin Breck - Reflections on using Quality Views)

Finish by updating the central model.

6. Code quality

Is the code itself in good shape? Is it well factored? Is it maintainable? Is it reasonably easy to extend the application to add new functionality? (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

Repeat the same process as above to color the modules according to the quality.

7. Testing

Does the component have tests to support making changes without introducing regressions or undue risk? Are the tests repeatable and reliable, and can they be executed in a reasonable time-frame? (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

Again, do the same thing for testing. Decorate the modules of the central model with weather icons to show how they are tested.

8. Capability

Does the component carry significant business risk? This might include code that was developed by an individual that has departed the company that no one else is familiar with; code that is not in one of the primary programming languages used by the development team; (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

In our story above, the workshop’s goal was to tackle onboarding and knowledge sharing. It’s associated with the “Bus Factor” risk. Here is an example of how you can track this risk.

Everyone annotates each module with their confidence to add a feature there.

Murex has been using Situational Leadership 2 for a long time, so we piggybacked on it. It provides four development levels of capability that are easy to self-assess:

• D1: “I know nothing, but I am eager to start!”
• D2: “I know enough to know that I’m going to suffer when I try.”
• D3: “I guess I’ll manage, but I’m always a bit scared to do this…”
• D4: “I’ve done this many times, don’t worry, I’ll handle it.”

Before session homework! Everyone was to watch this short video of Situational Leadership 2.

We then asked participants to place a small colored box with their names on the module. We used red for D1, orange for D2, yellow for D3, and green for D4. We reorganized these icons as histograms. These histograms represent the Bus Factor risk profile of every module.

This was just one example of our situation. For each relevant business risk, take the time to prepare a specific activity.

9. Bugs

This is when the Quality View starts to receive delivery data. At the beginning of the workshop, we gave homework to track lines of code affected by bug fixes in the past six months.

Have the people who collected the bugs info place one 🐞 icon on a module every time it was modified in a bug fix. In the end, you should get a good idea of which modules are sources of bugs.

This is also an excellent occasion to take a step back and discuss this view with everyone.

10. Upcoming features

Since becoming a team lead, I have been looking for ways to communicate two things regarding the software our team is responsible for. The first is the current state of the software. I want to communicate the quality of the system in terms of business risks—the reliability, scalability, and security of the system, as well as how receptive the software is to change, in order to meet future business needs. (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

This is the moment to get product stakeholders in. Before anything, please take a moment to present the Quality View and answer their questions. They will love it! It’s often the first time they can understand what “Under the Hood” is.

Ask them to list the upcoming features they are thinking of. Target something like 3 to 6 months, depending on the rhythm of your business.

Also, ask them to sort these features into three value buckets:

• High value
• Medium value
• Low value

Wait to try to map these features to the Quality View. The team will do that just after.

11. Future impacts

I want to communicate the quality of the system in terms of business risks […] A legacy component that lacks test coverage, or developer expertise, could be extremely difficult, risky, and costly to change, whereas a well-designed, well-factored application, with good test coverage and developers familiar with the code, might be evolved reliably and efficiently. (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

Developers will try to predict what modules will be changed soon. Ask them to list, for each feature, the affected modules. Use rounds of 1-2-4-all (see Steps 4 and 5) to aggregate predictions.

Finally, for each feature, add diamonds to every impacted module:

• Each module involved in a high-value feature will get three diamonds (💎💎💎)
• Each module involved in a medium-value feature will get two diamonds (💎💎)
• Each module involved in a low-value feature will get one diamond (💎)

Some modules might get plenty of diamonds!

12. Hotspots

Quality views are not about features versus quality. They arise from the understanding that in order to deliver high-quality systems, business objectives and customer requirements must be met, or exceeded. It is fine to keep focusing on features, but if customers cannot realize those features reliably, then nothing else matters. (Colin Breck - Reflections on using Quality Views)

At this point, all participants should have a 360º of the situation.

Unfortunately, you won’t be able to fix everything. Yet participants have all the information they need to make wise investments.

Give each participant 3 “dots” that they can place on the module (or dependency) they want to focus on. For example, in our workshops, we use flame icons (🔥).

The modules with the most dots are your “Hotspots.” Hotspots are areas of the code that are at risk of slowing down delivery.

13. Discuss and Decide what to do

The Quality View invites a holistic view of the system. When I presented a similar scenario at a quarterly-planning meeting, our Director of Product Development remarked: “How come those two components are still so red!?”. A constructive discussion followed, where we all came to the agreement that investing in these components would not be cost effective. We were comfortable accepting the short-term risks. (Colin Breck - Using Quality Views to Communicate Software Quality and Evolution)

The Quality View is complete, and everyone understands it. So it’s an excellent time to have the extensive all-in discussion you wanted to trigger.

Bring the prioritization topic forward. Stakeholders will be more conscious of technical tradeoffs now. As a result, the team should be able to build a more realistic and long-term plan. Decisions should take both features and agile technical excellence into account.

After the workshop

Strike the iron while it’s hot!

Feel free to run a follow-up workshop focusing on different aspects. For example:

• Mapping current to vision To decide if you should rewrite or refactor a component.
• Building a Core Domain Chart To identify a refactoring strategy for a component. Example: thorough refactoring, cosmetic refactoring, or replacing in-house code with a third party…
• You can invent any follow-up workshop for your specific challenges. For example, here is how we ran activities to speed up onboarding.

Onboarding at Murex

Remember how this post started. We ran these workshops to speed up onboarding and increase knowledge sharing. So in our case, we ran two extra activities after the Quality View:

• A give-and-take matrix to collect everyone’s needs and potential help.
• An activity to refine help suggestions into SMART and collective actions.

Teams ended up with very focused and high-impact actions like:

Next time Sally needs to debug module X, we will pair. I will show the key places to add breakpoints, and we will go through debugging together.

Participants liked that these actions were concrete and laser-focused. Compare this to the typical evasive knowledge-sharing actions: “Let’s write some documentation.”

Follow-up

As coaches, your main work after the workshop is to make sure these actions are prioritized and done. Insist that the team adds them to its backlog. Don’t hesitate to gently provoke team members if you see that nothing happens.

Finally, nudge the team to re-run the workshop regularly. Updating a Quality View is much faster than creating it for the first time. Please don’t make it too short, though: new joiners should try to sketch a Quality View by themselves. It’s an excellent chance to discover the system one is part of.

Here is what you can do now

Next time you work with a team that has no time for ‘back-office’ technical work, give this workshop a try! It’s bound to trigger interesting discussions with all stakeholders.

On top of that, drawing a Quality View collaboratively is a great way to share knowledge within the team.

Other posts that might interest you

• 5 Whole-Team Workshops To Increase Developers’ Role In Sprint Planning
• How to coach developers to get a chat with their product experts
• How to estimate velocity in Scrum to escape the feature factory
• Leverage Scrum to workaround feature-factory sprint planning
• A complete workshop for your team to see what’s a good test strategy

I used to share and bring new knowledge through the organizations I have been in. But in my new job, it looks like no one cares!

Sadly, I spend less and less time coding for the project. But I find that people respect coaches who are in the trenches with them!

Damn, I again got caught in an abstract ‘large-scale agile transformation’ discussion… This leaves me anguished every time!

As change agents, it’s natural to wonder how we could have a broader impact on the organization where we work. Isn’t our goal to transform how people work?

Unfortunately, you are among many parameters that influence an organization’s evolution. Focusing on wide-scale organizational transformation is no guarantee for results. In fact, this behavior can lead to exhaustion!

Wouldn’t it be great if you had the formula to refill your energy for sharing with people? Whatever is the organization evolving into?

Let’s see how to avoid the trap and still make a difference.

“Local Action, Global Impact”

I borrowed this motto from environmental protection movements. I recently read Let my people go surfing by Yvon Chouinard, the founder of Patagonia. The company has been subsidizing environment-protecting activists almost since its creation. One key point they make when selecting a group to support is that it is local and does local actions. Here is why:

• These people know the situation better.
• They have “skin in the game” to protect their homeland.
• They will be able to defend their cause better.
• Small groups waste less time and money on bureaucracy.
• As small wins pill up, they tilt the public opinion and the law.

Let’s copy these hardcore change agents!

Change only happens one person at a time, as they switch to a different point of view. Change happens locally, by nature! Simon Sinek supports this idea in How to Make a Cultural Transformation. He explains that the only sure way he knows to make cultural change is to win over 15% of people. You do this by meeting them and making their lives better.

It means spending as much time as possible working with or for teams. It also means limiting the energy we burn for “large-scale agile transformation.” It’s too easy to get caught up in this topic. I try to remember to reassess my priorities regularly. I adapt whenever I see that I am disconnecting from teams and talking about change that I cannot control!

Not only does the “Local actions, Global change” strategy works, but it will also make your life lighter!

1. First, you will stop worrying about the unachievable goal of “large-scale transformation.” Instead, enthusiastically work with people and consider broad change a bonus.
2. Second, you don’t have to ask for permission to bring change! Just make things better for you and the people around you.

Local Actions

If you had not yet understood 😉: Local actions are where you should invest your time and energy!

Examples of local actions

The prominent local actions are about helping team members with their day-to-day issues. For example:

• Running whole-team workshops to tackle particular topics and to break silos. Check out 5 Whole-Team Workshops To Increase Developers’ Role In Sprint Planning. (We have recently experimented with a workshop to build quality views, let me know if you want me to write about it)
• Facilitating mob programming or coding dojo sessions around legacy code or maintainable testing challenges.

Preparing for any of the above also counts as local action. Be careful to get regular feedback and remember that you should be slightly embarrassed the first time you run the session.

You may have heard me say: If you're not embarrassed by the first version of your product, you've launched too latehttps://t.co/r4JyKzzyWO

— Reid Hoffman (@reidhoffman) March 29, 2017

Local action is not limited to teams! Sessions with managers or product managers can be local too. However, keep the focus on their behavior and not that of others!

Another local action is to be present and embody XP’s calm and steady rhythm! This behavior has a lot more impact than we usually think!

You can also host ‘open sessions,’ which anyone from the organization can join! These sessions can be code katas or educational workshops. It’s an excellent way to generate awareness, connect, and provide help.

The direct benefits of local actions

The main obvious benefit of local actions is that we can directly improve some people’s lives! Many developers told me how learning XP practices changed their work life. Their days had become more effective, engaging, and, most of all, calmer.

So, keep in mind that XP improves people’s lives. Focus on local actions. Your energy will follow! Plus, people will listen to you if you remain optimistic!

From another perspective, every local action is a potential conference talk or workshop. Sending proposals or attending meetups is another chance to improve developers’ lives.

Finally, the local action strategy is perfect if you are an embedded coach or a developer! All local actions can be part of your day-to-day job. Make sure to ‘sell’ it the right way:

• Organize problem-solving workshops to make your team more effective.
• Run mob or kata programming sessions to increase the skills of newcomers (and others).
• Run sessions at public conference events to help your organization with hiring.

Global Changes

Focusing on local actions keeps us energetic and optimistic. Moreover, local efforts maximize our long-term chances of inspiring others and triggering more change! Here are examples of broad changes that local actions can trigger.

I’ve said above that XP practices equip developers with a calmer and more productive work life. Less stress at work also means a happier family at home! Who knows? You may contribute to saving couples and healthier kids through technical coaching!

You might inspire others to start local actions too! Don’t forget that any movement begins with a first follower.

When the people you coach move to a new team or company, they will also impact those around them! Maybe they will, in turn, trigger large-scale changes later.

Finally, it is possible that your coaching leads to organization-scale change. It’s a long shot: a lot is outside your control, especially in large organizations. So, please don’t count on it! Yet, if the organization is supportive and you get enough “followers,” you have a chance! Be patient.

Again, all these are bonuses! Don’t expect them. You can expect a local impact if you stay focused on local actions and maintain your enthusiasm. Any local result already has enormous value! And wider change will happen from time to time. So celebrate your local acts, and share stories when a broader impact happens.

Make it a habit

XP started as a local experiment in the C3 project. If the goal had been to spread to every dev team, XP would be a failure. Yet, XP has changed the face of the entire industry. Practices like unit testing and Continuous Integration have become standards. Others, like pair programming, are still spreading. So let’s stick to our local actions! Who knows what will happen?

Here is my final trick to remember to “Act Local.” First, print and keep a large calendar on your desk (you’ll find plenty online). Then, every work day, just before you leave, write down three local actions you did.

It’s a bit like Self-Kudos. Don’t be falsely modest: you are only writing for yourself! Once you are done, step back, and be proud of what you did!

Finally, read back through all the actions you did when you need to lift your mood!

You might also love…

• 3 Questions To Let-Go Technical Agile Coaching Measures
• How to measure (and report 😢) your tech agile coaching effectiveness?
• 5 technical agile coaching tips to fight exhaustion from laggards

The team is good, but the organization mainly pushes them for output!

Developers have as much difficulty changing their habits as anyone else. Besides, we’re too busy.

This manager was in my interview and kept asking me questions like: “what if devs feel they are being slowed down?”.

We all know this story. Learning new practices or taking on new habits takes time. And developers always have something more urgent to do.

Lately, my colleagues and I almost worked with a team struggling with onboarding. We helped define knowledge-sharing actions, trained seniors to run team mobs or katas, etc. Yet, at the moment of setting up team sessions, senior developers were too busy!

There is no workaround: Sustainable pace starts NOW!

In its most trivial formulation, it’s as simple as this. To go from doing A to get to doing B, we have to unlearn A and learn B. That takes time. If we don’t have time, we can’t afford to change. (Slash the Load, Mike Hill).

Teams only have so much control over their time! There are always urgent and valuable projects to deliver. Even productivity and sustainability improvements only add more work in the short term! Very often, management will not grant the team some time for learning.

Sometimes, it might look like there are no ways out!

At every moment, we have the choice to step back and take it easy! Nothing prevents us from injecting some ‘sustainable’ seconds into work. It’s not about what happens. It’s about our state of mind and how we live what is happening.

At first, it can be only a few seconds here and there during the day. With time though, we can train our minds to do this more regularly.

How to slow down at work as developers?

“Inject sustainable instants throughout our day of work” might sound a bit too vague… So let’s see how to do this more practically.

The Slow Code Retreat is a workshop I ran at XPDays Benelux. The idea is to let people experience different ‘slow working’ techniques.

Here is the feedback I received at this workshop.

Here is how the workshop is structured:

1. Welcome
2. Connect with the topic and other participants with these 4 questions:
   • What did you say no to to attend this session?
   • According to you, what could slow code be?
   • From your experience, list a few situations where slow code could have been helpful.
   • What is the big question you bring to this session?
3. Present 6 slow code practices (see below)
   1. One or two rounds of slow code practice on code katas
      • Participants pick 1 or 2 practices they want to experiment with
      • They self-organize in solo, pairs, or mobs
      • For 30 minutes, they go through the simplest katas like Fizz Buzz or Pascal’s Triangle
4. Takeaways
5. Q&A

The complete workshop lasts between one and a half and 2 hours.

6 slow working practices

Participants can try the 6 slow working practices during the workshop. I’ve split them into 3 categories: coding, communication, and mobbing.

Slow Coding

We can use these whenever we are programming solo, in a pair, or in a mob.

Slow TODO List

Take the time to focus only on the present task:

• Keep a TODO list while you code
• Keep track of everything that remains to be done
• Check or strikethrough steps as you do them
• Indent sub-tasks
• Can use a .txt, a .markdown, a shared online doc, or a mind map
• Reorganize your tasks when needed
• If you revert steps that you cannot do yet, it becomes the Mikado Method

Benefits:

• This removes all the mental load involved with keeping track of the status of work
• The map serves as a communication tool for handovers, pairing, or mobbing
• Helps us to drop things that we eventually decide not to do!

References:

• code-in-flow/mindful-programming (github.com)
• TODO list or Mind Map for programming

Slow Baby Steps

Take the time to practice egoless programming and baby-steps programming with TCR:

• Start coding with TCR
• Whenever you get reverted
  • Notice the feelings you experience and accept that error is humane.
  • Practice humility and Egoless Programming
  • Try again with a smaller step
• As the day goes by, notice how your capacity for flawless work decreases!

Benefits:

• With time you’ll learn how much you can do without mistakes
• This teaches you to do extra small steps that cannot go wrong!
• This helps to understand when to call it a day and leave
• This avoids writing low-quality code when you are too tired

References:

• code-in-flow/mindful-programming (github.com)
• The 10 commandments of Egoless Programming

Slow Self-Retros

Take the time to observe what happens inside us:

• Set a timer to ring every 5 minutes
• Every time it rings, take a short pause and fill out this log individually:

• Use cheat sheets for feelings and needs references.

Benefits:

• Helps us to spot our non-constructive reactions to events like:
  • “I don’t know how to do that!”
  • “Damn, I was sure this test would pass! I’ve got no idea why it’s failing!”
  • “How stupid I am!”
  • “I don’t understand anything about this code!”
• Develops our knowledge of inner feelings and needs.
• Provides plenty of data for continuous improvement and retrospectives of all kinds.

References:

• code-in-flow/mindful-programming (github.com)

Slow Communication

For the sake of organization, I put only Slow Code Reviews in the category of slow communication. Yet, Slow Navigating could also go in this section.

Slow Code Reviews

Take the time to offer non-violent feedback to your colleagues:

• When writing reviews
• When voicing feedback in the mob
• Follow the Non-Violent Communication pattern:
  • List the facts
  • Share your feelings
  • Share what needs you have
  • Suggest a new way of doing things that meets everyone’s needs

Benefits:

• It prevents conflicts from building up for the wrong reasons
• It improves teamwork, psychological safety, but also the efficiency of reviews
• It leaves the door open for more creative solutions
• It builds our feelings and needs fluency and self-awareness
• It is a way to start learning Non-Violent Communication

References:

• Nonviolent Code Review
• Five Strategies For removing Violence From Code Reviews
• Non-Violent Communication In Code Reviews: Receiving Comments
• Resolving Code Review Conflict In A Hippie-Dippie Way

Slow Mobbing

Finally, here are two practices specifically suited to mobbing or pair programming.

Slow Driving

Take the time to be aware of your feelings and thoughts when driving:

• Accept, or even better, relax into being navigated!
• Stay focused on typing and do what you are asked to do
• Focus on the touch of the keyboard and what displays on the screen
• Don’t judge what you are asked to do
• Breath while compiling or running tests

Benefits:

• This driving ‘pause’ makes the mobbing more sustainable
• It helps to take a step back:
• Let your creative mind work in the background
• Come back to navigation with a new perspective

References:

• [Mindfulness For Programmers. 3 simple exercises to be more present…

  by Julia Di Russo

  Towards Data Science](https://towardsdatascience.com/mindfulness-for-programmers-da6f92147b8f)

Slow Navigating

Take the time to practice egoless programming while navigating in the mob:

• When other mobsters seem to be struggling with something you’ve figured out:
  • Observe any criticism or judgment that you may feel.
  • Instead, try to be patient and compassionate.
• When you struggle to understand or solve something:
  • Observe any self-criticism or self-judgment that you may notice
  • Instead, try to accept these feelings and let them go.
• When other mobsters come up with different solutions than you: - Strive towards egoless programming and humility by welcoming their solution 

Here is a variant:

• Take a step back in the mob:
  • Strive to remain a neutral observer of the mob
  • Keep a log of what is happening and the mood of the mob. (a bit like Slow Self-Retro)

Benefits:

• A compassionate behavior builds psychological safety, improving decision-making and team performance.
• A “mob log” can be handy for continuous improvement and retrospectives.

References:

• Extreme Programming Creator Kent Beck: Tech Has a Compassion Deficit
• The 10 commandments of Egoless Programming

Try the workshop!

Here are the slides for the workshop I gave at XPDays Benelux.

My first recommendation is to try the workshop yourself. My first try at “slow self-retro” was mind-blowing. I was dumb-struck to see the emotional roller coaster a simple kata would get me through! If you have close peers to try it with, slow mobbing will teach you even more!

Also, next time you face a team with no time for coaching, don’t try to force it into their calendar. Has the team got “down time” in its calendar: Scrum slack-time, SAFe Innovation & planning? (Or August in France 😉?) Suggest volunteers try this 2 hours workshop during this downtime:

• “Slow Driving” and “Slow TODO List” make work more sustainable and productive from day 1!
• The other techniques need more time to install (that might be a topic for a follow-up post)
• All practices will get them to explore an ignored facet of software development

Whatever you try, I would love to read your feedback!

Here are other articles that might interest you:

• Technical coaching can be exhausting at times. Here are “3 Questions To Let-Go Technical Agile Coaching Measures” and “5 technical agile coaching tips to fight exhaustion from laggards.”
• Here is another post containing other experimental technical coaching practices: “How the pandemic made us discover better ways of coaching.”
• 100% pairing can be difficult for some people. Here is “How to use Mob Programming at the rescue of Pair Programming burnout.”
• Slow TODO List is a direct use of the “TODO list or Mind Map for programming,” the only difference being a shift of intent from productivity to calm.
• “How to help a team to find their preferred mob programming rules?” presents how to use a mobbing code retreat to experiment with new rules for mobbing. This could be the perfect occasion to try slow mobbing!

One of the first teams I worked with as a full-time coach struggled with testing. Let’s call this team Phoenix. It was relying almost only on slow end-to-end tests. The team had just welcomed a few members to make it cross-disciplinary. In addition, the team aimed to speed up the testing feedback loop. So, developers were xUnit-testing while quality engineers were speeding up systems tests.

Around 2 years later, the situation had improved a lot. Developers were getting more confidence in their tests, and end-to-end tests were faster. Yet, the team was still relying on those slow tests. There was yet no coordinated effort towards an improved test strategy. As a result, the team had to overcome a new threshold to further improve their testing.

I also noticed that the team used its own DIY vocabulary for the different kinds of software tests:

• “TPKs” for end-to-end tests
• “offline tests” for any type of developers tests

One thing I’m still unclear on is what you mean by “Integration Testing: and whether it’s similar enough in meaning to what the rest of the folks mean by “integration testing”

I’ve learned to define testing terms before having testing conversations. At one large-sized company, engineers had different definitions for each testing term. E.g., one Pearson’s “integration” test was another person’s “integrated” test.

I agree that “integration Test” has a lot of meanings.

Blurry testing terms are a common symptom of not thinking about “What is a good test strategy for our team?” A lack of testing strategy leads to many problems, like:

• Holes in the test harness, which lead to bugs and rework
• A slow testing feedback loop, relying on old habits, like end-to-end integrated tests
• Increased test maintenance burden because different kinds of test overlap coverage.

With time, these “testing problems” increase the risk of abandoning testing altogether!

Wouldn’t it be great if engineers regularly aligned on testing terms?

Let’s teach a dedicated workshop to the teams!

Phoenix tackled testing issues with an all-in workshop to discuss the testing strategy. During the workshop, all team members were able to:

• Learn industry’s testing best practices and compare their own practices
• Agree and capture testing terms
• Agree about who, how, and when they should test the different aspects of their system
• As a whole team, define and plan an improvement to their testing strategy

Here is what they said about the workshop:

This workshop made me think about many things, thanks to the different questions.

Thanks to this workshop, I enriched my testing vocabulary with new words, such as subcutaneous tests.

It’s like a game; we had fun but also came up with new solutions.

I liked the fact that the whole team participated in the workshop.

More specifically, QA engineers and developers saw that some parts of the code were tested twice. It was clear that to reduce the testing feedback loop, they had to collaborate more. They had to start replacing end-to-end tests with developer tests. At the end of the workshop, they decided to write a first decoupled acceptance test.

A few months after the workshop, the team was now regularly removing end-to-end tests. As a result, developers could enjoy a faster testing feedback loop.

🎁 With better testing comes more sustainable and calmer work!

The Workshop Agenda

You might be wondering what was inside this workshop? Here is a summary of the steps that the Phoenix team went through. The workshop is a succession of 7 steps. All in all, it takes between 5 to 7 hours. Therefore, running this workshop as a series of 1-hour sessions is best.

Step 1: Learn what industry agile trailblazers do

Before the session, we sent homework to the team members. We shared links like:

• DevLin2017 - Aslak Hellesøy - Testable Architectures - YouTube
• 7 Reasons to Choose Consumer-Driven Contract Tests Over End-to-End Tests (reflectoring.io)

The homework was to search the web and these references for different kinds of software tests.

During the workshop, we asked each team member to present a kind of test. To illustrate this, they had to:

• Present a definition to the rest of the team
• And place it on this duration X maintenance X coverage quadrant.

The idea is to learn how the different kinds of tests compare.

Step 2: Draw the ideal pyramid

With this new knowledge, team members could build an ‘ideal’ test pyramid.

It’s funny that this ideal pyramid does not look too pyramidal. Martin Fowler said we should not bother so much about the shape anyway! There is no good-or-bad result. This step is yet another way for the team to apprehend different kinds of software tests.

Step 3: Draw your pyramid

After digging through their test metrics, the team could draw its own test pyramid. We sent the team more homework for this activity. We asked team members to come up with metrics:

• What are your different kinds of tests?
• What is the total execution time of each of these kinds of tests?
• How many assertions does each of these kinds of tests check?

This big rectangle in the middle represents end-to-end tests. It was clear to all the team members that they relied heavily on those!

Step 4: Compare and discuss

Participants had 2 pyramids and a better understanding of the test vocabulary. To continue, they could now map their tests to the industry’s standards.

As you can see, they had to get creative! There is no one-to-one mapping between their tests and the kinds of tests we can find in the industry. This mapping showed how end-to-end tests verified too many aspects of the system.

The team members could now imagine what a good test strategy would be for them. Here are examples of what I heard during the workshop:

We are missing decoupled acceptance tests!

We won’t be able to remove end-to-end tests until we ensure coverage differently!

Step 5: Fill a test Strategy Canvas

The Test Strategy canvas is a one-page template that summarizes how a team tests its software.

One of the goals of this workshop is to agree on names for the different kinds of software tests. That’s done in this step. The Phoenix team members also agreed to a unique test strategy thanks to this activity. This canvas clarifies precisely:

• The purpose of testing in the team
• What is inside or outside the team’s responsibility
• The different kinds of tests: name, constraints, technologies, who runs and maintains them…

Having a whole team converge to a single canvas can look daunting! However, mixing the 1-2-4-all and asynchronous sessions is an effective way to do it.

Here is what the Phoenix canvas looked like:

The grid you see in the middle of the canvas describes every different kind of test. As an example, here is the line for Unit Tests:

This canvas can also serve as a living convention. Fortunately, updating the workshop board should not be too long. Re-running the workshop is also a good onboarding activity for new joiners.

Step 6: Solution focus to get 1 step closer

At this point, all participants agreed on the current situation. They also knew the industry’s best practices. The next step was to go through a Solution-Focus activity to draft an improvement.

This activity constrains the size of improvements to something small and manageable. This lets the PO and the rest of the team find a compromise that:

• Delivers value early.
• Without blocking feature delivery.
• While still going in the right direction.

Step 7: Draft an improvement as a team!

The solution focus activity ends with participants brainstorming the “10% improvement”. Here is Phoenix’s improvement draft:

Final testing improvement the team agreed on.

A key benefit of coming up with this improvement with the whole team is that it is already prioritized! During the workshop, the PO had all the time to build empathy with everyone. He understood how this improvement would make the team more efficient.

💡 A nice side effect is that putting tests in place often involves paying back technical debt!

This workshop was also a way to break silos and give non-developers a look inside the system.

To summarize, such technical whole-team workshops can show a different way:

💡 The way of communication, collaboration, and collective decision-making

Is your test strategy clear?

Did you notice any miscommunication around testing between team members?

• Do they disagree about testing terms, how to test, or how to improve testing?
• Do the different profiles in the team disagree about the priority to give to testing?

If any of these is true, run this Test Strategy Workshop! Find someone interested in facilitating the workshop and help them the first time. They should be able to re-run it later for an update. Running this workshop now and again will result in continuous improvement in testing.

What about you? I’d love to read about other coaching techniques to handle testing disagreements! Finally, if you try this workshop, please comment on how it went or what could improve it.

If you liked this post, you might also be interested in:

• How to make a team facilitate agile architecture workshops
• How to help a team to find their preferred mob programming rules?
• 5 Whole-Team Workshops To Increase Developers’ Role In Sprint Planning
• 3 Good and Bad Ways to Write Team Coding Standards and Conventions
• How We Started Exploratory Testing

A few weeks ago, I wrote that TCR code kata exercises are great for teaching evolutionary design.

Have you suggested TCR sessions to the teams you are coaching? Great! Unfortunately, “Selling” TCR is not easy. Here is what you might notice:

The big pushback to continuous design is of course from devs who insist that they need an end-all solution now, and that it has to be completely implemented now even if the design represents a speculative need.

The harder sell is with people who have been taught that changing the design is “rework waste.”

They used their code review process as a hazing ritual, forcing new programmers to prove they could write everything perfectly the first time.

I’ve also written about “TDD does not work in real life!” complaints. It becomes even worse as we push TDD to the TCR extreme! TCR code kata exercises don’t appeal to developers who believe in “perfect code first.”

What if you had a trick to hook developers on TCR evolutionary design practice sessions?

Lately, my colleague Ahmad started to run kata sessions with a group of newcomers at Murex. One of the first sessions was to practice TDD and TCR with the Mars Rover kata. The group set out for an ambitious test and started to write a lot of code. Despite one mobster complaining about the long step, they pushed on for more than 15 minutes. Eventually, they were confident that their code was working! They saved… TCR ran… and reverted everything!

From then on, the dynamic of the group changed. It went from ego-hero to collaboration against the new TCR opponent. During the end-of-session retro, everyone saw that baby steps were safer and calmer. They also understood that TCR was a great teacher.

To our own surprise, my team and I have discovered that katas with TCR sell better than those with TDD!

1. Before, Present sessions like fun drills
2. Make sure to Run a genuine deliberate practice session
3. Finish the session with an effective retro to transpose practice to real work

Present sessions like fun drills!

How you introduce the sessions greatly impacts the participants’ engagement.

Leverage your pedagogy-expert posture

TCR sounds like a ‘drill’. The word ‘drill’ has an ‘improvement’ connotation and people understand that:

• Drills are different from real-life work.
• Yet, drills positively impact real-life work.

Using such vocabulary also puts you in the position of a pedagogy expert. (Side Note: I am no pedagogy expert, but as a tech coach, I know more than most developers I work with. In the country of the blind, the one-eyed man is king!) As a result, people are more likely to trust you about the learning value of our exercises.

Highlight the fun!

One of the main observations we made about TCR katas is that they are fun! They have a poker-like twist, as we ‘bet’ our code on green tests. We felt this ourselves, observed it in group dynamics, and heard it through feedback.

💡 TDD code katas can be fun, but TCR code kata exercises are even more fun!

Run a genuine deliberate practice session

Keep them in the practice mindset.

Always repeat that this is practice. At first, participants might be unable to use TCR or TDD in their day-to-day work. Remind them that a code kata is a unique occasion to practice by the book in a safe context.

I stopped and reminded them that they were here to learn how to build things incrementally, that they should continue to work through the exercises with that in mind (Jeff langr on extremeprogramming@groups.io)

This should help them to stay engaged at times when they are doubting.

But TCR has yet another advantage. It’s weird and very different from how most developers write code. At first, it’s almost impossible for participants to envision using it in their day-to-day work. As a result, they tend to take TCR code katas as pure exercises. In the end, it’s easier for participants to stay in a constructive practice mindset!

Wait for reverts!

At the risk of sounding sadistic, TCR gives its critical lesson when it reverts our code! If we were running a traditional TDD session, we would have to remind the participants to take small steps.

# Traditional TDD Code Kata
while(true)
   coach.say("Remember not to write too much code before running the tests!")
   sleep(1.minute)
end

💡 With TCR, the best practice is to let participants take long steps!

Most of these extra-long steps end up with TCR reverting the code. Participants might want to ‘cheat’ to recover the code at this point! (For example, you can get it back with a Ctrl+Z in many IDEs). This is the moment to put on your “sports coach” cap:

Hey! This is cheating 😉! This is the crucial moment of TCR. You just learned that this code does not quite work, and TCR is telling you that you need to go slower.

This can be a difficult lesson for some participants. Others in the group will be happy to start from a blank page again, though. Usually, everybody gets over it after a few minutes.

Lean on TCR

As illustrated above, we don’t need to talk much during a TCR code kata exercise. Instead, participants can learn by themselves through the TCR script.

Developers, used to picky compilers, will get far less annoyed by the machine than by a human coach. As a result, it will be easier for them to take a step back and reconsider their opinion.

Also, they will learn what is meaningful to them at this moment. It’s different from us trying to guess what is worth remembering!

To summarize, TCR sessions are more intense and effective and need less coach intervention!

Finish the session with a compelling retrospective

We always end kata sessions with a quick retrospective. It’s essential to take 5 or 10 minutes for participants to discuss what they did and learned. It’s also the best moment to make the decision to change how they want to work. TCR has some critical lessons to bring to these quick retrospectives.

Stop biting more than you can chew!

TCR is a cruel teacher: whenever we try to make a change that outgrows our abilities, TCR reverts it.

After a few hours, one will get a gut instinct about how much they can change in one step without making mistakes!

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. (Edsger W. Dijkstra)

As Dijkstra said, this is a fundamental lesson that is always applicable. We can apply this knowledge to whatever we are working on:

• a code kata or a commercial product
• a greenfield or a legacy codebase
• a professional app or a Sunday pet-project

We’ll have learned this for the rest of our lives! (Note: use TCR regularly to keep the lesson up to date!)

As a coach, we can use the retro to ask powerful questions about this topic:

• What did you notice about the changes that passed?
• What about the changes that TCR reverted?
• How can you transpose this to your day-to-day work?

We have added a new feature in our TCR tool to help participants answer these questions. It’s a pure didactic feature that adds fail and revert commits. Then, through the Git log, participants can retrospect the failed changes. To try it, run the TCR tool with tcr --commit-failures. It does not change anything to the TCR flow, except that you’ll get extra commits to retrospect.

For example, you can inspect the failing changes with git log --oneline --full-diff -p .

4e9bbf5 ❌ TCR - tests failing
diff --git a/java/src/main/java/com/murex/BowlingGame.java b/java/src/main/java/com/murex/BowlingGame.java
index d49fe79..df25c72 100644
--- a/java/src/main/java/com/murex/BowlingGame.java
+++ b/java/src/main/java/com/murex/BowlingGame.java
@@ -30,15 +30,20 @@ class BowlingGame {
     static int score(int... rolls) {
         int score = 0;
 
-        if (rolls[0] == TOTAL_PINS)
-            return 28;
-        if (rolls[2] == TOTAL_PINS) {
-            return 20;
-        }
+//        if (rolls[0] == TOTAL_PINS)
+//            return 28;
+//        if (rolls[2] == TOTAL_PINS) {
+//            return 20;
+//        }
 
         int iRoll = 0;
         for (int iFrame = 0; iFrame < NB_FRAMES; iFrame++) {
-            if (isASpare(rolls, iRoll)) {
+            if(rolls[iRoll] == TOTAL_PINS) {
+                score += TOTAL_PINS;
+                score += rolls[iRoll] + rolls[iRoll + 1];
+                iRoll++;
+            }
+            else if (isASpare(rolls, iRoll)) {
                 score += rolls[iRoll] + rolls[iRoll + 1];
                 score += rolls[iRoll + 2];
                 iRoll += 2;

You can also get a birds eye view of your commit history through your online Git interface:

.

Suggest TCR when refactoring production code

You can also use the retro to nudge participants into using TCR for their day-to-day work. With fast feedback tests, refactoring production code with TCR is pretty straightforward. For example, you can say something like:

If you happen to be refactoring a piece of code that has fast tests, give TCR a try! It makes refactoring calm and practical.

Let’s summarize

Here is my advice to get people engaged in TCR practice sessions:

• don’t mention TCR
• set a “fun and collaborative drills” atmosphere
• let people be reverted
• run impactful session retrospectives

As I wrote above, TCR learnings are surprisingly production-ready! Coachees will feel the benefits pretty fast! After that, they’ll start to look forward to more practice. And as they go through sessions, participants will find TCR increasingly more attractive.

At Murex, we have been building a TCR tool for code kata exercises. You can find it at https://github.com/murex/TCR. You can also find a sample kata repo at https://github.com/murex/Kata-BowlingGame.

What about you? I’d love to read your feedback about getting people engaged in TCR practice sessions! Or maybe you have been using TCR on a day-to-day basis? If you get to try these tips, I’d love to hear how it went!

Here are other posts that you might find interesting:

• A surprising way to teach evolutionary design
• How to handle “TDD does not work in real life!” during code katas
• How the pandemic made us discover better ways of coaching
• How to coach a team that has been burnt by bad TDD
• How the Samman Method helps to sell technical coaching internally?
• 7 tricks to influence a team resisting to change its technical habits

Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach.

More than just software development skills, it [Note: evolutionary design] also takes humility, patience, restraint, discipline, and confidence.

People don’t learn new habits overnight. Three days barely scratches the surface, so sitting with them as they work through real stuff, and showing how things play out, is critical. It can be months before better habits stick.

Performing Evolutionary Design makes the lives of developers better! With it, a team can re-orient its software design according to the latest challenges. This makes progress steadier, more predictable, and the pace more sustainable!

For Kent Beck, master programmers split large code changes into small steps. Baby steps are the building blocks of continuous software design evolution. Baby-steps programming is the fundamental skill for evolutionary design.

Unfortunately, teaching baby steps is not easy. Participants tend to stick to wide steps. Even in a TDD coaching session and even as we remind them!

Wouldn’t you love to run baby-steps training sessions and teach evolutionary design faster?

It turns out that using TCR (test && commit || revert) in practice sessions does that!

How we started to run TCR practice sessions

Thomas Deniffel’s post about TCR Variants made a massive impression on me. I tried TCR with 1 or 2 katas and then suggested to my coach colleagues to experiment too. Everyone liked how it ‘forced’ us to stick to baby steps.

Here is what our TCR flow looks like:

• It watches the file system for changes to the code
• As soon as it detects some changes, it builds and runs the tests
  • If the tests fail, it reverts
  • If the tests pass, it commits
• It repeats

If we are too bold or ambitious (or pretentious) with a code change, the tests fail, and the change gets reverted. One quickly learns that the easiest way to go through an exercise with TCR is to stick to baby steps.

Having participants stick to baby steps during a code kata has always been an issue. So we agreed to experiment with TCR in a few training sessions.

This was a success! The feedback after our test sessions was excellent! As a result, TCR has become the default for every session we run.

What do participants say?

As I said, up to now, feedback has been great. Here are some examples of what people said at the end of a session.

It’s fun!

It’s almost a ‘gamified’ way to go through code katas!

There’s a poker flavor of ‘betting’ on your change.

It stretches coding muscles.

It’s TDD on steroids!

I learned how to do more rigorous katas.

I pushed baby steps to 11!

At first, I was skeptical about the Revert thing. But once I realized it’s meant as a practice tool; I started to appreciate its ruthlessness 😀

It yields more profound lessons.

We were lost in endless refactoring, and the tool taught us a lesson: to let go!

It’s good for the focus because you must stick to what you are doing now. And it’s good for the ego because it’s a script, not a human, that tells you to use smaller steps!

It creates a real feeling of progression!

I learned to focus more on each step rather than wanting to solve the problem.

TCR is like a workout machine!

TCR is a bit like a workout machine for TDD practice sessions. It makes the sessions more challenging and interesting. As a result, it’s a learning accelerator.

What exactly changes with TCR?

A classic TDD practice session

TDD-rookies tend not to run the tests often enough and spend too much time out of green-state. Here is the situation I have often observed:

1. Participants write a test.
2. They write way more code than needed to pass the test.
3. They manage to pass the test with a lot of thinking.
4. Unfortunately, they broke other tests in the process.
5. Eventually, they take 15 minutes or more to debug everything back to green.

As coaches, we have to point out every time they start on such a difficult path, but:

• It’s exhausting to be the killjoy all the time.
• We cannot keep an eye on everyone at the same time. As a result, many participants struggle with long steps.

TCR as a coach bot!

Things are different in a TCR practice session:

• Are participants making an ambitious giant step that fails? => The code is reverted.
• Did they break other tests while passing the new one? => The code is reverted.

TCR keeps the code in a green state. It “forces” participants to stick to baby steps. It does that without us having to remind people all the time. It does that without us having to be there!

As a bonus, we can have more people in a single session!

From TCR to evolutionary design

J.B. Rainsberger explains that practicing micro-steps teaches how to ‘chunk’ them into larger ones. With TCR, participants experience going through a programming task with baby steps. They can even check the git-log to see the detailed steps they used. This is how they learn evolutionary design.

See for yourself!

The simplest way to give TCR a try is to run "test" && "commit" || "revert" instead of just test.

If you are using git, you can commit with git commit -am "TCR" and revert with git restore .. The test command depends on the language and toolchain you are using. Pick your favorite kata and give it a go! If you lack inspiration, go with the classic Bowling Game. I have seen TDD veterans get reverted on this kata and learn from TCR. There’s definitely something for everyone here. I’m sure you will have fun too!

Batteries included!

At work, we have been working on a more advanced TCR tool. You can find it at https://github.com/murex/TCR. You can also find a sample kata repo at https://github.com/murex/Kata-BowlingGame.

Compared to terminal commands, it also:

• watches the file system, and runs TCR as soon it spots some file changes
• pushes and pulls through an online repo to enable remote mobbing with git-handover
• provides a mob timer to switch the driver role during the session
• can commit reverts for participants to retrospect on what got reverted
• finally, it’s also gentler than strict TCR because it does not revert the tests

The tool currently supports git, Java, C#, C++, and Go, but it’s open to contributions!

Give TCR a try and share your experience! I’d also love to read about your tips for teaching evolutionary design.

Here are other posts that you might find interesting:

• How to deliver a remote training with code-katas and randori in pairs
• Incremental Software Development Strategies for Large Scale Refactoring #2: Baby Steps
• A coding dojo exercises plan toward refactoring legacy code
• Why you should start a team coding dojo Randori right now
• How to start a team coding dojo Randori today

3 wonderful workshops that will make your serverless architecture agile

Successfully building a serverless system as a team is far from easy. So, here are 3 DDD workshops for everyone to do collective and incremental architecture.

It’s actually harder to do serverless development with two engineers than it is with one engineer. And [the problem] scales up ~ Nathan Taggart

(From 3 Wonderful Workshops That Will Make Your Serverless Architecture Agile)

A few weeks ago, I wrote a guest post for Marco Troisi on his blog, The Serverless Mindset. It presents 3 workshops: Big-Picture Event-Storming, Design-Level Event-Storming, and Example Mapping. It explains how these workshops avoid command-and-control or chaotic architecture in serverless teams. In fact, they unlock a middle way that is calmer, more collaborative, and more effective! It’s agile architecture!

As much as management wanted to benefit from Agile, they didn’t want to give up control. They could not give up micromanaging. It was more important for them to be in control than it was for the company to be successful. (Someone on extremeprogramming@groups.io)

I stopped believing in team self-organization long ago. […] There are amazing individuals who can do it, and I worked with them. Those usually make up 5-10% of the team. (Someone on extremeprogramming@groups.io)

I needed to go out on medical leave for a while, and when I came back, every single practice I had introduced got rolled back, with expected results. (Someone on extremeprogramming@groups.io)

Guess what? These challenges and workshops are not restricted to serverless contexts. So most teams will find agile architecture helpful.

As coaches, our job is not to facilitate these workshops (despite what we are often asked 😕). Our job is to make these workshops a habit in the teams! So how do we coach teams to run these workshops regularly by themselves?

Wouldn’t it be great if you knew how to coach teams to do transparent and collective architecture?

How to teach Event Storming

Big-Picture Event Storming

Big-Picture Event Storming is a whole-team workshop whose purpose is to visualize everything! It’s about sticking all the domain events of the system on a giant design board. It’s Domain-Driven Design in practice! It transfers tremendous knowledge between the domain experts and the developers.

An architecture accelerator

Event Storming can achieve over a few days what would take months with traditional architecture. The idea is not to get a perfect up-front architecture. Instead, it’s to design just enough for everyone to pull in the same direction.

(From 3 Wonderful Workshops That Will Make Your Serverless Architecture Agile)

I can think of 3 learning steps to be able to teach Event Storming to a team:

1. Facilitating Event Storming yourself
2. Injecting Event Storming into your team as a team member
3. Finally, installing Event Storming into the organizations that you are coaching

I already wrote about how to facilitate Event Storming workshops. I also wrote about how to inject Event Storming into your organization.

The third step is particularly tricky because the workshop often lasts for a few days. As a result, people will be afraid to take on the facilitation!

Let’s see how to hand over the facilitation to the team.

Start with Immersion

It’s useless to expect someone else to help with the facilitation during the first Event-Storming. People usually see it as an ‘extraordinary’ event that is not worth learning.

Don’t bother and facilitate the workshop yourself! As often as you can, remind them that they should regularly re-run this workshop themselves.

Use this first taste of Event Storming to spot people who “get it.” Then, after the workshop, try to involve these people in facilitation and agile architecture.

Repeat Shorter Event Storming Workshops

Take the habit of suggesting short Event Storming workshops:

• Flow Event Storming for retrospectives
• Or Design-Level Event Storming to dive into the design of a core part of the code.

These smaller-scale workshops don’t need to involve everyone.

As soon as the team agrees to run another workshop, find someone to help you with facilitation. Take 2 hours with your apprentice facilitators to rehearse a simple scenario.

Continue suggesting regular Event Storming. The next time you run the workshop, handover facilitation completely. Be present as a backup, though. When that works well, you have successfully made Event Storming a habit in the team.

Example Mapping

Example Mapping

The promise of serverless is that the cloud provider will take care of all the plumbing for you. This means that your lambdas should contain almost only domain-oriented code. Example Mapping is a neat activity to clarify the Lambda’s business rules.

Example Mapping only takes 20 minutes, so you can run it very often. For example:

• When starting a new user story.
• Or after a Design-Level Event-Storming, to clarify what happens inside an aggregate.

Example Mapping is a structured conversation between Developers and Domain experts. Other specific profiles (e.g. quality engineer) can also join if need be.

(From 3 Wonderful Workshops That Will Make Your Serverless Architecture Agile)

Here’s a detailed guide about how to inject Example-Mapping into a team. The practice is simple, so people should be able to adopt it quickly.

Picture from Cucumber blog

Some teams will find Example Mapping is overkill for their context. So don’t hesitate to simplify it to accommodate the team’s constraints. For example, replace Gherkin with literate programming tests.

Make these workshops a habit!

Don’t wait!

Are you involved with building a serverless system? Whether you are just starting or already deep in, you should run a Big-Picture Event Storming! It’s a starting point that will lead you to Design-Level Event Storming and Example Mapping. These workshops will result in:

• Alignment between everyone.
• Just-enough architecture to keep your system healthy and to avoid centralized decision-making.

(From 3 Wonderful Workshops That Will Make Your Serverless Architecture Agile)

Is a team you are coaching leaning towards command-and-control or chaotic architecture? Suggest Event Storming or Example Mapping to do more agile architecture! Remember the 3 steps to make these workshops a team habit:

1. Start with immersion
2. Spot early adopters and potential facilitators
3. Involve them more and more in regular sessions

What do you think? What are your tips for handing over the facilitation to coachees? I’d love to read from you in the comments.

Other articles that might interest you:

• Organization Refactoring: Event Storming and DDD injection
• # How to coach developers to get a chat with their product experts
• A detailed facilitation guide about Big Picture Event Storming that start with Misadventures with Big Design Up Front
• Why should we use Design Level Event Storming for DDD? A detailed facilitation guide about Design-Level Event Storming
• Preview of The 1-hour Event Storming book Matthieu Tournemire and I are currently writing
• If you are interested in more workshops, here are 5 Whole-Team Workshops To Increase Developers’ Role In Sprint Planning
• If you are starting on a serverless team, read 3 Things You Need to Master to Get Your Team Ready to Work With Serverless