I’m no stranger to the world of Agile, having worked on a multitude of teams that have attempted to work in some kind of agile way. Some have sprints of 1 week, others have sprints of 2 weeks and some don’t have sprints at all. In every case, there was never a perfect solution. That remains true and is perhaps the entire point of the Agile Manifesto in the first place, to understand that things change and a flexible approach is always the most appropriate way to work.
I’ve never done a formal training session, just picked up as I’ve gone along. Again, that’s kind of the point. However I always try to reflect and find gaps in my knowledge so when my colleagues on NHS 111 online invited me to a training session they were giving I thought it would be worth coming along. Quite quickly after arriving I realised that one of the biggest takeaways from the day would be understanding how other non-development/product teams think about working in an agile way and the struggles that come with trying to apply that approach in an organisation like the NHS that is traditional full of more formal methodologies. I’ve been very lucky to always work on teams that at least understand the benefits of Agile .
The day was run by Tom Axworthy and James Tiffen (spoilers ahead if you are intending to attend one of their sessions too), people I’ve worked alongside for the past year and a half. They made it clear at the beginning that the day would consist of essentially two days packed into one and that it would be very much activity-lead (to mimic agile teams instead of being talked at). It was a good day, there was a good split of people I knew and people I didn’t so although parts of it got a bit deep into how the 111 online team works, there was a lot to learn from the other people from varied backgrounds such as procurement and a more agency-like team. It is so easy to think of agile as something just product teams do, so that was quite interesting to think about how it would affect other types of work.
That was the notes I took based on what they both said while going through the slides. They rattled through these really quickly and focussed the rest of the day on two activities.
The ball game was simple in theory, you have to pass balls to each other and how many balls get around all people and back to the start count as a delivered. What soon became obvious though was that we needed to practise different approaches before having any idea what would work, planning ahead wouldn’t have helped. Also while we did have the rules in front of us, we all misinterpreted the rules. For example, I thought the balls that were available were the only balls we could use and once delivered they went on the table. But in reality the rules only said they must get back to the start. So we soon realised by the last person putting them on the table, they never got back to the start and we had zero points. We also noticed that meant we could reuse the balls so it worked as a circular pipeline. We were told to make sure the balls always went through the air and never touched the floor or a container and so started quite far away from each other. Over time we realised the closer together we all were, the better it would work and all we had to do was drop the balls into each other’s cupped hands.
The main point of this process was to do a retrospective after each timed session and work out what the best approach going forward would be. One particularly interesting thing was that half way through we were getting around 40 points (up from 10) and thought that was amazing. Then were told that other teams got roughly 130. So instantly we realised we could do better, worked out how (doing 2 or 3 balls at a time) and ended up getting around 130 ourselves.
It just goes to show no matter how well you think you’re doing, it is hard to know what the potential is.
Oh I love Lego. Our “vision” that we had to meet was to create a Lego city that had tourists who would think it was a lovely place but it was actually a secret experimentation laboratory.
I could go into massive detail about how we build a city, and kept getting told off for not quite meeting the criteria of the backlog item (because we hadn’t asked for it to be fleshed out further). Interestingly we had to all figure out together how much effort each backlog item would take and I thought the perimeter wall would be the hardest thing to do because you had to wait till the end to do it and it was unknowable how big it would be. Everyone else disagreed and said a small wall is simple. It turned out to be a big task because it had to be so long, a particular height and with guns (that the “product owner” hadn’t actually told us about) and also a lot of the bricks had already been used.
I think this task really showed how everyone does work in the real world. Anyone that has worked with me knows if I feel like I’m not being useful, I make myself useful. This is great in the sense that I don’t twiddle my thumbs doing nothing, but it means things get brought in that were not already planned and often my views differ to other people’s. It’s something I know I do, but really showed me that it is a trait of mine not just when I work on things that are in my expertise. How I fix it I’m not sure, but it’s definitely enlightening.