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
Feature-itis. It’s an agile Product Owner game. It’s when the Product Owner says, in his or her best George Carlin voice, “Gimme Features. I don’t care about no stinkin’ framework. I don’t care about no technical debt. I don’t care that it’s going to make your work harder later. I only care about now. I’m
Bob Payne interviewed me about agile program management last year at the Agile 2010 conference and posted the podcast. We always have a great time talking, and that podcast was no exception. He makes me sound quite coherent! Matt Heusser interviewed me about my new workshop with Rebecca Wirfs-Brock about Agile Architecture. My column on
I love it when my readers challenge and question me. Thank you, Sam and Paulo for asking the equivalent of “Huh?” for Refactoring and Redesign are Different. You asked great questions. Let me see if I can answer. For me, the time issue is the lack of transparency about the time required to complete the
I’ve been working with people starting their transition to agile. They are all smart people—some of them scary-smart. And some of them are misusing some of the terminology. Some people are using the word “refactoring” to describe significant work, say, weeks or even months of effort of rework. Sorry, I call that redesign. To me,
I still have estimation on the mind. I saw The Impact of Accidental Complexity on Estimates and I was wondering about the effect of management on bad code. Do managers sometimes force developers to write bad code by allowing technical debt? Jay’s third point implicates technical debt as a cause: Introducing technical debt increases accidental
I’m at Belgium Testing Days, and in about 90 minutes, I’ll be giving a lightning talk as part of a keynote. I love lightning talks because I love to talk and I love the challenge of a 5-minute, go-for-broke, get-it-organized, and do-it. And, it’s an excuse to drink a lot of cold caffeine in preparation.
On the bike at the gym this morning, I thought about increasing my level. When I exercise, more friction is good. But when you develop or use products, more friction is bad. Brian Marick talks about this when he speaks and writes about “ease” for development teams. If you’ve encountered a web page that made
One of the problems many people encounter when moving to agile is that they (literally) cannot imagine iterations shorter than 4 weeks. I rarely recommend an iteration as long as 4 weeks now, and if people insist on 3 weeks, suggest they find the root cause for the reason their iteration needs to be so
Dave and Bob have great comments on my post, Might Three Backlogs Be Better Than One?. Dave is describing situations where management is making reasonable decisions, not incurring management debt, and by extension, technical debt. Bob and I have experience with significant management debt. (Take a look at Musings About Management Debt for more information