Last Thursday I went along to a BCS (British Computer Society) organised event presented by a major influence in the DSDM space, Jennifer Stapleton. Thanks to Ian for recommending this as I really enjoyed her talk.
The Presenter
As a presenter, Stapleton obviously knows what she is talking about. She’s extremely comfortable with the content, and extremely lively on her feet – something I’m not sure the level-floored room was most ideal for. I’ll admit that her slides appear a little old fashioned with lots of bullet point text, or just lots of text and, what looks like, clip art all over the place. I do think, however, that the content is definitely worth while. The lessons she’s learned from her eleven (plus) year involvement with DSDM, considered as one of the earliest agile methodologies, certainly shines through in many of her examples.
The Audience
The event apparently sold out the week the BCS announced it and based on the names on the empty sign up sheet and the number of empty chairs, I guess a lot of people didn’t turn up. A few people who turned up on the night didn’t seem to have any problems entering. I noticed many more people with grey hair and suits compared to the other events I’ve been to (mainly agile gatherings, or language specific interest groups). Based on the questions thrown from the audience, I guessed a higher proportion of them worked for government agencies and a few of them came from academic backgrounds.
The Content
I think that what Stapleton had to say was extremely compelling, though if you’ve done agile software development, prepare yourself for a different world. Programme management goes well beyond what you’d normally think about, especially at the project level, and although applying agile principles at that level probably isn’t different, I’m sure the practices that go along with it are.
She started off by clarifying some of the terms that she used – the differences between a programme and a project, the differences between a programme and a portfolio and how she describes tranches (think iterations at a bigger level). I think her definitions of the terms are essential as I think a lot of people simply group things together and label things incorrectly as a “programme”.
She talked about what you need to be an effective programme manager and how you go about managing portfolios, programmes and projects to meet a programme. She talked about the impact of budgeting cycles that last a year, and the impact it has (feast or famine), finishing with her “Agile Programme Management Maturity Model” (yes, another one!), a tool that helps her evaluate organisations she works with. She also touched very briefly on feedback and cycles of feedback needed although I don’t think she emphasised it nearly enough.
Find her slides at the London Central BCS website.
A few new terms
SRO – Senior Responsible Owner – The SRO should also work out if the structure required to deliver the Programme can realistically be achieved, in order to confirm that policy can be delivered.
MSP2007 – Managing Successful Programmes 2007 – A qualification around the programme management space.
The Takeaways
- I like the fact that she explicitly considers change projects that tend to either flow alongside or follow a project (which also, may or may not be software based). In my experience, sponsors rarely think about how their project impacts other people and their roles in the organisation and this often has a huge impact on their success.
- Agile organisations need agile leaders. According to Stapleton and in response to my question, they’re not somebody that you can train (although I’m not convinced about that if you consider mentoring).
- At the programme management level, you don’t need to worry about the agile development process – instead it’s a focus on setting the right metrics (aligning rewards with goals and outcomes), and understanding how to co-ordinate and communicate results.
- DSDM explicitly addresses a fixed vision problem not necessarily solved by XP or Scrum directly.
- Simply presenting a model is not enough – I can see how people in the early stages of learning about agile programme management might use the APMMM as a direct measure (e.g. Organisation Z fits in category X because they do this or that) instead of trying to work out how to use it as a way to measure progress, or direct change.
- What Stapleton talked about covers a lot of principles. A gap of practices still exist that make it difficult for inexperienced people to apply directly. It’s all good to want to get to X, the question is, what’s the best known ways of getting there or, at least, what are the options?
