A Tasty Agile Pi

I've always looked with cynicism at posts on here trying to shoehorn work topics into other events or activities, but my experience this weekend just needed a write-up. Bear with it - I promise it's related to software!

I headed down to London to help out with an attempt to calculate Pi to the highest precision we could manage, by hand. No calculators, no phones, no computers, no smart watches, pen and paper and mental arithmetic only. Why, you might ask? I love the frivolousness of it - there's no point to it other than the doing of it, and the celebration of the joy in doing it. Nothing like we did has been attempted at this scale for many generations, at least 2 living memory's worth, we were told. We had 100 - 200 people a day working towards it for 5 days in total, and people came from all corners of the planet (see the map) to join in.

Anyway - to achieve this, there was a HUGE operation set up which involved thousands of worksheets being created for long division calculations, which people took and completed. Once a sheet was submitted it went through a barrage of checks - the check-in desk did an initial scan to make sure everything was readable and filled out, then each calculation was actually done numerous times (usually 3, but sometimes up to 5) and answers compared by the 'verification station' to make sure they agreed, and further checks done for those that didn't. Once a result was agreed upon, there was another sanity check on the maths itself using mod 9, mod 10 and mod 11 checks on the result (the mod squad), after which a calculation was finally accepted and sent to the 'archive' of verified calculations that would make up the final answer. Even then, the archive would do a final check between submitted answers, and random calculations were sent out by yet another squad (the 'phantom protocol'...) to be done yet again for additional verification.

And this was all needed - even with a lot of these verification steps already in place from the start, the error rate began at the start of the week around the 50 - 60% mark - that is, 50 - 60% of handed in sheets had at least 1 error on them that was found. The rest of the verification procedures and some other practices were brought in as a result and the error rate came down to 25%, which was a momentous achievement.

Once a given calculation was complete though, it went via the copier team, who would write out new worksheets for calculations to do based on the results of the verified originals - each calculation could generate 3 others, which could be done up to 5 times each, so this was not an easy job and had a lot of responsibility - you worked in pairs on the copier tables and checked each others work. I spent some time doing some copy work and it was very stressful. We had flow charts, multiple coloured pieces of paper signifying different parts of the calculation and other measures to make things as simple as possible, but there was still a lot resting on the copier's work - there was no real way to verify or detect errors that came from the copiers like there was for all the other roles. The maths could be perfect but you wouldn't get the right answer if told to do the wrong maths!

And now the bit that actually relates to work...

On Saturday, we worked as one big machine - the people doing the long division would queue up for work on one of 7 different parts of the calculation, and when work was available people would be called from the front of the queue and assigned the work, as well as a coloured lanyard specifying which of the 7 parts they were working on. They would then visit the times tables library to pick up the times table for whatever they were dividing by (out of around 75 different possible divisors), find a table space and do the calculation before checking it in at the check in desk, then going round the cycle again. Once a worksheet was submitted it could take several hours to work its way through the system and for the dependent calculations to be 'released' to the division team, as the repeat calculations needed to verify could be floating around the room, there could be a backlog at the mod squad, or the copiers might need more information to complete their task. The room was divided up by role - there were tables for the dividers, tables for the copiers, a dedicated check-in desk, desks for handing out each of the 7 parts of the calculation, desks for combining the results at the end etc.

On Sunday, in an attempt to stretch as far as possible for the last day, we changed approach and built much smaller round tables of cross functional teams experienced in each area - I was assigned to the table tackling the calculation with code name 'Monday' (there were 7 calculations... don't ask what the others were called!). There were 4 of us doing the division, 2 from the mod squad doing the sanity checks and comparisons between our results, and 2 copiers generating the next set of calculations to send back round.

The difference in efficiency could not have been more obvious - the cycle time went from several hours down to about 15 minutes - communication between the different functions was direct and immediate, feedback about errors came instantly and so could be watched out for in future iterations, work could be done as soon as it was available, and each of the functions got a short break while waiting for the other functions in the cycle to complete their task too, to allow some breathing room. I found I needed to relax my hand after a while - I'm not used to writing so much with pen and paper these days!

The disadvantage to this approach? Some of the extensive safety checks that were in place previously were no longer in place. This was an accepted risk as we had reached a good target 'MVP' previously and were now stretching to go as far as possible with this accepted risk. It also required a team of people already trained up in the different roles and who were able to work confidently in those roles without the same safety nets as before, so probably couldn't have worked at the start of the week. People trained up in several roles over the week and settled into the ones they enjoyed or were best placed by the end - I did some copying on the Saturday but very much enjoyed the long division.

The parallels to software development and Agile specifically could not have been more plain and obvious. Fast feedback, fail fast, cross-functional teams, regular communication, and working as a team that bonded really well. The additional risk this approach carried very much reminded me of Move fast and break things - a common adage in software. It doesn't mean that you make a mess and break everything, it's about taking on additional risk in order to deliver much more value for the client, while accepting that while you aren't trying to break anything or create issues, these become slightly more likely as a result - though not enough to outweigh the additional value gained. The approach was termed the 'Hail Mary' approach on the day, but I don't think this was entirely fair - it wasn't as dangerous as that name made it sound, it just carried a small amount of extra risk.

These similarities were spotted by many people on my team as we discussed how things were going (because of course there were loads of software developers there!), and the realisation was startling to me. Sometimes working on big projects can remove you slightly from the process, whatever that process is, so that you don't necessarily see the advantages so easily of working that way, but being so involved and close to it over the weekend made it blindingly obvious. Working in this 'agile' way was SO much more efficient than being a small cog in a huge lumbering machine that it was quite shocking, really made it sit well for me in my head.

When I turned up on Saturday morning at 9am I really wasn't sure what I had signed up for, or whether I'd feel out of place when I turned up, but I could not have had a better time with a greater bunch of people working towards a common goal (voluntarily, other than a free lunch!). I worked with people from the Netherlands, Germany, France, Scotland, the US and even further afield who had all come to help out do this for no other reason than the joy of being part of it.

How did we do in the end though? Did we manage to calculate Pi to any significant accuracy? Well, for that you'll have to wait for the video to come out on March 11th, in time for Pi day on March 14th. Follow the @standupmaths YouTube channel to see it!