What is this #agileforteams thing about?

Hi, My name is Matt Kocaj. I’m a dev, team lead, tech lead, hardware hacker, dad, husband and I suck at gardening. I like to fly drones, launch model rockets and write clean code. I’m also furiously passionate about the craft of software development and helping teams get the most from the precious ninja skills and knowledge they have. Like you, I hate building things no one uses so I want to show you some of the things I’ve learnt over the years building products and delivering projects from different gigs. I’ve been a full-time team player, a contract dev, consulting team lead and various other team roles. Hopefully I can impart some valuable lessons to you so that you and your team can be more successful in your efforts.

While I’m passionate about “finding the right thing” to build, #leanstartup, #leanUX (Lean User Experience), validation and testing, etc; this ebook is not about those things specifically. I’d call those “higher order ideals” - something to strive for but, in my experience, are much harder to realise. This ebook, #agileforteams, is about the patterns and practices which will lead you to building and delivering value to your stakeholders effectively and consistently. It’s also about enabling your team to respond quickly to the inevitable change which you will face on a weekly basis. We call this being Agile.

Right about here is where I start making claims in the first person rather the collective “we” which would ordinarily refer to the corpus of agile practising colleagues and friends in the development world. It might sound arrogant, but I want you to separate my ego from this - there is no right way to do Agile. I’m just going to share with you what’s worked for me and the teams I’ve been blessed to work with. I’ve seen enough of the same patterns which survived trial and pain. I’ve also seen many things that perhaps might be called the “common practice” fail time and time again. I’ll share this with you in the hope you can take something from it and be spared some of the time wasting frustration.

Agile by definition is about trying something, and then if it doesn’t work, trying something else. It’s saying to yourself, “The way we work is not set in stone. We can change it when we need to.” Ironically, this is precisely the attitude we should have towards software as well. I want to show you my Agile recipe. This is my flavour if you like. It’s a reliable, composite Scrum/Kanban hybrid of sorts which relies on a heavy dose of pragmatism and simplicity. Nothing about the component parts is particularly unique or special. It’s the collective function that is most interesting.

I will prescribe this recipe to you, knowing that given its past performance, it will work very effectively for your team. I’ll give you all the parts and empower you to reproduce it in your team. But agile is about adapting. So I’ll also be encouraging you, that once your practise is up and running, you tune it over time. This is the heart of Agile - taking a process and making it better.