Articles for category: Delivery

Separating Code from Ownership

We all hate when our code breaks. You put all this time and energy into creating the most beautiful piece of software known to mankind and then it blows up on the launchpad. It stings.  Even after so many years of programming, it stings. But code is code and it will blow up (I believe this to be its second purpose in life). Owning the problem when this happens is good, blaming yourself and hiding it, is not so good. Own the problem, not the code, conditions change, if you gave it your best effort, great, learn, fix, move forward.

April 11, 2022

Greg Thomas

If it Blows up, it’s Broken

There is no talking your way out of it. If it blows up, it’s broken, there is no if, then, that – it blew up, it broke and now it’s time to move on. Admit it’s broken, put together the plan to fix it, and make it happen. Don’t waste time arguing if it’s broken, get past that and fix it.

What’s in our Head

The Hidden List is what we keep at the back of our minds, keep track of, and keep adding to as we progress thought-out the day. As a Developer, the list is going to be small, but as a Leader, that list is going to be very long.  Therefore it’s imperative that you get it out, write it down, and get it into the system of record. By not getting it out of your head, all you are doing is holding your team back from what they truly need to focus on.

April 6, 2022

Greg Thomas

Let the Data Drive Your Sprints

If your team is not inputting data into the work they are doing, then all you are tracking is sticky notes and their movement. Which is fine. But if it’s data you’re after, you need to ensure your team is updating as expected so you have the information to drive what gets pushed out and what can be pulled in. Again, you don’t have to use the data, but make it clear then, that it’s not the data you are after (i.e., perhaps its process or culture change which is valid goals as well).

April 5, 2022

Greg Thomas

Oh, Remember That?

We rarely do. Or rather, we rarely all do remember the same thing, in the same way, with the same impact as when it first happened. Our memories drift and unless you are the one closest to the issue, they fade faster than most.  That’s why it’s scary when you’re in a meeting discussing a bug or an issue that comes up and someone says – “oh remember that?  We had this happen before, remember the impact from it?  Oh yeah we did this and this workaround and now here we are… going through it again.” Whenever you hear someone