Buzzwords are all around in today’s world and that is no exception in Scriptura Engage’s technology department. Agile, Scrum, Lean, DevOps, Cloud… just to name a few.
The omnipresence of these terms doesn’t bother me; the pressure to adopting them does, however.
To be clear: it’s not that I am a non-believer. On the contrary! I really think that an agile development approach, for instance, lets your team grow and improves the overall quality of your product. And I do believe that involving developers in the operational part of your business will help to get better insights in the product’s maintainability shortcomings, just to name one reason.
But I do not believe in fairy tales. Too often, all these hypes are introduced by top-management who expect these adjustments will magically solve all the company’s current problems. In my eyes, you can’t force a team to become agile or DevOps-oriented. You have to let them grow into this. And this is how we contributed to it.
Since a few months, we have writing walls at Scriptura Engage. And that is just a marvellous facilitation to improve the involvement of a technical team. When we sit together to discuss how we are going to implement a new feature, it’s a much more dynamic conversation now. We did have whiteboards of course, but it just isn’t the same.
It’s always tricky to try to explain human behavior, but I think one of the reasons why writing walls do work better is because of the space. The additional physical writing area allows team members to start explaining a completely new approach without the need to erase the previous one. Somehow this feels much safer as it is less intrusive; you suggest an equipotent alternative, instead of a better one. And having both (or more) ideas visually represented at the same time leads to better discussions in my experience.
So how does this link to my introduction? Well, many of today’s buzzwords, especially those impacting behavior, only work when the team itself is fully committed. And according to my experience, a team will only commit itself once it feels it’s involved in the (technical) decision-making process. And as an Agile Coach, ScrumMaster, Facilitator (hello to the buzz-words again), that’s one thing you should really focus on.
So create some room, give some space and let your developers pick their markers…