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
Agile approaches work for projects. Have you considered how to make agile work for a program? A program is composed of several projects, typically across the organization. Each of the sub-projects delivers value. But the real value to the organization is when all of the projects deliver results in a synchronized fashion. Since agile approaches
Via Jack Vinson, I found this gem: Stop doing half-actions. All of you who are separating your developers from your testers? You are doing half-actions. Separating the writers from the developers and testers? Half actions there, too. Even when you define architecture and implement across the architecture, instead of by feature, that’s a half-action. A
I’m writing the portfolio management book, and I just finished a whole big re-architecture. I’m so excited. I realize most people aren’t that excited about a rearchitecture :-), especially not of a book in progress. But I am, because I took my own advice. When I started writing the book, I had several partly done
I’ve taught several workshops where people wanted to learn how to start adopting some agile approaches. They knew about timeboxing, but didn’t quite see how to make it work. The part they were missing was having working valuable product at the end of each timebox. I explain that to the participants, and they nod sagely.
Thierry poses a question I’ve heard in several of my PM workshops this week and last week: When should the team do the architectural work? Thierry’s concerned if his team continues to implement by feature, how can the team do the architectural work? If they take an iteration or two to deal with architecture,
Joshua asked me to clarify what I meant by implementing by architecture. Here’s my picture-story. When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture. When a team implements by feature, they are cross-functional teams. When teams implement by feature, they do what’s needed in whatever part
Scott points out Software Product Delivery – 20 Rules? that you should do the riskiest part of the project first. (He explains that you modify that given what’s most important.) I’d add a further refinement: that what’s most important better provide the most value. If it doesn’t, do the most valuable parts first. You
I had the opportunity to read Practices of an Agile Developer: Working in the Real World. The book has 45 tip to help developers become agile. And, it’s clear that Venkat and Andy know the problems of becoming an agile developer, because along with each tip, there’s a devil-thought to show people what happens