Agile101 – Agile Project Management and Digital Publishing

Agile Project Management, Programme Management and Digital Publishing

Today is Saturday, January 21st, 2012

Agile Programme Management Increases Flexibility

increased-flexibility

There are numerous benefits to adopting Agile ideals and introducing Scrum/Kanban-esque practices at a programme level. One of these benefits is increased flexibility, which in turn offers improved output, reduced time-to-market and increased value.

With more teams, you have access to more resource and a wider range of skills (!)
By staggering sprints, you are increasing the number of sprint entry-points within a fixed time period
By hosting programme-level planning meetings, work can be allocated based on skill set, experience and/or priority
By spreading knowledge across a wider team, you reduce the impact of illness, holiday and/or new starters
By introducing Risk Assessment reviews you are able to re-allocate resource or plot decision points/actions
By introducing an Epic Board, you create a visible plan of the project pipeline (Resourcing/Risk Management)
You are able to prioritise delivery at a Project/Product level AND at a Story/Task level

More resource – Multi-skilled teams

It’s all well and good saying that an Agile Team has to be multi-skilled. The implication is that an Agile team should be able to respond and deliver any/all requirements thrown at them. The reality is that every person and every team will have strengths and weaknesses.

The objective of a recruiter/manager at a project level will be to create a team of generalists with a few specialists thrown in for good measure. One benefit of having a multi-team programme is the opportunity to secure a wider range of specialists and a higher number of generalists that can be re-purposed according to priority.

Staggering Sprints – Risk Management & Change Management

By staggering sprint start dates and/or sprint durations there are more opportunities to respond to changing priorities without compromising team focus during the course of a sprint. This can be useful when managing risk, dependencies and change.

A recent example:

Team A must complete project ‘Minimum Marketable Feature (“MMF”)’ by a certain deadline in order for us to present a competitive product offering at a very important industry event.

We’re now in sprint #2 of 5 (with three sprints to go until the event). We know it will take us at least one full sprint to deliver the MMF but the sales teams have just secured a phenomenal campaign that needs to be delivered by the end of Sprint 4.

We think we might be able to finish the commercial deal within 1-2 sprints based on our velocity but we’ve never done anything like it before.

If all goes to plan then we should finish the commercial deal by the end of sprint 4 (maybe even sprint 3!), which should leave us enough time to finish the MMF…but it’s looking tight.

Team B is starting a new sprint in the middle of Team A’s sprint 4.

************

Risk Assessment - Risk of not delivering MMF may result in poor performance at the industry event (3/4)**

Risk Mitigation - Decision point at the end of Sprint 3 – Re-assign the MMF work to team B

************

**Risk Rating – Likelihood 1-5 / Impact 1-5

Programme-level Planning and Prioritisation

One benefit of delivering stories that comply with the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) is that dependencies between stories are minimised and often eliminated entirely.

With few dependencies existing between User Stories and/or Epics, a programme manager can work with their product managers to ensure that the most valuable User Stories are being delivered at any point in time. This may involve seconding more than one team to a project for part of the project.

By introducing an Epic Board into the mix, work streams are able to easily review and negotiate workload across sprints and work streams. Work can be allocated based on the skills available, holiday cover, previous experience, deadlines etc.

Epic boards also enable programme managers to identify resource bottlenecks and other risks/issues that may appear in later sprints. By discussing the project pipeline at the Scrum of Scrums and in the Programme-level planning session, risks and/or decision points can be added to the Epic board – Risks are represented with different coloured cards so that they are visible at a glance.

It is possible to minimise complexity of a programme by introducing Work in Progress Limits (“WIP”) at a programme level on the Epic Board – as per the Kanban approach. This can be done by capping the number of Projects in Progress (might be based on the number of Product Managers) or Epics in Progress (based on the number of teams).

It is also possible to monitor and allocate work based on Project budget/Sprint Budget. By introducing a common point estimation system i.e. a 1,2,3,5,8,13,21 is the same across all teams you can quite easily calculate the average cost of a point in the Fibonacci sequence. You can then divide work across teams in order to reduce time to market without worrying about complex cost tracking.

Cost of a point = (ave(velocity/days in sprint)*(cost of department/working days))

For more information about how to calculate the value of a point, read my post about caclulating the ROI of implementing Agile Project Management practices. In short, the value of the whole can indeed be greater than the sum of the separate parts when you allow each part to work to your advantage.