what stinkin' process? No images? Click here I'm going to need a processSpecial question time: If I'm looking for good, less known, Elixir bloggers that deserve more attention, who should I reach out to in your eyes? Let me know at lars@underjord.io Another livestream will happen on the YouTube channel today. This one at 14.30 CEST. I think we'll be fighting with some Ecto nearly-internals to generate appropriate SQL across databases. This might be a gnarly one. Part of the CMS project efforts. More video posts should be up. All at underjord.io. BEAM Radio published an episode on Elixir Deployment with guest Hubert Łępicki. I was unfortunately out for this one (during vacation) but should be a good listen. Can a little process go a long wayWild things are happening on the business side of Underjord right now where it looks very likely that I will be leading a small team of intrepid developers in some longer-term product development. This leads to many questions about how we should be working, as a team. But you might, to support my argument, ask "you've done super well on your own, why not just do that but with more people?" to which I would reply "yeah, that's not necessarily .. reproducible or sustainable". A good process is something you can lean on a bit, it ought to keep you working in the right direction, provide some structure and some common perspective on how a team does what it is supposed to. The way I run myself and my business doesn't necessarily translate into a team of people doing their job. My process is weird, idiosyncratic, personal and significantly driven and motivated by performance pressures. I pitch myself to clients and then want to live up to what we agreed on. The way I run myself and my business is not necessarily sustainable as a team practice. I've tried to transfer some of my methods to other people. I'm not sure it has typically worked. I'm also keenly aware that my personal/individual way of working has mostly improved with experience and practice. Providing a bit of structure and guidance to a team is a good way of taking some of the pressure off and providing clarity. So how are we going to do it? The client is partial to Scrum so that will be the foundation. I don't subscribe to any branded method so it doesn't matter to me. What I think is useful is laying out how you are going to work, trying that, changing the parts that don't work and making sure it continues to serve the team and the end goals. And the client is aligned with that. No concerns there. I find it important that the process becomes clear to the team and becomes something you can rely on in moments when you aren't really feeling it. Also quite important to me that the process doesn't feel like a drag on actually doing the work. I like minimal process, some people want a lot more and I think this team will have a fairly light process knowing the people involved. But it is something I've not thought about in a bit. What process do I believe in? How agile do I want it to be? What actual practices/activities do I think are actually beneficial? And in the end I just come back to the human side of it. I think stand-ups and similar recurring meetings are useful because regular communication reduces misunderstandings, reinforces connections and lets the humans connect. Clearly, if you do meetings poorly they can pretty much invert those advantages so be careful. I think organizing the work in sprints, releases or other blocks is useful to bound the problem and give it shape. The details of any particular method as written is something I've grown deeply disinterested in. I'm still pretty interested in how actual specific teams do their thing. Because there are special pieces to it. What did they strip out, what is working well, what is still a trouble spot? As always, the theory is less interesting to me than what we actually do in practice. That's where the building happens. I'm very excited to be doing this team thing. To a large extent because of the people involved. Also because I enjoy product work and this will be entirely that. And from a few years of mostly managing myself I'll have a whole team to answer to. Which is deeply uncomfortable and also awesome. What are the best practices you know for software teams? Are there methods you believe in whole or that you'd pick some gems out of? Let me have it at lars@underjord.io or on Twitter where I'm @lawik. Thank you for reading, I appreciate your attention. - Lars Wikman |