I’ve just finished up a role as an Agile Coach in an eCommerce enterprise helping their Financial Services teams adopt a more iterative approach to value delivery.
Before that, I was embedded in one of their development teams as an Agile Tester.
This post is a summary of our adventures as developers building relationships with our colleagues in Financial Services….
January 2019 I started in the org embedded in a newly formed team as an Agile Tester. Throughout that 12 month contract, as well as helping the team with Agile testing, I was also helping with general agility both in the team & outside it.
The team I was in was tasked with making improvements to the site for updated FCA regulations.
This was a fascinating challenge as the primary stakeholder we were delivering value for was the FCA, not our customers.
This lead to some interesting tradeoffs between customer value & FCA value. Needless to say, we ran a lot of UX tests & the tests returned some fascinating results.
So many stakeholders!
This challenge gave me the opportunity to share one of my favourite lessons from Tom Gilb:
“every project fails because a stakeholders needs have not been met‘
Here’s an image outlining the various stakeholders involved with a project from Roxanne Miller
This project (and it was a project) gave everyone involved in it the chance to see how many different stakeholders needed to be satisfied in order for it to be a success.
We ran the project with elements of Scrum & Kanban & the various stakeholders attended our various routines like standup each morning, story kickoffs (3 amigos) & demos.
At the beginning of the project, we joked about us developers calling our stakeholders “the business” & they calling us “IT”.
Over the months, “the business” correctly narrowed to “the FS team” & we “the dev team”.
But even “FS team” was too blackbox. We wondered why clarification questions took so long & why there were so many changes to the copy?
Opening the FS team black box
Eventually, we opened the box & asked them to walk us through what the “the FS team” actually consisted of.
We were amazed at the whole other world they were working in & the other challenges they were facing besides our web project.
This gave the team a real feel of the bigger system they are part of.
Here’s a breakdown of some of the other responsibilities in “the FS team”
- There was a team who was responsible for coming up with new financial products to help our customers spread the cost
- Another team would evaluate the risks of those products & give them the yay or nay
- One team would liase with 4 other teams in order to create marketing strategies of the new products
- Another team would check all the copy related to financial products
- Sometimes, all of these teams needed to defer to a higher team for clarification
Each of these teams has their own process & processes for working with the other teams. These processes were not iterative, but they worked.
Now these teams are being asked to work more closely with development teams who are striving to do more iterative delivery; how do their current processes adapt to cope with this new interaction?
For some, it was like tying to mix oil & water.
Expanding my reach outside of our development team
Our development team had a working process which was delivering value.
I started to see how I could help those FS team members interfacing with our development team improve their ways of working with us to be more sustainable.
Things started to make more sense for our colleagues outside our development team & they started to adopt the Agile Principles into their ways of working.
It was fascinating to see how ideas from a manifesto for software development could be adapted for non software related work.
This is a journey I wanted to be part of!
So I took a step out of the team as an embedded Agile Tester & started back at the same organisation as an Agile Coach, helping FS dev & non-dev teams navigate their way to increased agility!
More to come in the next post…
Thanks for reading 🙂
Some of the resources used for non-dev team members Agile basics training include:
- Agile is also for teams that DON’T build software (blog post)
- Agile for non-software teams: a practical guide for your journey (book by Gil Broza)
- Agile values & principles for non-SW Teams (26 mins talk by Roberta Stafford Agile On The Beach 2016)
- Agile Manifesto – the complete Guide (free ebook by Agile Arthur)