Agility is the ability to learn and adapt rapidly.
The principles that I try to apply to a lot of situations embody what I believe the original intent1 of the Agile manifesto is. They’re widely applicable to most types of projects and I ascribe them to just “getting things done”. These principles are:
- Stay curious for longer.
- Get Started Faster.
- Be Aggressively Lean
- Make time immutable.
- Do it once, then do it better. Iterate.
- Embrace Conway’s law.
Stay Curious for longer.
I’ve posted before about my curiosity and in this context it’s no different. Approach your project as an opportunity to learn new things, not just build things. Validate your assumptions. Explore more.. Engage your stakeholders to learn from them.
If you can manage to ask questions for 5 minutes longer than you normally do before diving into solutions, you’ll be in a much better position to be successful at whatever you’re doing.
Get Started Faster.
Start right away with a proof of concept and don’t wait for design to be done. Your design can evolve from the proof of concept.
Make decisions faster by taking smaller risks and being prepared to take different directions if it doesn’t work out. Be bold and move forward, one step at a time.
Be Aggressively Lean.
Don’t introduce complexities earlier than they are needed. Fight for simplicity and do the minimum possible to meet your needs at that point in time. This isn’t laziness, this is limiting your investment in case you need to pivot and maintaining your agility.
You don’t need an N-tier architecture in your codebase for the first few iterations. Continuously refactor patterns in as needed - don’t start with them.
Make Time Immutable
Don’t ask “When will X be done?", instead ask “How much can you do by Friday?". Time is our only immutable constraint, so be flexible on scope and quality instead. By making time a requirement instead of an outcome, lots of good habits start to fall into place.
With an immutable deadline, people focus on what’s important. There’s less bikeshedding, lean approaches start to become the norm, and the most important & valuable features naturally bubble to the top while the least important ones fall out into the next iteration. Dependencies and blockers are tackled or mitigated faster.
Do it once, then do it better. Iterate.
To compliment making time immutable, commit to at least three iterations. Every iteration, even the final one, is a proof-of-concept. Each iteration just gets a little step better than the previous one in terms of quality and scope.
Make every iteration as short as possible so there will be time for the following iteration.
Embrace Conway’s Law
Conway’s Law is an adage that states your system design will follow your organizational design. This means your codebase will have all the flaws and drawbacks that you experience in your cross-team dependencies and priority management.
Invert Conway’s law and make it work for you. Design and assign your teams according to good distributed system design principles. Minimize dependencies, allow different parts to scale independently, build for resiliency and robustness. Measure and eliminate frictions between different parts. Observe how the overall system performs.
-
Intent being the operative word here. Many implementations of agile have gone wrong over the decades because they valued process over individuals and interactions. This post focuses on the behaviour of individuals and the actions that come from that. ↩︎