Courage is the willingness to confront fear; one Scrum value says “The Scrum Team members have the courage to do the right thing, to work on tough problems”. It may not be “running into a burning building” courage, it can still be quite daunting to speak up when you feel yours is the lone voice or when stepping into unfamiliar territory.
For the upcoming hackathon, my fellow coaches and I have decided we’re going to spend a few days trying to better understand the developers’ experience by using some of the same tools and techniques. Why does this take courage? Well, some of us haven’t written code professionally in many years (~20 years in my case) and some of us have never been a developer, so we all have a lot to learn. Fortunately, as a strong team, we know we can rely on each other for support as we learn but it won’t all be “the blind leading the blind” – we have found ourselves a coach 🙂
We have the benefit of it being greenfield development (starting from a blank page rather than on top of legacy code) and the freedom of being our own product owner. It means we can focus on the things we want to experience rather than what we need to build; if we discover our current “product” (a slack bot to support team appreciation) doesn’t give us the learning opportunities that we want, we can chop and change it.
I expect it will be interesting to see many software engineering principles being applied in new ways, for example in my day change control was managed via
vcs; these days it’s
git. The rationale is the same, the operations are the same, but the commands have changed … and why did they decide to use
pull counter-intuitively? 🙂
Just like the teams we coach, I’m sure there are things I’ll need to unlearn before I can learn the new approach.