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
The nice folks at getabstract like Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Some of the takeaways they highlight are: Project portfolio management helps you finish your software projects on schedule. You must understand your mission to make choices about prioritizing software projects. Managers must select which projects to undertake and
I hope that this 3-part series on how to move to continuous integration and how to evaluate if it’s worth moving to continuous integration on your program convinced you moving to continuous integration was worth it for programs. The reason continuous integration is an issue on programs, is because the lack of CI can delay
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
Matthias Bohlen interviewed me as part of the preparation for the OOP conference. We spoke on a wide range of topics, not just my talk which is “Six Behaviors to Consider When Hiring for an Agile Team.” We spoke briefly about program management, which is why I’m leading my influence tutorial. Hear the entire podcast
I missed one presentation in my last post. At Oredev, I had an opportunity to speak with the PMI Sweden folks (at least, the southern Sweden folks). I talked about Agile Program Management, and discussed my current thinking about agile program management. As I’ve been working with clients, I’ve been updating my thinking—what a surprise