Why change? A question I've been asking a lot recently, but I guess the drive for the change has been building momentum over the last few months, leaving us in a position where working our own way, just doesn't seem sensible any more.
- The project teams have demonstrated that agile works for them.
- Spread across multiple projects, the Tech Comms team are always at risk of clashes for our time. Working outside of the process that everyone else follows only risks exacerbating that problem.
- Speaking to colleagues across the business, I discovered that other Tech Comms teams are working to an agile methodology, although not within specific project teams.
- At the TCUK conference, most people I spoke to, were working closely with their development teams within scrums, with no real problems.
So that's the why, now the how.
Although we had the feeling through casual conversations we'd had with the different development teams that they'd welcome us working with them in scrum, we wanted to ensure that they were all in agreement that this was the right thing to do. We also wanted to make sure that we were working with the teams in the same way. We're only a small Tech Comms team and we don't want to be working in different ways across four different projects.
We drafted our thoughts into a document (what else) and distributed it to the scrum masters for each team, and invited them to a meeting to discuss. The main process for each sprint was summarised in this diagram.
The teams were all happy to start working like this - we have agreement - and all in a half hour meeting.
Yes, the nitty gritty needs to be ironed out. I suspect that they are using TFS in subtly different ways to manage their development, so we need to spend time with each of them and understand that. We also have one team who aren't using TFS for sprint planning. So, we have to understand at least two different ways of managing projects.
But, I'm pleased that we're doing this.
No comments:
Post a Comment