Go Small to Gain Momentum You’ve seen projects that start off great. They zoom along, delivering. And then something happens. They slow to a crawl. Sometimes, they get stuck so badly you decide to stop and declare victory (or defeat) and start all over. What can you do to make sure that doesn’t happen to […]
If you saw Large Program? Release More Often, you might have noted that I said, You want to release all the time inside your building. You need the feedback, to watch the product grow. Some of my clients have said, “But my customers don’t want the software that often.” That might be true. You may
I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?” If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to join.
We got here because I started with Managing the Stream of Features in an Agile Program. That got me to Organizing an Agile Program, Part 1:Introduction, Organizing an Agile Program, Part 2: Networks for Managing Agile Programs, Organizing an Agile Program Part 3: Large Programs Demand Servant Leadership. Sorry I got behind. Life interfered. Some
Many months ago, Rebecca asked an interesting question about technical debt in projects. She asked, How to start when there’s a really big mess? In that case, small, just being a professional clean-up acts may not even make a dent. Of course, as with any good question, the answer is, “it depends.” And the biggest
Do you have a product owner who doesn’t want to admit to technical debt? “Give me another feature! And another feature! Just keep giving me features! It’s feature time, baby!” Once a product owner has the heady feeling of seeing features one after the other, it’s difficult for that product owner to consider anything other
We understand how to swarm around a feature as a collocated team. But how do you do that when you are part of a geographically distributed agile team? It depends on how you are distributed and across how many time zones. How are you distributed? Too many geographically distributed teams are separated by function. That
Once you have a program (a collection of interrelated projects focused on one business goal) and you have technical debt, you have a much bigger problem. Not just because the technical debt is likely bigger. Not just because you have more people. But because you also geographically distributed teams, and those teams are almost always
I’ve had several conversations in email and with clients recently that have all been about this question: “What do we do about our infrastructure?” Either the project or the program has to create/update/upgraded their architecture or automated test infrastructure, pay down technical debt, or somehow do something that’s not part of a story. And, that’s
I’ve been blogging about agile architecture, and the responses have been fascinating. Some people are totally against the idea of an agile architect, regardless of the size of the program. Others are ready to give me the benefit of the doubt. In this column, let me clarify the case for (or against) the job-titled agile