Agile Training Day

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.

Notes

• “let the people make the tools and processes that work for them”
• Back in the day they were using Prince2 and noticed they “always wasted time building things they didn’t use or need” and there was “always a barrier to change requirements”
• It was interesting to hear about issues with Prince2 as although I’ve worked in fairly waterfall ways in the past (ie. client -> designer -> developer -> “ahhh everything is not what we expected” -> live) I’ve never worked on teams with very formal methodologies
• They explained the Agile Manifesto and had slides for The 12 Principles of Agile
• “We ensure value by delivering to our users” as opposed to spending massive amounts of time writing documents about things that never come to fruition.
• “want to do it as soon as we can” (deliver value to users)
• “technology is changing so rapidly that what we known will be obsolete in a few years time” with regards to welcoming changes to requirements (which was one of the biggest hurdles beforehand)
• “teams in NHS used to be skillset focussed, now deliver products” Over time the NHS has begun to value multi-disciplinary product teams instead of having all developers in one team, all testers in another etc.
• “build trust between team and stakeholders”
• “Sometimes difficult conversations are required to make team better” on reviewing how the team is working, how people feel about the work they do.
• Face-to-face > call > slack > email
• “Progress is measured by delivery to customers” (and stakeholders). This prompted me to wonder how do you measure value of delivery vs effort.
• “ideally if everyone was co-located the sprint backlog would be post-it notes on the wall” This made me wonder, if that is true then would something like Real Time Board be more appropriate than Trello (ie. no comments etc) and if so then what would the appropriate way of capturing information be?
• “cultivating environment is really tricky” for getting people to be retrospective
• “communication is hardest thing about Agile” (hardest thing full stop I would say)
• “If we do fail, we want to fail in a small way not wait 6 months and fail in a big way”
• “Better for Scrum Master to be outside of development” Their experience of being both developer and Scrum Master was that it is very hard to be able to assist in the correct way (unblocking things) at the same time as working on developing the features
• “Product backlog is a what. Sprint backlog is a how”
• A good retrospective is about behaviour of why something went well or not, rather than the thing itself
• It’s very easy to talk about what caused something to go badly but what made something go well is often ignored
• Taking notes each day and preparing for the regular sprint ceremonies in a good way can be far more productive than trying to remember there and then
• Epics should be broken down into deliverable parts
• It was at this stage that I started thinking about how I feel when we deliver a backlog item. Often if it is demoable then it feels successful even if it isn’t a full feature. But if it is a thing that works fine but isn’t usable/demoable without other backlog items being complete too then it feels less successful to me even if that’s what we planned to do. I think this is because of Progressive Enhancement. My natural inclination to splitting things up following the PE mindset of “don’t build a car with no wheels, build a skateboard that builds up to a bike than builds up to a car”. So when we have nothing to demo, despite plenty of effort going to completing what we planned, it is because we have produced “the shell of a car rather than a useable stepping stone”. Just a thought. Might flesh out later. Maybe a well defined backlog item is something that can be demoed, otherwise how can it add value on its own without the rest of the epic”?

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.

Activity #1 - The Ball Game

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.

Activity #2 - Lego City

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.