I’ve written this document because, over the past few years, I have encountered one too many situations with developers not living up to their own expectations.

As a developer myself with a couple of decades of experience under my belt, I’ve seen a lot of examples of how code can go wrong and how painful it can be to fix them when the PM comes along with a new feature request or important bug fix. As a project manager I’ve had to deal with the consequences of those poor coding decisions, spending an inordinate amount of time and social and political capital trying to smooth things over when a client gets upset because we went over time and budget.

I’ve been away from my computer for quite a bit recently, hard at work in the Texas heat (don’t worry, I keep well hydrated and take lots of breaks) fixing a limestone patio. It’s a lot of moving dirt around, lifting and placing large stones, and planning.

Planning. We can never evade it, can we? Whether building a new house, fixing an old patio, or creating the latest revolutionary digital product, planning is always there.

OKRs: Objectives and Key Results.

Oof, how they bother me sometimes. Nothing wrong with them per se, except they sometimes obfuscate what should happen behind just another TLA (Three Letter Acronym), an idea created from the heart of Intel (who I used to work for), as notorious for their overuse of acronyms as the US military is.

I’m wrapping up a not-quite two month software project right now and we’re in the midst of finalizing with stakeholders, doing retrospectives, and digesting all that has happened. During the project I kept copious notes and I can make a few definitive comments:

"Over-communication" is not a thing because things change and there is always a reason to communicate.

What people often get bogged down in is what to communicate and when, for fear of inducing communication fatigue (assuming they have an honest intent to actually communicate).

The key word is communicating.

The Experiences​

• User Experience (UX): Discovering and meeting the needs of the user so that they have an improved, effective, and delightful experience when using software.
• Customer Experience (CX): Improving how a customer engages with a brand, product, or services to engender a sense of loyalty.
• Developer Experience (DX): Creating tools and systems that make developing software applications and features easier, faster, and in a more productive fashion.

All of these *Xs are efforts to improve how humans engage with our modern world. The benefits are real, and the joy of using a system without fretting, stressing, or hitting speed bumps is a worthwhile endeavor in its own right.

Remember, if someone tells you that the chances of something happening are "next to nil" or "almost impossible" or even "highly unlikely," then the chances are still non-zero.

Next to nil isn't zero.

This axiom is clue that something is at risk and you should pay attention to it. It's not statistics that we should worry about it. It's our assumptions.

From: Lex Fridman's John Carmack Interview

It's not the writing of the program initially, it's the whole lifespan of the program.

No software project worth putting into production is ever truly static. Even a hypothetically bug-free application upon initial release has to change as it gets used in the real world. Users provide feedback so the UX has to change; the product owner or client of the application wants to tweak something; a new platform comes out for it to be deployed to; the app is so popular that it needs to be scaled up — any number of circumstances will force a change in software at some point during its lifetime.

Jira is a powerful and highly customizable software project management tool. Because of its popularity and long-time presence in the industry, there is a myriad of add-on and integrations to the platform, including Slack and GitHub.

Make it easy for your co-workers NOT to have to ask you questions.

(and yes, I know, this has very little to do with sprints directly)

We don't blame, we solve.​

Easily the biggest hindrance to a successful project is in-fighting and finger-pointing. This isn't a game, nor is it life-or-death. It's a project. We're very smart people trying to solve some very complex problems. Mistakes will be made. No one will die. Money, on the other hand, may be lost. Let's not let it get to that. Paychecks are nice.