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 →
The product owner defines what the development team is meant to build and the order in which it is built. What should you do when the Product Owner responsibilities lie with more than one person?
The short answer, that works in simple situations, is get the business to pick one. However things are not always so simple and there are situations where you will need more than product owner. I’ll outline a few scenarios, both good and bad, which for the purposes of this post I’ll characterise as Many Kings, Pretender to the Throne, and finally Chief and Indians. Continue reading →
I thought I’d share the way I organise programme teams. 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 structure and mix of roles. I push Agile but the same organisation would work with a less nimble approach.
There is nothing mysterious or radical about my programme organisation. In fact it is entirely in keeping with the guidance from Managing Successful Programmes (MSP). If you didn’t know Organisation is one of the nine Governance Themes from MSP.
Although I tend to apply the same shape to all of my programmes I do adapt it to local conditions. The size of the team makes a big difference so I’ll show how I have organised large, medium sized and small programme teams. I’ll also take a quick look at a poor structure for a programme team – with role based teams – and explain why I don’t fancy it.
There are obviously other ways of structuring a programme team but this is what has worked for me. Continue reading →
Karine doesn’t show up. She has a good reputation and was previously the product owner on a run away success. But on your project she seems quite distracted by other commitments. What she is working on is all good stuff and related to the wider programme but it means Karine often misses the important meetings with your development team. When she does turn up the team are very happy with the input she provides. They’d just like it more often. Much more often.
Phil doesn’t show up. He is a colleague of Karine and is product owner on another work stream within the same programme. Phil’s development team never sees him at all as he is entirely focussed on external communications.
Mike doesn’t show up. He’s the external customer and commissioned you and your company to build some software. He knows his business inside out but he’s never been involved in software development before. And Mike is quite busy and doesn’t often make it to your offices. When he does come in he talks to the CEO and not the developers.
I’m sure elements of these scenarios will sound familiar to you?
You’ve got a a big problem if the Product Owner does not show up to the key meetings of the Agile Heartbeat or is otherwise not engaged.
To address this problem you’ve got three options: Educate, Delegate, or Escalate. Continue reading →
P3M stands for "programme, portfolio and project management". Product management is a closely related discipline and as most software organisations do product development I’ll include it in the discussion.
P3M Levels: programme, project, portfolio and product management
That bit is simple. The tricky bit is agreeing what a project, product, portfolio or programme is. Projects and products are pretty straight forward but definitions vary quite a lot for programme and portfolio. A portfolio for some people is a set of products where for others it is a group of projects. I have, for example, met a portfolio manager who was responsible for some projects and within the same division met a another portfolio manager who was responsible for the product portfolio of the entire division. Programmes are sometimes seen as simply as a complex project or set of projects, or, more interestingly, as an initiative to deliver business benefit. Continue reading →
Each of the Agile methods includes defined roles. Some have more, some have, less. DSDM is the only one of the methods that makes a big deal of making role responsibilities explicit but I think this is important. To work effectively as a team people need to know what their role is and the roles of their peers. I have often had to coach teams on the demarcation between key roles on the team – typically the leadership roles, i.e. project owner, agile project manager (or scrum master) and technical lead. Continue reading →
One company I worked with called the start of the project the “Blueprint” as it is about roughly shaping the project and product. “Inception” is another common term for this phase in agile projects. This article outlines traditional project initiation then delves into more detail on Agile Project Initiation. Continue reading →
Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project. This article outlines traditional risk management, how Agile is a risk mitigation strategy, and how to do Agile risk management. Continue reading →