Posts

Why Fables?

I love fables. Like a picture is worth a thousand words, a simple story with a moral lesson is a good way to share experience — translating something complex into something smaller and more digestible. Looking back across my career, I have led teams of every sort, shape, and size across a lot of different industries. The people were different. The platforms were different. The tools were constantly changing, sometimes mid-project. But when I think across every engagement, one thing runs through all of them: incremental delivery of software. That is the only constant. Not the language, not the methodology, not the org chart or the budget. Just the steady act of shipping working software piece by piece and learning from what it tells you. I have done a lot of it. I have lived through the wins, the near-disasters, and the moments where the wheels came completely off. Every one of those experiences taught me something. Fables strip it down to what matters. A tortoise and a hare do n...
Read more

The Dangers of Micro-Managing from 50,000 Feet

There is a particular kind of manager who is deeply involved in everything and yet somehow never actually close to the work. They attend every meeting. They ask for constant status updates. They want to be copied on every email. They weigh in on decisions that are nowhere near their level. And yet, despite all of that involvement, they do not actually know what is going on. They are micro-managing from 50,000 feet — controlling everything in theory while understanding very little in practice. I have seen this pattern more times than I can count. And I have seen the damage it does. What It Actually Looks Like Micro-managing from altitude is harder to spot than the classic version, where a manager is looking over someone's shoulder telling them how to type. The high-altitude version feels more sophisticated. The manager is "engaged." They are "across" the project. They are "asking the right questions." But what they are really doing is creating...
Read more

What problem are we trying to solve?

No, really. Stop for a second and ask it plainly: what is the problem here? If we are doing projects, we are problem solving. We are trying to help our business run more efficiently, compete more effectively, or do something it could not do before. That is the whole point. Everything else — the methodology, the tools, the ceremonies, the frameworks — is in service of that goal. Not the other way around. The Problems Come in Every Shape and Size No two projects are the same. The business problem might be a spreadsheet that one very clever person built five years ago to track customer orders, and which now has 47 tabs, three people who understand it, and zero ability to scale. Converting that into a real system that can be supported and maintained is a genuine problem worth solving — and it looks nothing like building a new customer-facing mobile app from scratch, which looks nothing like upgrading a twenty-year-old core banking platform that nobody wants to touch. The permutatio...
Read more

Why Agile Fails — And How to Make It Stick

I have lived through this more than once. You walk into an organization, you can see clearly that Agile would make things better, and you hit a wall. Not a wall of bad intentions — most of the people involved are smart, experienced, and genuinely trying to deliver good work. The wall is something older and harder than that. It is culture. It is history. It is the accumulated weight of a command-and-control framework that has been built up over years, sometimes decades, and that has been working well enough that nobody with real power has had a reason to change it. And then you show up and tell them they should. Why Large Organizations Struggle The Agile Manifesto was written in 2001. But mainstream adoption — real adoption, not just putting "Agile" on a job description — did not come until much later. And even today, after more than twenty years, plenty of large organizations are still working through it. That is not laziness. It is complexity. Think about what it a...
Read more

Agilish — What It Means and Why It Exists

ag·il·ish /ˈajəliSH/ adjective Able to apply Agile values and principles to execute a plan quickly and easily. "The team worked in an Agilish way to meet their deadline in spite of unplanned obstacles." Relating to or denoting a method of project management characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans. "Agilish methods apply Agile concepts to different types and sizes of projects." The World Agile Assumes The Agile Manifesto was written in 2001 by seventeen practitioners who believed — rightly — that there was a better way to build software. The values and principles they articulated have stood the test of time. Incremental delivery, collaboration, responding to change, working software over documentation — these ideas work. The evidence is overwhelming. But the Agile Manifesto was not written with a Program Management Office in the room. It was not written with a heavily regulated ...
Read more

Parkinson's Law and the Case for Small Increments

par·kin·son's law noun — "Work expands so as to fill the time available for its completion." — C. Northcote Parkinson, The Economist, 1955 In a previous post I wrote about Ron Jeffries, the co-founder of Extreme Programming and the man credited with inventing story points. One of Jeffries' core arguments — and the reason he eventually grew to regret story points — is that estimation tends to become a target, and once it becomes a target it stops being useful. Teams stop working toward delivering value and start working toward hitting a number. There is a law that explains exactly why this happens. It has been around since 1955 and it has nothing to do with software. But it describes software teams perfectly. What Is Parkinson's Law? Cyril Northcote Parkinson was a British naval historian who published a satirical essay in The Economist in 1955. In it, he observed something that anyone who has worked in a large organization will immediately recognize: w...
Read more

The Story Point Conundrum

Estimating Software Projects is a Conundrum. co·nun·drum /kəˈnəndrəm/ noun — a confusing and difficult problem or question. The problem to solve is this: when you work at a company that has a Program Management Office (PMO) and/or is highly regulated, the business partners that sponsor and regulate projects expect accurate estimates for the work you are going to do. They also expect evidence that you are delivering on those estimates. At the same time, large projects tend to take a long time. It may not take long to deliver working software into production if your team is good, but to "finish" a project — such as a re-platform or a large scope of work — can take months if not years to complete. And over the course of that time, things change. Business priorities change. Technologies change. Your budget will change. The people on your project team will change. The longer a project needs to run, the bigger the challenge with estimating and delivering the software that...
Read more