I’ve been developing an agile architecture workshop with Rebecca Wirfs-Brock. Aside from more Murphy’s Law moments than a small project deserves, we’ve encountered a number of agile architecture and program myths. Here are three for your reading pleasure. (Just in case you aren’t sure, all of these are false–they are myths.) “We don’t need no […]
You interviewed with a team a month ago, and you were a little concerned. It didn’t seem as if they were keeping to their iterations. Their product owner wasn’t grooming the backlog often enough to keep the backlog filled for the release meeting. They seemed to have an awful lot of defects piling up at
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
To continue our story from part 1 and part 2… The teams have determined their individual impediments to Continuous Integration. You, as the technical program manager, and the technical program team can take those impediments, with input from the teams can see the impediments to program-wide continuous integration. You have used a similar problem-solving approach,
Let’s set the context (which I did not do in my most recent post–sorry). Define a Program A program is composed of several feature teams, which may well be working on several projects or different feature sets. I assume they are. The goal of a program supersedes the goal of any of the projects, and
I like continuous integration. A lot. I started being an aficionado of continuous integration back in my senior year of university. It was my very first (and last) team project in my college career. There were three of us. The project manager waited until the night before the project was due to get us all
Workshop Objective: If you’ve been reading the software engineering literature, you know that Agile is all the rage. But moving from a phase gate lifecycle (or even a strictly iterative or strictly incremental lifecycle) to iterative/incremental development is quite difficult. Not only is the project planning different from planning up front, but moving from technical practices
Workshop Objective: After this workshop, you will be able to develop appropriate project plans for a software project and execute those plans, reviewing risks, and making appropriate tradeoffs. This workshop is based on my project management book: Manage It! Your Guide to Modern, Pragmatic Project Management. Workshop Overview: This workshop presents project leadership planning and implementation for sofware-oriented
Workshop Objective: If you’re dreading the next project—because you know it will be a disaster, or at the very least uncomfortable—it’s time to think about designing your next project. We’re accustomed to thinking about designing products or tests, but projects? Is it really possible to design a project? Yes. Lifecycles, those idealized approaches to organizing
Workshop Objective: This experiential workshop provides you with an understanding and options for how you might create a successful geographically distributed agile project. The topics we’ll address are how to plan and execute the work for a geographically distributed project. Workshop Overview: If you have teams all over the world trying to create a product together, you