(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.
This post is the second in a series related to product management and product teams. Like the previous post, this one is partly influenced by Marty Cagan’s article on “Product Teams” vs “Feature Teams”. Marty seems to see the role of Product Manager different than we do, but the difference is probably more about the team than about the Product Manager. That said, this post is especially influenced by the frequent recurring question, “Should a Product Manager be on the Team?”
Being on the Team in LeSS
First, let us clarify that a little bit by exploring what “part of the Team” means in LeSS.
The Team has a shared responsibility for the result of a Sprint. A shared responsibility means that, even though people on the team probably have a primary specialization and a preferred focus area (which may not be the same, because of learning), all of the members of the team are responsible for all the work that the team does. In practice, this results in vague boundaries between the individual team members primary specialization, and in some teams not even a meaningful distinction.
A Team in LeSS (and Scrum) is also self-managing. What’s the implication of that on a team taking a shared responsibility? Key point: the team will need to have (1) a clear shared goal, (2) at the same time. We want to stress the temporal aspect here as it is rarely discussed but really important! When a new self-managing team is formed in which previously the team members were used to traditional siloed single-function roles, then if they continue that pattern, the team will struggle with finding ways to parallelize their work. The first and easiest questions is, how can we test before the implementation is done? Then, the same question needs to be answered related to the other roles that used to work in a sequential lifecycle with handoff, “How can we do the UI design at the same time as the implementation?”, “How can we do the analysis at the same time as the implementation”.
The fundamental problem that self-managing teams with shared responsibility have to solve is: How can we together in parallel work on activities that were previously considered sequential?
What would it mean if the Product Manager were part of the team?
When a Product Manager is part of the team, it will mean that the Product Management responsibilities are a shared responsibility within the team. However, one problem to solve here is that a significant amount of Product Management activities usually do not – or even can’t – happen at the same time as the activities of the rest of the Team for the selected work in the Sprint. This is mostly because of the delayed feedback of some of these activities. For example, if a Product Manager is out observing users or talking with them, then this activity is usually not at the same time and for the same goal as what the team is working on right now.
Just to be clear, we are not saying that it’s good that Product Managers don’t work on the same goals at the same time as the Team, we are simply observing that this is often so, and that it’s hard to change that in the context of the customers they work with and the organization they work in.
Considering this, we have seen two common alternatives of Product Management working with the team:
Product Manager as part of the team
This means the whole team takes on Product Management responsibilities (not just the person with Product Management preference). The team together discusses how to get closer to customers, understand them better, emphasize better, and discover potential new outcomes to achieve or new features to create.
It is likely to happen that the Product Management activities do not directly relate directly to the other work selected in the Sprint. In that case, the team needs to cope with the temporal differences, the work selected in the Sprint and the Product Management responsibilities related to understanding the customer, without creating separate roles within the team. For example, the entire team gets together at the beginning of the Sprint (Sprint Planning 2) to understand the Product Management activities and decides how they together are going to work on these.
Note that there is a similarity and overlap between Product Management activities and Product Backlog Refinement. Product Backlog Refinement is similar look-ahead work. A difference is that it is often possible to do Product Backlog Refinement work with the entire team together while it might not be feasible to always send the entire team to the customer (though maybe that’s not a bad idea…)
Product Manager who works with a team
Although in LeSS we love the Product Manager – and hence Product Management responsibility – to be part of the team, in practice we often see a Product Manager working with teams. In this case, the Product Manager focuses on Product Management activities (such as competitor and market analysis, and much more) and helps the teams to understand the market, customer, and problems to solve. Sometimes a Product Manager might work very close with one or several teams for a long time when the team works with customers or features that they know most about. However, in that case the Product Management responsibilities are not (yet) fully shared within the team.
In some cases, this is a first step to eventually moving the Product Management responsibilities into the team. In other cases, that won’t happen because (1) the focus of the team changes whereas the focus of the Product Management might not (e.g. in case the Product Manager is focused on a particular customer or customer segment), or (2) the Product Manager’s responsibility is intrinsically hard to share in the team, which might be the case when there’s lots of travel and customer relationships that needs to be maintained.
Conclusion
So, should the Product Manager be a part of the team? Which also means, should Product Management be a shared responsibility in the team? If you can do that, great! Alternatively, Product Managers can work with the team to help them understand the customers better.
On the Product Owner Role
Final note: We are talking about Product Management here and not the role of Product Owner. In LeSS, the Product Owner focuses on overall Product vision, prioritization, and investment decisions. In product companies, the Product Owner tends to be one senior person from a Product Management group, but not all Product Managers will be Product Owners.
RSS feed