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 caught up with posting a couple of Pragmatic Manager email newsletters last week. My January email was Why Multitasking Doesn’t Work. The April email was Agile Programs: Possible or a Pipe Dream. If you subscribed, you’d have read them by now.
Rothman Consulting Group, Inc. Vol 8, #2: Agile Programs: Possible or a Pipe Dream? April 25, 2011 In This Issue: Agile Programs: Possible or a Pipe Dream? AYE Early Bird Discount, April 30, 2011 New to the Pragmatic Manager? Agile Programs: Possible or a Pipe Dream? Yes, agile programs are possible. If fact, some
I’ve been working with program teams lately, and some of them have issues when they talk about different teams on their programs when they use words such as “headquarters” and “remote” locations. The headquarters teams tell me the remote teams don’t listen to them and the remote teams tell me the headquarters teams don’t hear
A few months ago at Agile Boston, Mike Cottmeyer said that when he looks at teams who want to scale agile, he looks at their ability to create working teams. If they can create teams, they can scale. If they can’t, they have little hope of scaling agile. (Mike, if I’m misquoting you, I’ll correct
A great way to destroy a program is to avoid writing a charter. When I do assessments or work with teams, I often find that programs do not have charters, or that the charter is too big, or is missing some key piece of information. But what do you really need in a charter? Too
I’ve been working with and discussing agile program management with a bunch of people. One of the big issues is: what do we call certain people at the program level? We need a program manager, someone who sets/explains the program’s vision, develops program-wide release criteria with sponsors, has a way to articulate program status, someone
I’ve been working on agile program management and a colleague emailed me about his program. He’s having trouble seeing how to do agile on a large program. The customer wants to see a working system before they add the features, so the customer thinks the program need to provide “all” the architecture, with some hard-coded
I’ve been working with Rebecca Wirfs-Brock on an agile architecture workshop. I’m working with Rebecca because she has such a depth of experience in architecture, as well as design. She’s working with me because of my project and program management experience. We’re pretty psyched. We’re working through the issues of large programs and architecture, and,
I’ve been working with organizations who want to move their programs to agile. They’ve been successful with small projects. But now, they want to make agile work with large programs, programs that involve hardware or firmware, programs with many pieces of interdependent software features, programs of 50 to 300 (or more!) people. Now, you might