Agile is associated with speed. The promise of Agile is working code faster, but how does this happen in practice? Though practices like Test-driven Development (TDD,) Continuous Integration (CI) and Continuous Deployment (CD.)
These are easier to understand when you see them in action, so imagine you’re standing over the shoulder of a web programmer, who’s building blog software. They start by writing the “write blog post” screen, and then they load up their browser to see it. Something’s not quite right, the post button is in the wrong place. So they go back to their HTML editor, make a fix, then check the browser again, hitting the refresh button. Ah, that’s better. Now they go back to their HTML editor and add some PHP code so it connects to the database and saves the post. They go back to their browser, try it, then they check the database to see if the blog post really got stored. Nope, it missed some data. So back to the PHP code to find the bug… and this back and forth continues until that screen works properly.
If you’re lost by this example, there’s an analog. Imagine writing a long document, but whenever you want to re-read anything you just typed, you’ve got to print it. That’s a lot of waiting for the printer. Same thing with coding.
It’s like writing a document with the proof-reader standing over your shoulder giving instant feedback when you need it.
Instead of manually testing on the staging server, we can automatically release code that passes all of our prior tests. This is called Continuous Integration. For example, if our blog programmer starts writing a complicated new feature but accidentally breaks old functionality, the old traffic light will turn red and point it out to them right away. Since they know they just created the bug, they know where it is and can address it quickly. If it were later caught on a staging server, it wouldn’t be fresh in the programmer’s mind so it would take a lot of time finding the bug.
I’m on the Kernel Stewards team, where we help ~2,000 fellows understand the what the development of blockchains mean to humanity on anthropological scales. I’m particularly interested in enabling fellows to build things with blockchains that are altruistic and prudent.
I’m also building a communication tool for community groups and unconferences. It focuses on autonomising teams rather than “coordinating”.
In the past, I've designed peer-learning programs for Oxford, UCL, Techstars, Microsoft Ventures and The Royal Academy Of Engineering, careering from startups to humanitech and engineering. I also played a role in the Lean Startup methodology, and the European startup ecosystem. You can read about this here.
Menus and kitchens (2023)
Retreats for remote teams (2023)
What do you need right now? (2023)
Making sense of DAOs (2022)
Choose happiness (2021)
Emotional Vocabulary (2020)
Project portfolios (2020)
The history Of Lean Startup (2016)
Entrepreneurship is craft (2014)