This post is yet another take on how we should be creating software together. I’m now working on a book named “Coding Together” that will be reviewing all the challenges of collaborative software delivery and the ways of overcoming them for maximum creativity and efficiency. As I’m gathering materials – my understanding not only deepens but shifts – complex systems viewed holistically definitely cannot be analyzed as a sum of their parts.
Two years ago I gave a few talks and wrote about the importance of enabling self-service principle in a smart and secure way for smooth and effective value delivery in software engineering organisations. I still hold a strong belief in self-service builds, tests, deployments and infrastructure provisioning. All these can greatly enhance the rate of innovation and the quality of produced software.
If done correctly, that is…
But it can be quite disastrous when this self-service concept implementation isn’t designed and delivered with due attention. What’s more annoying and demotivating than being told that you can build, test and deploy with a click of a button but ending up with a failed process and a bunch of cryptic error messages?!
And then opening a ticket to the suporting team and waiting for hours because “they are busy developing the new self-service infrastructure”…
I’ve seen this happening too often in real life and that led me to understand that self-service is really worth nothing when the other most important ingredient is missing. And that is – human service consciousness. Not serving oneself but serving others should be the focus.
That’s easy to say, but how do you practically implement this? How should we structure our software development organization around service consciousness and how is this any different than what we used to have before continuious delivery and automation became common knowledge?
Microservice architectures are becoming the de-facto standard for building modern highly scalable and reliable software systems. In line with Conway’s law – small service teams based on consumer-driven contracts should become the foundation of a highly scalable, flexible and agile IT organisation. And it’s really less about the team size but more about being focused on serving the members of other teams – the consumers of your team’s api, the users of your self-service automation, the implementers of your feature requests or the developers you’re assigning bugs to. It’s about building a decentralized Team of Teams where each unit takes pride in the level of service it provides and not in its special status in organisational hierarchy.
Advanced communication is what allows us humans to collaborate on massive scale. But communication can also ruin collaboration if what we transmit is a negative, elitist or egocentric attitude.
As Sabine Bendixen rightfully writes – a highly effective agile organization starts with effective communication.
Communication is always the first thing we at Otomato look at when performing a software delivery assessment for our clients. How are changes getting communicated? How is knowledge managed within the organization? How are decisions made? How do the members of different teams see themselves and their role in the value delivery stream?
Whenever there’s hostility, resentment and lack of motivation or transparency – we know we struck a bottleneck. And this is a great place to start. Start building trust and visibility, reviewing and streamlining the processes. But most important – start building collaboration around providing important services among teams. Around treating all the internal interactions as interactions with customers in which customers invariably come first and their experience is the utmost measure of our performance.
I like to call this ‘service-oriented collaboration’ and that’s the only type of collaboration that’s truly sustainable, adaptable and robust. This is the kind of collaboration that will allow your business to quickly change course when needed and keep engineers creative and motivated. And once you have this – self-service infrastructure will take you to the moon!
Now did you notice how this whole post didn’t mention DevOps even once?
Watch our follow-up posts to learn why.
Happy delivering!