Managing an agile team of internal and external partners

Tassos Koutlas (@akoutlas) - Cameron & Wilding

Alyssa Stringer (@stringeralyssa) - Investors in People

Who we are

Tassos Koutlas, Senior Technical Consultant

Cameron & Wilding

Alyssa Stringer, Product Owner

Investors in People

Big Blue Door

Development partner working with IIP for two years

Investors in People

● The UK’s leading people management standard

● Government initiative in 1990, commercially driven since

2012

● 14,000 accredited organisations (UK and internationally)

● Launched the sixth generation Standard in September 2015

● Online and offline assessment process

● Product and brand managed by Head Office

● Delivery managed by multiple licensed partners and 400

self-employed practitioners

Cameron and Wilding

Digital agency in London specialising at

1. Agile transitioning

2. Strategy

3. UX / Design

4. Technology

http://cameronandwilding.com/

The situation

● A small, ambitious brand team

● A 500+ person user base, and 14,000 client organisations

● Complex systems and multiple digital products

● Limited in-house technical expertise

● External development agency with distributed developers

● A traditional approach to project management

● A patchy approach to testing

● Buggy software

The challenge

1. Identify the nature of bugs and stabilise digital platforms

2. Creating new digital products for the future

3. Transition to a fully lean and agile organisation

… Achieve all of the above in six months

Discovery

A Sprint 0 to discover where we were. Our findings concentrated

on 3 things:

1. Communication issues

2. Project delivery issues

3. Quality issues

Communications [1/2]

● Too many tools used that made it difficult to track conversations,

● Discussions across mediums and channels (emails, phone, slack,

trackers).

● Too many people involved at various levels

● Panic when bugs were identified with no process for dealing with

issues

● Internal stakeholders led decisions rather than the team

Priorities were difficult to put across to the development partner. Their

biggest pain.

Communications [2/2]

What we did to address it:

1. We provided a single point of contact (Product Owner)

2. We started using Pivotal for managing the project

3. We started using Slack for any/all discussions

4. We started using Skype for any/all meetups (although we

experiment with many video platforms due to frequent

software glitches in all of them)

Everything ended up smoother and felt more controlled.

Product delivery [1/3]

● Not much involvement from IIP.

● Confusion between what was needed and what was captured in the

requirements.

● Inconsistency in requirements (some detailed; some high level)

● The development agency had no means to provide experience and

expertise on what was being built [culture/process].

Some agile elements were there but the process seemed fragmented

and was leaving room for improvement.

Product delivery [2/3]

What we did to address it:

1. We started using user stories instead of detailed

requirements

2. We started having a sprint goal (focused sprints)

3. The full team started participate on daily stand-ups

4. The full team started participate on sprint planning

sessions

5. The full team started participate on backlog refinement

sessions

6. The PO started leading sprint review sessions

Product delivery [3/3]

Scrum has allowed us to have more open communication and a

structured framework for delivery.

- Collaboration on product strategy and technical

implementation

- Daily Stand Ups for improved tracked progress and

transparency of delivery

- Sprint reviews allow for more open stakeholder management

- Bugs are effectively monitored and fixed as part of the team’s

daily work

Alignment

● Shared product vision

● Set expectations

● Clear roles and responsibilities

● Consistent framework (scrum)

Re-framing our work

Introducing user stories

Introducing acceptance criteria

Understanding the user perspective

Quality [1/2]

● QA process in place but not always enforced

● Confusion with development environments and deployment

process (frequent releases - new bugs)

● Inconsistencies on how specification is captured

● Stories do not have test plans associated with them

● Difficult to do regression testing if new functionality is

introduced

Quality [2/2]

What we did to address it:

1. Agree on a Definition of Done document for every

feature

2. Enforce every story to have a clear defined specification

3. Enforce every story to have a clear defined test plan

4. User test what was built (user feedback, avoid confusion)

5. Releases at the end of sprint

Definition of done

Code specs

Test plans

Culture

Day 1

An agile experiment

Day 180

- Iterative software development

- A product backlog

- A collaborative and engaged team

- An organisation that understands agile principles and the

opportunity to scale

Results

● A steep decline (60%) in bugs per month

(And a more consistent approach to dealing with bugs)

● A fully functioning Product Owner and other staff trained in

supportive roles

● An engaged development team providing insights, experience

and expertise in all aspects of the project, not just

development

● Iteratively delivering new functionality in half the time

● More open communication with the wider business

regarding release plans and ROI

● Impact maps for strategic thinking

Product roadmap

December January February March April

Benchmarking

Localisation

Paper survey

Emails & groups

Hardening

Statistics - Story points

Statistics - Velocity

Feedback!

Please evaluate our session here:

https://events.drupal.orgdublin2016/sessions/managing-agile-tea

m-internal-and-external-partners

Thank you!

Our whitepaper on Creating an Agile organisation has more in

depth lessons learned on transitioning cultures into agile and you

get a 50% discount on Packt Publishing ebooks by getting it.

http://bit.ly/AgileWhitePaper

Follow us:

@cameronwilding

@IIP