What risks does your project have? Do you need feedback loops so you can: Cancel the project at any time (to manage schedule and cost risks. Assess technical risks so you can rework the architecture or design to manage feature set risks. Manage what you release to customers so you can manage defect, feature set, […]
The original signatories of the Manifesto for Agile Software Development wanted to solve these specific problems: How can we: Bring more adaptability to software development? Stop “plan the work and work the plan” thinking? Release something of value earlier? Especially since teams now had these levers, from the iterative and incremental approaches: Prototype something for
I discussed the origins of the agile approaches in Part 5. In this post, I’ll discuss how you can create an agile approach that fits your context. Why should you create your own agile approach? Because your context is unique to you, your team, project, product, and culture. You deserve an agile approach that helps
Which levers does your team need to manage risk in your project? Do you need to cancel the project if you can’t finish a phase? You might not have the time. You might not have the ability to do this project. That’s the point of Serial lifecycles in Part 1. Maybe you need feedback from
One problem when you have a program with agile projects and non-agile projects is how to marry the two parts. The agile projects deliver value every couple of weeks. The non-agile projects? Well, it’s possible they don’t deliver value for months to years. In Managing Programs with Agile and Traditional Projects, I suggested that you
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
I’ve been writing through my travels. Today, Stickyminds published Not Ready for Agile? Start Your Journey with Release Trains. In February, Gantthead.com published Timebox or Kanban: A False Dichotomy. I would have let you know, but I was traveling and was unaware they published it! I write the columns ahead of time and don’t know