My Professional Summary

I have over 20 years of experience and a unique balance of a technical background coupled with the ability to manage, de-risk, and make the impossible solution possible. I have participated in every stage of the software development lifecycle within small to medium sized businesses. My focus is to produce well crafted, working applications with an eye on the end users experience while staying on budget and hitting timelines.

.. While all that is true, we all say that..

⚠️ Before we begin, I know not all places can or should work the same way - I'm not saying that. I'm simply sharing the environments where I thrived the most. Nothing more.

Let’s Cut to the Chase

I like being on smaller teams, teams that “punch above their weight”. Being able to achieve more with less means that we get to reach out to stakeholders, other teams, and even end users. I absolutely love working as closely as possible with designers and all the “non-coders” because when we break those silos down, real work gets done faster and with higher quality.

The best way I’ve ever worked was with a “small mighty team” consisting of 2 or 3 developers, a designer, and the person wanting the product/feature/change. I guess most would call this the Product Owner, but I literally mean the person writing the checks who wants this work done. (I know that can’t always be the case, but it was for the two instances I’ve worked this way.) It’s the most productive, efficient, and effective way I’ve ever worked.

I like to get together for a day or two, discuss the next objective, create a User Story Map, and then we can get to work. We can repeat this process in a month or two when we close in on finishing our objective. We’re not doing any deep technical inspection here. The main points of doing this is to:

• Establish a “north star” and get everyone on the same page.
• Break down what the user needs to accomplish into slices that can be delivered in small incremental steps.
• Try to assess if any particular piece is risky, has an integration, etc. Anything beyond “just another ticket” kinda work. Do these first. If you can’t, you can’t do the project by definition and you save money by figuring that out before doing anything else.

We didn’t estimate anything; we didn’t guess on anything. We didn’t have planning or grooming meetings to distract us by taking our attention off of the work we were actually doing right now. Why load everything in this sprint and next sprint into our heads when we’re not ready to talk about them yet? Doing that just kills our attention.

I suppose the way we’d slice out work is a form of guessing since we tried to have each card doable in about a day or two. Whenever things took longer than that, we knew we had to reexamine the work and ask: Do we need to slice this further? Do we need to pull someone else in? Do we need more questions answered?

We didn’t even use sprints because they didn’t give any value with the way we worked. Since we already mapped out what needed done, we knew what was design heavy, what the risky parts were, where the integrations were, where we needed more info from other teams, etc. At this point, the PO, designer, and devs would talk and put a few cards into “Up Next”. No hour long meeting, literally it’d take like 5 minutes during any random standup. The PO would say “I want to focus on X” and the designer and devs would either say “Cool” or “We need to do this other thing first because of Y”. We’d adjust. We’d learn. We’d adapt.

Everything was like this. We trusted the PO to know the direction and they trusted that we knew what we were doing. The “PO” (again, the one writing the checks ) didn’t treat us like a line cook who just did as told. They treated us like a chef, as experienced professionals who knew how to make software better than they did. Not sprinting, not talking about every card that we were going to work on in the next two weeks, not going over everything in detail until it was time enabled us to focus. This is vital to writing great software. This is something I’ve found severely lacking on most teams.

Day to day, we put everything on a quasi-kanban board. We worked in small steps, communicating with the PO every day at standup to show progress and ask/answer questions. This allowed us to make necessary adjustments to ensure we were on the right track. It also enabled us to have the harder conversations when it wasn’t possible and we could present options.

Some teams had regular retros, but mine did not. Whenever we felt the need to discuss something, we’d talk about it right then (or whenever the person was ready to talk). Why wait up to 2 weeks to talk about something? If someone wasn’t comfortable bringing it up, they’d talk to someone they trusted and they would. Either way, we’d get it resolved, learn/adapt, and move on better than before.

We had WIP limits on our work and we would actively obey them. The flow of work slows down when there are too many things going on. Errors are introduced. Don’t start on new work! Finish what is already started! Help others first! Remove friction and blockers! Improve things you know need improved! Act like a Team Member and not a siloed off Individual Contributor!

We also pair programmed and used TDD every day, all day long. When you don’t know how to use a tool, it slows you down. When you know how to use them, they speed you up. Tests and TDD sped us up.

Of course we did Continuous Integration. I don’t mean the “CI/CD build tool” like how most people use that term today, even though we did have a build tool in place. I mean actual, for real, continuously integrating our code. The thing you do, not a tool you buy. We’d push to the main branch. We paired on the work, we reviewed it while we designed, talked, wrote, refactored, and committed the code together. And if it was a bigger and riskier bit of code, it’d be behind a feature flag or abstracted away so that we could selectively turn it on and off. This allowed us to get real world feedback as soon as possible which would then inform us for the next round of commits we’d do. All within the same day, sometimes multiple times a day.

I have seen first hand what this work style produces.

It’s very productive and efficient.

Dare I say even moreso than the big “Agile Frameworks”..