If you’re new to coaching, you might also enjoy the talk I did on stealing coaching lessons from sports at Dare Conf Mini a couple of years back: video and slides.
Thank you for welcoming me to speak at agile.delivery and for all the positive feedback, especially after the plethora of AV issues. Slides are shared here, as well as the promised links to the various books mentioned.
If you’re new to coaching, you might also enjoy the talk I did on stealing coaching lessons from sports at Dare Conf Mini a couple of years back: video and slides.
I was delighted to speak today at the Digital Project Management Summit 2014 in Austin, Texas. Below are my slides, and the links to the books and resources that I mentioned.
Tonight I spoke at the London Content Strategy Meetup, an excellent group sharing best practice in the content strategy & development arena. I really enjoyed hearing about Age UK’s research & understanding of older people (or “people in later life”) from Rob and then Chris‘ fascinating approach to figuring out a content strategy for building advocacy for mental health de-stigmatisation amongst young people.
I was quite nervous about talking about agile to this audience, particularly since I’ve only really gotten good exposure to content strategy, design and management in my year at GDS. But they were a lovely friendly bunch and I’m really grateful to Sarah Richards & Graham Francis for suggesting me to the organisers.
Essentially I subtitled my talk “a magical mystery tour of Meri being an idiot” and talked through the various lessons I’d learnt about how agile is actually a pretty brilliant approach for content development.
The book I recommend at the end is an absolutely BRILLIANT summary/primer/refresher on Scrum — I heartily recommend you buy at least a copy for yourself and possibly one for everyone you know who needs more agile in their life. You can get it at Amazon or on Kindle (I promise you the Kindle version will be the best 77p you ever spend. Seriously.).
We talk a lot about agile here at GDS. We use agile methodologies to focus on our users. The faster we can build a functioning product, the sooner we can get it in front of real users and start iterating based on their feedback.
This has a number of implications for how we organise our projects and manage our people, and I wanted to explain how that affects they way we work.
Multi-disciplinary teams
In practice, we group our people into small, multi-disciplinary product teams. These teams will work closely throughout the day, often meeting first thing for a stand-up, a very quick recap of previous day’s work and a round up of what they have planned. If an area grows too large we break it out into smaller teams again — no one wants to be in a stand-up of 30+ people!
A typical product team will have a product manager (defining the vision for the product and how it will meet user needs), a delivery manager (agile project manager with a focus on making things happen), a technical architect and then a mix of developers, designers, web ops and content designers. We also have folks focused on understanding our users, including customer insight, user research and product analytics.
Transition team stand up
Matching people and projects
We have chosen to organise all of our “makers” into a flexible pool called the Delivery Team which currently has over 70 people. As requests for skills come into this team, we look at what is needed and then match to someone with the right skills and interest in that area.
We want everyone to have challenging, rewarding work, using their current skills well and stretching them to develop further in their chosen specialism (or in a new area if they desire).
Since we may well move people from one team to another based on the needs of the project, we deliberately keep line management separate from project assignment. Some worried that this would be confusing but in practice it has worked well. Each individual can turn to their delivery manager for project specifics and has their line manager as sounding board and for career, personal development and similar topics.
Harmonising not standardising
Over the past few months we’ve also tried to do things in a similar way across products where it makes sense. For instance, having the same sprint timings makes it easier to move people from product to product; encouraging all our delivery managers to use terminology in a consistent way has also helped us to communicate better.
Don’t do it all by yourself (you can’t)
At the moment we have a number of product teams all running in parallel to build GOV.UK as well as a number of other projects.
In order to meet all the short term demand, we have added to our core staffing with a number of contractors from a range of small and medium sized businesses. They’re working on projects with very specific time-limits, and they’ve help make make sure our core staff have the flexibility & agility to respond to changing needs. They’ve also brought us some external perspectives and practices, which have been helping us to meet user needs in the best way possible.
I was delighted and honoured to write an article for this year’s 24ways advent calendar. The topic is Project Management, with a bit of a festive analogy used to impart some top tips for keeping projects on track.
Go on over, check it out and let me know what you think!
