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
teamgroup 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?
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.
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 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)
Not only will investing in collaboration make you a better coach. Improving your communication and collaboration skills also makes you happier!
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.”
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!
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)
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.
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.
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!)
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 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:
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.
🤣 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:
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.
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…
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:
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 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.
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.
(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!
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 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.
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.
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 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!
An interesting aspect of communication techniques is that we can innovate by combining them. For example:
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!
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:
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?
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.
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!
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.
The workshop is a string of Liberating Structures:
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.
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!
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!
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:
In your future workshops, add high return-on-investment structures such as:
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.
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:
Wouldn’t it be great if we had ways to connect with developers without mentioning Agile or Scrum?
What can we do?
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 are not a rigid recipe! Instead, baby Steps are about continuous learning, adaptation, and delivery at a steady pace.
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!
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!
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:
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:
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:
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:
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:
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:
Two sessions are usually enough, but your mileage may vary.
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:
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.
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:
The goal is not to have a formal design document. But you must have something visual that creates shared understanding and triggers conversations.
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:
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.
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.
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.
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.
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:
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.
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.
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:
Wait to try to map these features to the Quality View. The team will do that just after.
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:
Some modules might get plenty of diamonds!
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.
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.
Feel free to run a follow-up workshop focusing on different aspects. For example:
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:
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.”
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.
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.
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.
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:
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!
If you had not yet understood 😉: Local actions are where you should invest your time and energy!
The prominent local actions are about helping team members with their day-to-day issues. For example:
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 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:
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.
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!
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!
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.
“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:
The complete workshop lasts between one and a half and 2 hours.
Participants can try the 6 slow working practices during the workshop. I’ve split them into 3 categories: coding, communication, and mobbing.
We can use these whenever we are programming solo, in a pair, or in a mob.
Take the time to focus only on the present task:
Take the time to practice egoless programming and baby-steps programming with TCR:
Take the time to observe what happens inside us:
ROTI | Did | Learnt | Puzzles | Feelings | Need | Decision |
---|---|---|---|---|---|---|
… |
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.
Take the time to offer non-violent feedback to your colleagues:
Finally, here are two practices specifically suited to mobbing or pair programming.
Take the time to be aware of your feelings and thoughts when driving:
[Mindfulness For Programmers. 3 simple exercises to be more present… | by Julia Di Russo | Towards Data Science](https://towardsdatascience.com/mindfulness-for-programmers-da6f92147b8f) |
Take the time to practice egoless programming while navigating in the mob:
Here is a variant:
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:
Whatever you try, I would love to read your feedback!
Here are other articles that might interest you:
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:
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:
With time, these “testing problems” increase the risk of abandoning testing altogether!
Wouldn’t it be great if engineers regularly aligned on testing terms?
Phoenix tackled testing issues with an all-in workshop to discuss the testing strategy. During the workshop, all team members were able to:
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!
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.
Before the session, we sent homework to the team members. We shared links like:
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:
The idea is to learn how the different kinds of tests compare.
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.
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:
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!
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!
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:
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.
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:
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
Did you notice any miscommunication around testing between team members?
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:
]]>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!
How you introduce the sessions greatly impacts the participants’ engagement.
TCR sounds like a ‘drill’. The word ‘drill’ has an ‘improvement’ connotation and people understand that:
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.
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!
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!
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.
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!
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.
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:
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:
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.
Here is my advice to get people engaged in TCR practice sessions:
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:
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!
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:
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.
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 almost a ‘gamified’ way to go through code katas!
There’s a poker flavor of ‘betting’ on your change.
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 😀
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 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.
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:
As coaches, we have to point out every time they start on such a difficult path, but:
Things are different in a TCR practice session:
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!
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.
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!
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:
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:
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?
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:
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.
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.
Take the habit of suggesting short Event Storming workshops:
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
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.
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:
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: