(this article is the first in a series of posts. Some of these might be published in the upcoming book “97 Things every Scrum practitioner should know” in the O’Reilly series, which will be edited by Gunther Verheyen)
The Scrum Master as a Technical Coach
The best Scrum Masters that I’ve encountered spend part of their time as a technical coach for their team. Unfortunately, it seems that most Scrum Masters do not do this. To me, this seems like a lost opportunity since spending effort on technical coaching for your team can help them enormously, and it will help you with your other Scrum Master responsibilities.
It often comes as a surprise when I suggest that a Scrum Master could (or even should) do technical coaching. It shouldn’t! Technical coaching isn’t explicit in the Scrum Guide  as it is written to be applicable to both technical and non-technical work. Therefore, technical coaching is only mentioned as “Helping the Development Team to create high-value products.’’ That is unfortunate. However, some other great Scrum resources do refer to technical coaching explicitly, such as Michael James’ Scrum Master Checklist . In the checklist, one of the four focus areas of a Scrum Master is “How are our engineering practices doing?”
Scrum Masters can (should) do technical coaching and that shouldn’t come as a surprise.
Why should a Scrum Master doing technical coaching?
Regular technical coaching has three important benefits:
It improves the team’s development practices.
It lets you experience the real problems that the team faces. This helps you in deciding where to focus the team, the Product Owner and organizational improvement work.
It keeps your technical skills up-to-date.
What kind of activities can a Scrum Master do?
Some examples from my own work as a Scrum Master are:
The most common activity: pair up with team members. Just announce during the daily that today you would like be pairing.
Setup your computer so that you can build and run tests.
Refactor some tests and code and have a sharing session with your team.
Create some unit or acceptance tests.
Organize a learning session about technical agile development practices. Use your team’s code as examples.
What to avoid?
The biggest risk is to become too involved in design decisions, and the team starts depending on your contributions. You can avoid this by:
Never plan your development time in the Sprint.
Never pick up a task from the Sprint Backlog.
Avoid making decisions. When asked for your opinion, provide many alternatives and keep reminding the team that “it is your decision.”
How to start?
It shouldn’t be hard to add technical coaching to your work as a Scrum Master when you have development experience. It just requires you to prioritize and plan for it. One option is to plan one or two days a week to focus on this. As the context switching might make it hard, alternatively, you can dedicate a Sprint on technical coaching and try to limit other Scrum Master activities.
If you do not have development experience it will require more effort. It is possible to learn the basics of development and the purpose of agile development practices while being a Scrum Master of a team. You can ask your team for help. Tell them, “I want to improve my development skills, could you help me with that?” Work out a plan together and dedicate time for learning. Spend a lot of time pairing, but avoid asking too many questions as it will slow down your pair and he/she will become annoyed.
Good luck with the technical coaching as Scrum Masters and I hope you will find it as rewarding as me.
So I am a beginner in using agile frameworks and came to Munich for LeSS Conference for one purpose only – to find out how to quickly and effectively and painlessly make use of the framework in my own context. Simple, right?
I knew there would be a lot of inspiration – and there was! Thank you all content givers! I knew there would be many interesting discussions about different implementations in details or specific problems on the way or discovering the mindset it is great to manifest – and there were! (Some discussions/presentations ended up standing because of hot topic) I expected many experienced, positive, I-know-why-I-came people to meet and to stay in touch afterwards and I wasn’t disappointed. Finally, I hoped for great food ;) and it was de-li-cious (though still… less is more).
I also have learned that silent high five actually works for big conference, that (piano) keyboard is not designed for one player only (and pattern „one keyboard – one screen – one developer” is only my heavy bias) and that bully hen was a great team player 6 generations earlier, so promoting good teams as a whole is far better than promoting individuals in the long run.
Did I find answer to my initial question? Yes, quite quickly. There is no shortcut to success. The best thing I can do is to get training(s) and coach guidance. And take it with no guarantee. And then: experiment, fail, learn, experiment, learn, have something almost done, explain, fail, experiment, engage, learn, practice, come back for missed rules and principles, learn, gather data and measure, experiment, learn, do less… and once again.
This was my main learning. And I’m thankful for that. I have one year of learning ahead before the next Conference takes place. And I’m looking forward to having little success in our LeSS adoption. See you next year!
It is with much trepidation and anticipation, that I decided to make the pilgrimage to Munich to attend this year’s LeSS Conference at the Paulaner am Nockherberg that happened between 12th to 13th of September, my very first. I know myself enough that travelling anywhere that wrecks havoc to my bio-clock has typically turned out torturous and eventful for me. However, I am curious as to what to expect and what I can gain attending THE annual LeSS event. There is a lot that I know that will put me into my uncomfortable zone - a brand new place I have yet to visit, a country with a language I do not speak, fresh new faces with people from countries and cultures very different from what I have grown used to in my 40 odd years growing up in Singapore.
We booked an Airbnb place, near-ish from the conference venue. I was warmly received by my Shanghai colleague, Joseph, on the early morning of 9th September, who waited at the train station, which is close to where he stays, and happens to be a short walking distance from where he currently coaches - BMW; Incidentally BMW is presently, undergoing a huge organisational transformation, to adopt LeSS, and find a better approach towards product development for their Autonomous Driving Program.
The next 2 days for me was an eye-opener, especially from the perspective of a developer of the LeSS website. I joined the LeSS trainers meeting. I got to meet LeSS stalwarts such as Jürgen De Smet, Elad Sofer, Cesario Ramos, Ran Nyman, Wolfgang Richter and Craig Larman, which gave me first-hand interactions and feedback directly from whom cared most about the LeSS community and the LeSS website. It was obvious everyone placed a strong emphasis on building up the technical capabilities of developers, that being an important pre-cursor, before even attempting to introduce organisational changes towards LeSS. We will, therefore, be introducing a feature to allow LeSS trainers to add recommended courses and events that shepherd developers towards levelling up their technical foundations on the LeSS website.
I turned up Day 1 of the Conference to the majestic venue of the Paulaner am Nockherberg restaurant and beer garden. It was breathtaking. Huge halls, a cosy beer garden for team events and social activities, which fit well, for the nature of the conference. My colleague, Ivan, was anxious about the potential chaos that might ensue, during Day 1 of the Conference when a large number of people would turn up at registration, encountering registration exceptions, and given his previous experience in 2018 NYC LeSS Conference. It turned out, given sufficient logical signs and directions along the Conference entrance, it quickly proved that self-organisation works. We had zero incidences of registration exceptions, and both Ivan and I ended with nothing to do at the “Registration Exception” handling table.
Bas kicked-off the conference and shared that LeSS Conference 2020 will happen in Amsterdam. In the keynote by Cesario and Nadine that followed, on “LeSS at ING Business Lending”, they shared, how ING moved from their existing Spotify Model in their LeSS Adoption. Teams went through preparations for the transformation, attending CLPs and technical training, while dislocated teams were organised around the business lending product. They used technology to enable mob programming across geographies.
There was a huge bazaar thereafter, that enabled people to quickly get acquainted with one another and within a short 15 minutes or so, teams with at least 5 members with maximum diversity were formed.
One key takeaway, after attending Michael James’ “What Are The Biggest Disadvantages of LeSS?”, is that, there is a wealth of knowledge, to be unearthed, from people in conference participants, that perhaps, has a good fiddle on what is and is not, a good thing to do, if one is to tilt an organisation, inch by inch towards becoming more agile. We learnt a lot, sharing experiences and pains, which each of us in the teams formed in the workshop, that gives us empirical evidence, of what paths, organisations have taken, that moved the needle, either away or towards being more agile.
In Jacek’s talk on “Working with pain in organisational change”, I learnt that it is important to be aware of how the pains experienced by individuals during a large organisational transformation, triggered by the intricate cause and effect between our System 1 Thinking and System 2 Thinking, will, work against the best-intended efforts during a LeSS adoption. By first finding a commonly shared belief with everyone involved as a starting point - gearing teams up with technical practices training in TDD, Continuous Integration, etc, becomes useful and important, in preparing an organisation for the flip, which relies heavily, on being able to practice and execute those technical practices well.
I did an Open Space topic on Kent Beck’s strategy for scaling software development collaboration - Limbo, suggested by my colleague - Terry. There were a lot of discussions and questions surrounding, how the fast small diff commits of TCR proposed in Limbo, would work, where you still had to pay attention to code quality, yet, direct you towards the intended solution for a feature. There was a lot of questions surrounding how the cadence of the commits, might result in chaos with conflicts and whether refactoring, might take a back-seat, given, it may take more time and larger change-sets. I had an extended discussion over lunch with Robert Batůšek from Solar Winds, as he missed my Open Space session while attending Lv Yi’s “Number of Backlogs and Multilearning”. He is excited and eager to experiment to introduce Limbo/TCR in his coding-dojo sessions with his teams in the Czech Republic. He has been organising software craftmanship coding dojos with his teams where he works, in Solar Winds.
In a parallel Open Space topic by Michael James and Aki, they shared, how Odd-e Japan, worked with a robot companion startup. A lot of vibes and interests surrounding the hardware and software integration and sprint cycles. I see a lot of these topics and interest in quite a few other occasions in the last 6 months or so. IoT, 3D printing, and product companies that build more tangible and material products are emerging very quickly recently, that could explain, the explosion of such interests.
In Day 2, Craig talked about Chicken Breeding. A huge takeaway for me was that a lot of problems that we are faced with in organisations today, have been well studied with case studies and opinions around how you might go about tackling them. These are well-studied problem space, with well-formed opinions and knowledge that are there, for the last 3 to 4 decades. A must-read book for me, out of the session, is “Governing the Commons” by Elinor Ostrom.
The talk by Anshul, “Banking on LeSS” struck closest to heart for me. I have spent 6 months in his organisation, helping with the LeSS Adoption, along with my colleagues Terry and Ivan. Bas had spent a year before, getting the organisation ready for the changes to come. Anshul shared, how over the last 1.5 years, the journey taken by his organisation, to adopt LeSS. A lot of training and preparations were done before they made any organisational changes. Teams were sent for CLP training, and technical training (Certified Scrum Developer courses), and working spaces were re-structured, that befits and allowed easy open space collaboration and interactions. Product owners and line managers were coached and they formed a Scrum Masters community, which were initially shunned by the managers. He shared the term NATO - “No Action Talk Only”, which were used by managers to describe the scrum masters community. That brought about many chuckles from the audience.
Reflecting on my 2 days at the conference and 2 days at the LeSS Trainer meeting, I miss the Italian food in Munich ! There is a lot of energy and interest surrounding LeSS and the vibrancy of the communities in Europe is invigorating. I was pleasantly surprised to see fellow Singaporeans, who had flown 12 hours to Munich, to attend the Conference, some as speakers, others as attendees. Good to hear about their expectations and experiences over the last 2 days. I, came across, a couple of interesting individuals - a Physicist who is now a Finance Manager, a Chemist turned Agile Coach, an Electrical Engineer turned team scrum master, etc. Wasps at the beer garden during mealtime and social events were a constant annoyance for me. Those filled Oktoberfest Beer Mug were not good for tiny Singaporean arm and wrist of mine. All in all, meeting people, sharing experiences, sharing what an idea means and what each of us heard, from the conference, was a huge huge gift to offset my to-be yet again, jet-lagged body !
Last week I had a pleasure (and pain :)) of attending Less Conference in Munich. Here are a few words why it is such a great experience and why I would recommend it to anyone working within a team.
Firstly - it was a team-based event. It was my first experience of such a formula. I couldn’t have imagined how it would affect my learning abilities. By the 2 p.m. on the first day, my brain capacity was reaching its limits (hence the pain part :)) and then I’ve learned some more. I don’t know how but the atmosphere made it possible.
The second reflection I had was about the people. Wow. Just Wow. Being a Scrum Master for 3+ years I thought I had at least some things figured out. Well maybe, but being in the presence of practitioners with this amount of experience just knocked my socks off. When I overcame the feeling of being so small in comparison, I took a lot with me. From the calm mentoring from Less Trainers (Craig, Greg, Wolfgang and others) giving me a different perspective on the ideas I was kind of stuck with, to the empathetic connections we all made during workshops and talks regarding our everyday challenges. Also from the great Team, I had the joy to work with - Tremors.
Lastly - I’ve made a few connections in my mind that I think wouldn’t have happened any other way. I can honestly say it was one of my career-changing moments. I got inspired and I feel I have the guidance that I was looking for.
I am very thankful for this experience - unlike any other. It was evolving on many levels. You can not deny the amount of substantial knowledge you could get but for me, it was all about the emotional journey I needed to take.