(this article is for a series of posts of which some 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)
Actively Doing Nothing (is actually hard work)
What do Scrum Masters actually do, all day long? This is a hard question as the behavior of a Scrum Master is very contextual. It depends greatly on the maturity of the team, the experience of the Product Owner, and the amount of dysfunction in the organization. I use the “five tools of Scrum Masters” for clarifying what a Scrum Master does, when he does that, and why,
A Scrum Master asks questions.
A Scrum Master educates.
A Scrum Master facilitates.
A Scrum Master actively does nothing.
A Scrum Master interrupts (in exceptional cases).
These tools require little clarification, except probably the tool I probably use most: actively doing nothing.
What is actively doing nothing?
Actively doing nothing means that when you observe non-optimal dynamics or plainly wrong behavior within your team or organization, you chose to not do anything at that moment.
A way to clarify actively doing nothing is to contrast it to its opposite: passively doing nothing. Passively doing nothing means you do nothing and you don’t care. However, actively doing nothing means you care, you carefully observe what is happening, and decide… to do nothing.
For example, you notice two people from two different teams are having a minor conflict about which team ought to do what. You observe and listen carefully, ask yourself whether this will cause permanent team damage, and if not, … you chose to do nothing.
Why would you do that!?
By actively doing nothing, you actually do something. You create the space for the team to take responsibility for the situation they are in. By doing something, anything, you are taking the responsibility away from them, and you prevent the team from solving that problem, you prevent the team from growing as a team. Therefore, as Scrum Master, I often observe the situation, think about the team and organizational dynamics, and consider whether not doing anything would cause harm. In most cases it doesn’t. If it doesn’t cause harm then often there is an opportunity for team self-learning and growth. Thus I force myself to not do anything other than to actively continue my observation.
Actively doing nothing might be followed up with actively doing something. For example, ask questions to help the team reflect to solidify the learnings they have from resolving that situation. Or, ask questions to help the team to reflect on what they could have done differently so that next time they might be able to resolve the situation. Asking questions is often followed up with two of the other Scrum Master tools, (1) facilitation when questions lead to interesting discussions and potentially decisions, and (2) education when the questions lead to a learning moment.
Actively doing nothing is hard!
Yes, doing nothing is hard and this often comes as a surprise. Why would doing nothing be hard? Because, as a good Scrum Master, you care about your team and you want to help them. You want to resolve the pain they are in by jumping in. However, a good Scrum Master realizes that this will not benefit them in the long run. Building a team means you need to create the space for the team to resolve issues themselves, learn from it, and grow.
A potential problem with actively doing nothing is that it will look like you are doing nothing, and not adding any value. Many of the teams I was a Scrum Master of joked that I don’t do anything. They noticed the team worked better when I was there, but they often couldn’t see why. Indeed, it seemed like I was… actively doing nothing.
Go out and become a better Scrum Master by actively doing nothing.
(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 [1] 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 [2]. 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.
RSS feed