Not quite 2 months ago, I joined Red Hat as an Engagement Lead in the Open Innovation Labs.
It's the beginning of a new journey. I feel a bit like I'm stepping carefully in to a rowing boat. I'm being mindful, and cautious, so as not to overbalance. I don't want to tip arse over tit into the river. So far, it's been fun, interesting, perplexing, and exciting. At times I've felt utterly joyful, at others, overwhelmed by doubt I could do what I said I'd do.
But here I am, beginning to feel the boat stabilise beneath me. I'm ready to set off.
The opportunity to join the Labs at Red Hat caught my eye because it brings the worlds of Open Source and Agile Development together.
For a long time, I'd felt there's a natural alignment between open source and agile, but was puzzled by the lack of open source content at agile events I attended. I then realised there'd been close to zero agile content at the open source events I'd been going to, or organising.
So I started giving an agile talk at open source events. There are a few variations of the "Turning stories into websites/software" talk around as recordings, and I've blogged about it before. It's mostly been well received. It always prompts great questions from the audience, and has led to conversations which prompted me to continue to learn, explore and evolve my own understanding of the intersection of agile and open source. Although, I will admit to sadly disappointing one developer who attended this talk. He thought it would reveal a magical tool to automate turning a user story into code. SORRY! No.
So how do you transform stories into code? You do it by telling each other stories, and developing shared understanding of what it means. User stories, or Job stories, are not, and should not be meaningless empty tasks to be ticked off a to-do list. They should invite conversation, exploration, and refinement. They should be broken down into components that yes, may then be turned into discrete tasks to implement.
So where does Open Source come into this? For me, the fact there are so many open source solutions in existence, for all sorts of problems means we don't necessarily need to re-invent the wheel from scratch. Perhaps there's something close to what we need already available. Perhaps we can experiment with that. Would using something "not quite right" help us learn more about the stories we're telling? The needs we're fulfilling? Perhaps we could build on the foundation of an existing open source project, instead of creating more software to maintain and care for.
I dunno. I'm free associating a bit here. These are somewhat unformed, forming thoughts I'm mulling over.
What's different about the Red Hat Labs, is the Open Practice Library. This is our upstream community project.
"Agile" is nearly 20 years old now. It's a pretty well established ecosystem of practice, approach and proven delivery. But, like the future, it's not evenly distributed. There are many methods, tools, ceremonies and rituals out there. And lots of organisations are successfully selling their secret sauce versions of "doing" agile.
But of course, there's no secret source at Red Hat. Even our foundation enablement training curriculum, "The DO500" or "DevOps Culture and Practice" is freely, and openly available on Github.
I'm just beginning this journey. I'm excited about where we are headed!
- Log in to post comments