No space to co-locate team – think again

I knew I had a big problem when I walked into the new programme space and found 18 desks. 18 wasn’t enough. I predicted I would have about 35 people on the team and I wanted them together. Co-location is so important to me that I will always challenge the assumption of “there is no space”. And I have found there are lots of things I can do to get my team together.
Continue reading

When Buckets Go Bad

I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.
Continue reading

Reporting Percentage Complete on an Agile Project

What do you do when management asks for a percentage complete on an Agile project? The flippant answer is “tell them the percentage complete”. Agilists reject percentage complete when reporting on low level stuff. But for the project as a whole you can get quite an interesting metric, one that is based on real data, so why not calculate and share it.

Continue reading

Three Ways to Control Scope in an Agile Programme

I both embrace change and also fight like crazy to reduce scope creep. On my current programme I use three main techniques to control scope: Programme Vision, Release Goal, and Requirements Trade-off. In different ways all of these put the business in control of what is in/out of scope. But they all help me stay within budget and time constraints.
Continue reading

The Sign Off – An Example of Delegation and Decision Making

I had just joined a team as programme manager and was talking to the lead user experience (UX) designer about the latest version of the UX design. We’d not worked together before and this was the first time I’d seen the designs. They looked pretty good to me and I told her so. That is when it got a bit weird.

PgM: They look great.
UX: Okay, I’ll get everybody together to get sign off on the designs.
PgM: Um, who is everybody?
UX: <Lists names of the business representative, product manager, technical architect, business sponsor, technical sponsor, UX discipline lead for the department, development manager, portfolio manager, team assistant to take notes, and quality manager>. I hope they don’t want too many changes.
PgM: <Jaw drops>

Continue reading

Manage All Assumptions as Risks

Assuming something means taking it for granted. In other words you’ve got a more or less conscious theory (or, less charitably, a guess) that something is going to happen. The trouble is that the assumption might not be true.

That screams risk. And as a programme manager or project manager you need to manage risk.
Continue reading

Agile Programme Roles and Responsibilities

To go with my typical programme organisation I thought I’d describe the roles and responsibilities I expect on an Agile programme. Remember I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different mix of roles.

Some roles in an programme correspond to the roles in an project.  The scale of responsibility is larger and emphasis on coordination greater but the nature of the roles is broadly similar. The Agile Programme Manager, Programme Product Owner and Technical Architect roles fit this mould, corresponding to Agile Project Manager, Product Owner and Technical Lead.

In addition a programme needs some roles that don’t appear at all in a project, in particular Programme Director and Business Change Manager. Again these roles are a result of the wider remit and increased communication necessary in a programme but also because of the focus on organisational transformation.
Continue reading