A couple of the teams I’m coaching had new people join them recently, and I was asked to be part of their onboarding. There is well-organised content covering the company and the technical aspects of the teams’ work, but what should I cover as their coach? I could explain Agile and Scrum principles, values and practices, but would that help the new team members understand what’s expected of them?
Instead, I paired with one of the experienced team members and we put together a “cheat sheet” with links to some key resources, e.g. where to find the group’s product roadmap. We covered how but also why the teams do things, for example, “how do teams know that they’re building the right thing?” – we also need to understand why it is important to get feedback on what’s being built, and why shorter feedback loops are preferable.
Given the new team members are being bombarded with lots of new information we wanted to give them an overview and some examples, but also some pointers so they can remind themselves and discover more … and the best way to learn how their team works is to ask their team! As their coach, I’m always happy to answer questions and discuss other ways of doing things, but I’m especially happy when teams learn from each other and run experiments to find improvements; I’m hopeful that having the new team members question their teammates will lead to them considering alternative approaches.
As part of the warm-up for a retrospective this week we were asked to share an article of clothing which represented the previous sprint. I picked a photo of a jumble sale because I felt we had been trying to find the value in a pile of possibilities – there are many things we could do, but which is the “best”? At a jumble sale, you really shouldn’t try something on then put it back and repeat until you find the thing you want; however, we have the benefit of being able to conduct small experiments to see if we’re doing the right thing.
By taking a small step and inspecting the outcome we can decide whether to continue going in that direction, make a small tweak based on what we’ve learned, or maybe go back and try something different.
To avoid any cognitive bias we should be clear beforehand what criteria we will use to analyse the outcomes; stating those criteria also helps identify any metrics we should collect.
For me, this is the heart of agility – short feedback loops that enable us to learn and react. That reaction helps us deliver what our customers need, and stop working on something as soon as it stops providing value.
I was watching Henrik Kniberg’s keynote at AgileByExample 2016 and I liked his T-shirt (as well as his speech, of course)
It sounds like 4 Simple Steps, but clearly it’s not simple or everyone would follow them. The challenge is to find out what’s preventing some or all of these – how is the system holding us back? Is there value in doing some, or is it “all or nothing”?
Of course, the answer is it depends 🙂 It starts with having conversations and helping people see the challenges, or at least listening to whether they even see the challenges. There is no “right” answer but maybe there are some answers which are less than ideal.
Chatting with a friend about domain names reminded me that my work-related blog (i.e. this one) was still using a domain that’s named for something I’ve not done in years (project management) so I spent a few hours last night moving it over to a more appropriate domain (https://TorontoAgileCoach.ca). I’ve had that domain for a few years and finally got round to using it!
I’ve tested the basics but please leave a comment or email me (paul@ my new domain) if you spot any problems.