The Care Collective has launched its brand new website – take a look at thecarecollective.wales

 

 

Last week marked the start of our work to help improve our services to carers by focusing on their needs through user centred service design.  In this post James Taylor, a delivery manager from our partners Perago, shares more about agile ways of working and supporting delivery teams.

 

We champion agile ways of working because we’ve seen first-hand the benefits it brings to our projects and the organisations we work with. For anyone new to this way of working the terminology and language can feel a bit confusing at first. My colleague Ross wrote a blog post a while back about using agile which gives a bit of the background to this way of working. The Centre for Digital Public Services also has a guide to agile terminology that may be helpful.  In this post I’ll be sharing how we’re applying agile to our work with CTSEW.

When applying agile to our projects, we’re not just using a trendy word, or only thinking about the project management methodology, we’re thinking about what it truly means to be agile. It’s about bringing together the right people, at the right time, with the right focus – a common mission – to enable change and sustainable value.

 

How we’re working

Bringing the right people together

Ahead of starting our first time-bound period of work (which we refer to as a ‘sprint’) we got the team ready with a kick-off meeting. Kieran and Jen from CTSEW joined the Perago team for this session where we: tested the project vision, described the high-level plan, our ways of working, and agreed the next steps to initiate the project.

 

Just in time planning

Following the kick-off meeting we allocated priority activities from the main list (referred to as a ‘project backlog’) to the sprint plan (our sprint backlog). We deicide a weekly sprint duration would work best as this is a short, 6-week project. They key is to take across into each sprint only what we believe we can realistically achieve – with the aim of creating value as early as possible.

The idea of just-in-time planning may feel strange at first if you’re used to traditional projects, where all requirements are specified upfront, alongside the plan for the entire project. Instead of fixing the requirements and plan at the start of a project and completing the entire series of tasks before releasing change for operational use at the end of the project, you get much more flexibility. This way we are more likely to deliver the right change, at the right time, with the right level of governance. New requirements that come up during a sprint are added to the backlog and a decision can be had about when the work should be completed.

We hold regular planning meetings on the first day of each sprint to make sure we have  the right goals and activities and  shared understanding of the scope . To prepare ahead, mid-week we review the main backlog and sprint plan.

 

Keeping on track

Each morning we have what we call, a daily stand up meeting, to help keep us on track.  It’s a safe space for the team to discuss what work’s been done, what still needs to be done and if there are any blockers (current or foreseen) that need attention.
We use the following questions to guide our discussion:

  • What have I done since we last met to help meet our Sprint Goal(s)?
  • What will I do before our next meeting to help meet our Sprint Goal(s)?
  • Are there any current or potential blockers that will stop me or the team from meeting our Sprint Goal(s)?

 

This 15 minutes is invaluable – we come out of it with an engaged team, a focus on the work to be done, an early opportunity to identify risks and issues, and a flexible plan.

 

Setting clear goals

Without specifying change to the nth degree, it can sometimes be difficult to agree when work is complete. A good starting point is setting clear sprint goals and activities, we also agree acceptance criteria for our definition of done. We keep in mind the concept of Minimum Viable Product (MVP) which is to do enough work that something valuable is created which works in its own right and leaves opportunity for future improvement.

 

Reflecting on our achievements

We apply learnings as soon as possible rather than leave it to the end of a project when you can’t do anything about it. That’s why our weekly retrospectives are so important. We carve out time on the last day of the sprint to reflect on what went well, what didn’t go so well, and note the actions and improvements that can be applied in the future.

 

Sharing what we’ve been doing

We think its really important to show what we’ve been working on – arranging frequent demos or showcases help share what we’re doing and engage people who may not otherwise be involved in the project on a day-to-day basis. We can then also use this feedback to shape our plans or any changes that may be needed to work done. We’re planning to hold a ‘show and tell’ event mid-way through this project and towards the end of the project. On longer projects, you may consider holding an event each sprint.
These steps help keep us on track – but they don’t guarantee success. In the spirit of agile we’re always open to adapting them as we progress, learn and share.

 
The Perago agile checklist 

As part of our approach to using agile with the teams we work with, we’ve created a simple checklist that might be useful to any teams starting out on a digital transformation project:
 

  • Identify the right people to support the change

 

  • Clearly defined roles and responsibilities (e.g. executive / sponsor, product owner, delivery team etc.)

 

  • Hold a kick-off meeting and agree the:
    • Project vision
    • High-level plan
    • Ways of working
    • Next steps for initiation

 

  • Planning
    • Develop a backlog or list of things that need to be done
    • Agree sprint duration – for longer projects fortnightly or monthly works well, for shorter projects weekly or fortnightly is best
    • Planning – first day of each sprint – allocate activities from the main backlog to the sprint plan / backlog
    • Agree sprint goals
    • Agree acceptance criteria and the definition of done for each activity
    • Embrace change and new requirements – make a clear decision about when they will be actioned
    • Squeeze time in half-way through the sprint to review the plan and develop activities further

 

  • Communication and progress
    • Hold daily stand up meetings to keep everyone on the same page
    • Act to resolve blockers and manage risks
    • Show what the team has been working on – take feedback and use this to inform plans
    • Hold weekly retrospectives on the last day of each sprint to apply lessons as soon as possible