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
We are looking for authors for the Agile Journal. Here is the 2012 editorial calendar as a guideline for you: January: Requirements; Agile Game Development February: Low Tech Test Tools March: Mobile, Redefining Quality April: Acceptance Test Driven Development May: What is Quality? June: Agile Management July: Cloud Development August: Business Value September: Agile Testing
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
I spent the most recent four weeks conferencing. I had a blast. Because I kept traveling, I nicknamed this series of conferences my “Northern Hemisphere Conference Tour.” I’ve posted the slides on slideshare.net. Oct 24-Oct 28, I was in Vancouver, BC at Much Ado About Agile 2011. I delivered a keynote entitled, “Where is Agile
I am writing a book about agile program management. I have some portion of the first draft written. I don’t know how much, because I have not had any review. When I write, I can’t tell how much I’ve written until I have my first review. Then I will know how much I have that
So where does all of this get us with budgets and dates? In many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost. It does matter
In Part 3, you had some knowledge of the team’s velocity. This is the option of when you do not have knowledge of the team’s velocity, because this team has not worked together before, or has not worked on a project like this before. You are all coming in blind. Your Zeroth Best Bet: Wait
You have options for estimation, once you have met the preconditions. If you don’t have the feature set in a ranked order, you are in trouble. That’s because if you use any lifecycle other than an agile lifecycle, the feature order matters to your estimates, and the team will discuss the feature order in addition