In my previous post, I spoke about how I was embedded as an Agile Tester in a team delivering Financial Services (FS) improvements to an ecommerce website.
This post builds on that experience by talking about my time there as an Agile Coach working with several FS teams helping them not only to interface with Agile development teams, but also increase agility in their own working practices.
There were 2 Agile Coaches in the organisation; one was more focused on defining the new desired ways of working with the C-suite, Senior Leadership Team & execs, whilst I was more focused on helping the teams implement new iterative ways of working.
There were several FS dev & non-dev teams within FS organisation, so as well as working with each other to deliver FS specific changes, they were also interfacing with the non-FS side of the organisation (where I was an embedded Tester) which was already making great strides with agility.
My time was split between the dev teams & the non-dev teams
FS development teams
These teams required your classic Agile coaching for those new to iterative development, things like;
- Shifting mindset from outputs to outcomes
- Splitting up work in to appropiate shapes & sizes (backlog refininement)
- Who does what when (roles & responsibilities, team routines like standups, demos & retros)
- Estimation & forecasting (yes, both were needed)
- Ad-hoc & planned interventions to help continuous improvement through the lens of the Agile Principles
- Reminding the teams that they all own quality & helping them embeded continuous testing throughout the SDLC.
Some of the team members had negative experiences of Agile adoption in previous roles & organisations. Consequently part of my role included reframing agility in a positive light to help embed the new ways of working.
Typically, this involved:
- Reinforcing the importance of the Agile principles as a lens for process improvement.
- Not discarding the current processes (as the teams were actually delivering value).
- Reiterating that Scrum is not Agile.
These ideas surfaced through a common pattern; we start from where the team are now, identify where / how the team would like to improve using the Agile principles as a lens & then proposing some experiments to take some steps towards those improvements (this pattern was also applicable for the FS non-dev teams).
FS non-development Teams
These were the teams that were now starting to work more closely with the dev teams, being pulled into their routines without fully understanding why.
These were teams like:
- FS Product (discovering what financial products would be helpful for the customers)
- FS Compliance
- FS Marketing
Their exposure to Agile was pretty much zero (other than hearing about it around the organisation).
This “blank canvas” was fantastic for both me & the teams. They had never had Agile “done” to them, so were less cynical & keen to learn. For me it was like a greenfield project where uneccessary constraints were not yet in place.
This enthusiam of both parties meant that ideas were well received & questions were free flowing. This led to several of the team members embracing the experimentation culture we were striving for.
Some interesting challenges we working through with the FS non-dev teams inclued:
- Agile is only for software development & wouldn’t work here (a fair argument, seeing as it is the Manifesto for Agile Software Development)
- I needed to adapt my language to be less software specific as the message was sometimes lost in the non-software context
- The teams were organised into specialisms, resulting in long handovers & extended lead times
Onboarding / Inceptions
Each new team went through a facilitated onboarding process called an “Inception” to kick off the project. These sessions served numerous purposes:
- Shared understanding of the problem & desired outcomes
- Common Agile understanding & language between the team members
- Shared experience for the team (team building)
- Safe space to raise questions & concerns
These sessions also served as a fantastic opportunity to share both domain & Agile knowledge - each team member knew who they could to turn to for what.
Experiments
We were just getting going exploring ideas for process improvement when the Covid-19 pandemic swept around the globe, understandably changing peoples priorities!
Some experiments we were working on included:
- Building a “virtual” cross-discipline team to improve lead times of FS marketing campaigns (as changing the FS organisation wasn’t in our gift)
- Keeping a development team delivering iteratively whilst working with a 3rd party which was developing with a staged delivery cycle
- Running “Agile Basics” workshops with other stakeholders outside of both development & FS (e.g. Customers Services)
To be continued…
I’ll be writing up more on those experiments in future posts - watch this space!
Thanks for reading,
Duncs