
posted 19th December 2022
Background
Getting your first role as a Scrum Master, Flow Manager, Agile Delivery Lead,
I was working in a big UK-based bank with an international reach. For a few years, I had been aware of the emergence of agile approaches and was more than intrigued. I could see common sense in the approach and loved the idea of learning fast and getting real feedback early. Maybe it was my experience and frustration of living the exact opposite in the past. I had sat my certified Scrum Master course and exam a year earlier and was very keen to use it. I had and continued to read up on loads of different books, blogs, and websites. However, I was stuck in a traditional Project Management role while the bank had a big "agile transformation" going on and I wanted in!

How did I get the role?
I tried my darndest to get involved with the big agile transformation but to no avail for over a year. I kept hearing good things about the transformation had and attended loads of "brown bag" sessions as well as a fair few workshops and internal meet-ups but nothing was there to get truly involved.
Then one day I met a Scrum Master in work in an after-work catch-up for our department and asked if I could shadow him so I could see a team with agile practices in the real world. Luckily, he agreed. I did this for the next two months, shadowing team events and catching up with him 1 on 1 whenever I could. He's a good guy and we are still in touch to this day.
The Scrum Master eventually decided to move on (not sure if my constant questioning and keenness contributed?). As the team and SM had been so good to me, I offered to cover whilst they hired someone else. Then I thought about the situation for a few days. It dawned on me that I could do this. The team knew me, I knew the company, the project, and the POs (there were two, we'll get to that) and asked if I could possibly step in for him. My manager wasn't exactly over the moon with this but she knew I had a passion for agile and a real desire to work day to day in that manner. She gave me her blessing as long as I helped find my replacement. Fortunately, I have a great network that I could call upon and found someone able to step in who I knew was unhappy where she was at the time. Boom! Let's do this.
As I'd moved fast in finding my replacement, I had roughly two weeks with the SM in place to facilitate a handover. I was nervous but mega excited. I had such a worry about knowing the technology and being a Jira whizz (all the wrong things to bat an eyelid about I have since learned).

Who was the team?
I'd obviously become familiar with the team, what I was not familiar with was that a load of them were contractors and were rolling off so I effectively took over the majority of a new team within two weeks!
The team was heavily influenced by the scrum framework but was not doing scrum well I'd later come to learn. The team was working on automating BI/MI reports across the private & retail sides of the bank. The tech was lots of SAS & Tableau-related work taking monthly, weekly, or daily reports and reducing manual effort to save the bank £100,000's in effort whilst increasing quality and coverage. Obviously being in a big bank risk-averse corporate environment there is lots of governance. However, this team was not subject to some of the big project governance as we were funded outside of the project side of the budget, that was a bit less of a headache but as I'd been a PM previously, I knew how to navigate it should we need to.
The team was split across multiple locations (Scotland, England, Poland, and India) with a team of 10 and 2 PO's (One for Private & one for Retail).
What did I do first?
As I'd been able to observe the team whilst shadowing, this helped immensely and I have done this where possible ever since (just observe and be present for the first few weeks. If the team asks for your opinion or insight great but hold back at first until you really understand what is going on. Some 121 time helps you dig a bit deeper too).
As the SM was moving on, I started to dig into the data available and started to see some patterns that I thought we could look at together and started to have a few more 121s that would give me more insight into the data I was seeing. One great thing about working with a BI/MI Team, they get data and are happy to talk about it.

What worked well?
From the data, I was able to share we found that a lot of the work we were taking on in each sprint was carrying over into the next. Also, the work was so big, some items would span two sometimes three sprints. What could we do? Luckily, we had a BA working in the team who also covered some testing for us. He would normally work between the POs and the report requestors to understand what we were going to actually work on automating, looking at data feeds, excel sheets, etc. We agreed that if he could start to break the work in the first instance into smaller pieces that could be put in front of the customer and PO to show value, we would do that and then share it with the developers to see if they needed anything more. We started off and it was not brilliant but we did notice that the BA, the end user, and the developers were talking more. We'd gone too far one way, now we needed to calibrate it. Within 3 weeks we were cooking! As our BA had taken the initial overview and broken it down and shared it with the developer when it came to testing, he knew what he was looking at and could take things further as he knew who we'd be sharing with and what we could share back.
As I mentioned above, one of the precursors to this success was being able to look at, challenge, and understand our metrics. We explored our lead times and batch sizes and made some positive changes early on. Without having that data to look at, it would have been harder to enable that change.
One other thing that helped me no end was finding allies early on via the 121s that I'd had. I got to know the team on a personal level quickly as we had things in common both work-related and in our personal lives. This helped immensely when seeing ideas and harvesting opinions.
What did I learn from?
After being onboard about a month after the SM left and seeing things speeding up and trending in a nice way my confidence was growing. The PO for our Retail side was somewhat present but the team was struggling for his attention a bit and feeling stuck. No problem, I've got this. Up steps Super Scrum Boy! Off I went to tell the PO what they needed to do/be so we can deliver at pace and if not, we could just get more done for the Private Bank. That went down like a lead balloon. What I did not appreciate was just how busy this guy was, he had demand coming left, right, and center and now here I am saying you need to be more visible to us. My pride took a sting and after a sulk, I apologized and we were able to have a more grown-up chat about what was possible and what would ideally work for him. What did I learn here? Think in systems, I saw the PO as our bottleneck. However, if I'd looked wider, I would have seen the pressure he was under and how I could possibly help or at least acknowledge him without being another antagonist for him.
One other one that sticks with me is when I suggested we try pairing in the team. I read a lot about the benefits of pairing and how it can both increase quality and speed up delivery over time. I spoke to a coach on another team where they were pairing so I arranged for two of our Scotland-based developers to come over with me to the other team's department so we could see how it worked and get their opinions on how it is for them in reality. The developers from said team loved it and demoed how they both did this in person and remotely and how it has helped them learn no end. I was thinking jackpot here, this looks good, and these folks are raving about it, what's not to love? Well, it turns out the folks in my team did it see it that way and were not open to it. I questioned why and got a load of technical reasons that I did not fully understand but that is by the by, the fact is they were not ready for this. There was no pull, it was all push from me. I am sure there was a lot more push from me that I was unaware of but I got away with it. However, this was a push too far. Classic over-reaching. This is something that I am much more aware of these days but I still fall for it as I am excitable and passionate about improvements and progress. Not every idea is good or bad but timing is always important.
There are many others I can think back on. I tried to make every retro fun. Each one had to have a theme and if everyone was not talking it was my failure! I used stats whenever I could where you may think this is great. However, without economic impact, no one really cares. Whereas if any of the leadership came to me for something, I was always trying to have all of the answers immediately there and then, beating myself up if I did not as it must look like amateur hour to them. Anytime I could see an opportunity that I thought could improve us I wanted to go after it. Turns out people can only stomach so much change at once. All of these things I have had to learn with egg on my chops but turns out you don't forget too quickly either this way.

What worked that I did not see coming?
One situation I was in was when one of the guys on the team kept telling me how much he hated agile. I hate scrum, there are too many meetings, and when do we get to the work. I don't care, blah blah, blah. I hate scrum! I just want to work on the important stuff fast. All this neigh saying was de-railing the team and it was a distraction that was not helping as I saw it at the time. Truth be told, there was also an element of hero work with this guy as he was very technically gifted with SAS and had worked with this product for a long time. This was also not great for the team as everyone would bow to his opinion which was quite often negative.
Now I have mentioned above my chat with the Retail Bank PO and how he felt we might be able to help him when we kissed and made up after my agile diva moment. What he thought would be good was if he had a dedicated resource to work with so he could capacity plan better and manage the demand coming his way better. The dev and he got along so we agreed that they would work together and as long as the work was visualized and we could leverage the dev for the Private Bank work if there was any dry spell on his side we give it a go and also agreed we'd leverage other developers on other Retail work as and when required but for now he'd have 1 dev he could count as his own as most of the work in the retail side was mortgage-related so they'd mostly focus on this.
I was not overly happy but I had been thinking could we split the team in a way as two POs and a team of 10 was not exactly ideal. However, I was nervous about this (probably as I felt I was letting go somewhat). What it did give me was a separation from detractor/hero working that was having a negative effect on the team. What I did not see coming was how well it worked. They sat together and flow increased in the area with less hand-off time. Releases sped up and started to happen daily at times as testing and acceptance happened in real time with them pairing up. For someone who hated agile, did not want to try pairing, and was in general a bit of a grump was all of a sudden (slightly) happier. They still came to the events but the detraction noise was reduced massively.

How did it end?
Unfortunately, despite the greatly received work, our funding came to an end. Although we had hit the target for the year for person-hours saved and then some. There was a re-organization going on in our department. Most of us stayed together (7 of us) and we moved on to another short-term target within the Risk & Finance side of the bank. Now we really started to focus more on leveraging the end user's intuitive usability of Tableau and we focussed on this for the next 1.5 years across the department reducing waste and improving insights freeing up analysts to analyze and stop being slaves to a never-ending Exel/PowerPoint cycle.
What are my biggest takeaways?
As a Scrum Master, you need to be able to shut up and hold that silence, even when it feels awkward. I remember our facilitator highlighting this when on my Scrum Master course but never did I truly understood it until I experienced it. Sometimes the awkward silence is the signal that the gold is about to surface so hold on! The team needs to arrive at the decision themselves, you can't make them do it. You can prompt and direct gently when going down rabbit holes but you don't always know best so help the team by enabling the team to explore it. Don't try to be the smartest in the room.
No one cares about good scrum, the picture-perfect burndown, constant and high velocity, or the best definition of done, the business cares about value delivered to them and if you can't demonstrate that, are you really working on the right thing for them? It's OK to question what people ask for. Talk to stakeholders about what is important to them in a language they understand.
Something key that I learned early from this experience and it has not failed me yet is the idea of Breaking it small, so you can test it quick, then release it fast, so you can learn early. I constantly remind myself of this regardless of the level I am working at or the team I am part of. If we can't see this happening, what can we do to enable it?
What would I do differently?
If I had my time over, I would definitely want to do some things differently. I would definitely have slowed down my push for improvement and ideally taken a bit more of a backseat to enable others to shine. It is really hard to find that balance of measurable improvement at the right rate of absorption for the team where there is a slight discomfort of change but not to the point of damage, like when you go to the gym. You feel you've been working out but if you injure yourself then that's too much. Even now I struggle with this but scaling change back to the smallest measurable test is a nice way to start rather than uber-happy Matt cracking the change whip every 5 minutes!
I love data and one of my favorite quotes is, "In God we trust, everyone else brings data" That said, I would have definitely slowed down the amount of data I thrust in front of the team and tied it back to economic factors so they saw the real impact of what we were dealing with and let them decide what is the best course of action rather than just wanting our lead times and change failure rate to reduce.
Obviously, I would slap myself too if I could get in front of me prior to my demands being served to the retail side PO! I would have approached that in a much better way I'd like to think.
What am I most proud of?
Personally, that team helped me loads. It got my foot in the door to a way of working that I love. I have definitely grown over the years since then and whilst that path may have been seeded previously, that initial years' experience has helped me no end and I still use that experience today.
From a team perspective (I'd like to think we knocked it out of the park results-wise!) I was really proud. We broke new ground for me as I thought we all had to be in the same room. However, we were early adopters of tools such as Zoom, Mural, etc. and the growth we saw from utilizing these collaboration tools was massive. Also, from this team, we formed a nucleus that would form some of the teams we were part of next (some of which were some of the best and most enjoyable teams I have ever had the privilege to be part of) but the biggest thing for me is how one of the folks (The BA/Tester) has since developed into an SM in one of the areas that I worked in previously.
Prior to that Scrum Team (I'm pretty sure he would not mind me saying this), he was a little disengaged with how things were and the way in which he had been engaged in work so I am so happy for him now as he's a great guy and a real energizer for change when empowered and supported.
Hopefully, you have been able to take something away from all of this. It has been great to think back and relive some of the good memories as well as squirm a bit too. Are you still looking for your first role but holding your certification? Maybe you're working with your first team and feeling lost. Maybe you are an experienced coach and you've experienced some of these pitfalls firsthand. I'd love to hear about them so do let me know below!