Articles for category: Drive

Breaking Code

Code is meant to be broken, reiterated over, broken again and again and again until it cannot function anymore. That is what code is meant to do. It works, it changes, it breaks, it gets fixed, it works again. Welcome to coding! Let the everlasting Frustration and Joy begin.

Jumping into a New Community

Jumping into a new community is never easy – you don’t know anyone, but you might have a connective interest between you that can be the establishing point for something new. But you have to go through that awkward phase of figuring things out. And that’s never fun because the first thought that runs through your mind – “Here we go again, starting all over again.” – figuring things out for the first time – again. Oddly enough, that awkwardness kicks off the community, gets it going, and establishes those bonds of “Hey, you don’t know what you’re doing either?”

February 28, 2024

Greg Thomas

One Backlog to Rule Them All

No matter how many teams, no matter how many boards at some point you are going to need one, masterful backlog to rule them all. You’ll need a roll-up, THE roll-up that will signify what everyone in your team is doing. This view isn’t for everyone and it won’t be broken out by sprints (they might be listed and each group might have its own) but invariably they will be listed by resource. And that’s the role of the “Big Bad Backlog for All” – what is everyone on my team doing across their project so I can make sure

February 27, 2024

Greg Thomas

Breaking the Ice in Your Next Meeting

I dread being in a meeting with a ton of people I’ve never met because I know it’s coming, the statement that is going to make everyone groan in unison. “Why don’t we go around the room and introduce ourselves!” Truth be told, I’ve never been great at introducing myself, I don’t know why – I mumble some words, hear someone else’s great intro, and then go – “wow that’s amazing” – but I’m still left going – I have no idea why you’re here. If you’re in a hierarchical culture, that intro might turn into a game of “who

February 24, 2024

Greg Thomas

The Best Durations for Sprints

I’ve done 1 week to 6 week sprints (yes at 6 weeks we called it a sprint) – if you’re not sure what fits best for you, here’s some guidance. 1 Week – It’s all bugs, it’s all known quantities, you have minimal code and your deployment model is code, commit, deploy.  QA happens when you ship to Production, teams of 1 – 2 developers.  The Theme is “MVP”. 2 Weeks – User Stories are in the fray now, the team is growing, and there are other people in the mix (product management, QA) but the goal is continued output.