It’s hard to overstate Benjamin Franklin’s contributions to the world. A true polymath, Franklin is best known for his statesmanship and diplomacy, his scientific insight, and his creation of the Scrum software development methodology.
Okay, Franklin was ahead of his time, but he wasn’t telling us how to build software more than 200 years ago. Yet like the founders of Scrum, Franklin was obsessed with finding better ways to work and shared his productivity strategy in his autobiography. It’s one of the first to-do lists in the historical record, but it anticipates Scrum – and Agile development in general – in many ways.
Planning and prioritization
Each morning, Franklin set aside time to, as he put it, “contrive [the] day’s business, and take resolution of the day.” That meant deciding on his priorities and which ones he could reasonably expect to accomplish. He’d commit to this list by writing it in a notebook he carried with him everywhere, in a section headed “What good shall I do this day?” Scrum masters should recognize this – Franklin was holding his own planning meeting to build a personal sprint backlog!
Timeboxing and sustainable pace
Franklin lived by a schedule. He woke up at 5 a.m. and went to bed at 10 p.m. every day. Work began at 8 o’clock and ended promptly at 6. If he hadn’t quite completed an item on his to-do list by then, it didn’t get done – he didn’t throw a good time after bad by working late. He also built slack time into his day for things like reading, tidying up, and “music or diversion.” Franklin wrote that this was in pursuit of order: allowing time for “each part of your business.” But Agilists today might recognize these techniques in their own pursuit of a sustainable pace.
Reviews and flexibility
When his working hours were over, Franklin set aside time for what he called an “examination of the day.” He considered the evening question, “What good have I done to-day,” and recorded these accomplishments in his notebook. Note that he didn’t simply cross off completed items. By writing out a separate list, Franklin acknowledged that priorities change, and could compare his goals to his actual achievements. Like a team developing software in a changing market, Franklin found that he “must mix with the world,” making strict adherence to a plan impossible. Instead, he focused on the bigger picture.
Retrospective and continuous improvement
Before he created this productivity strategy, Franklin compiled a list of 13 virtues that he felt it was important to live by. In each evening’s examination, he’d consider whether he had failed to observe any of them, and record these transgressions in his notebook as well. He hoped to live in harmony with them all, but a disastrous first attempt proved he couldn’t change all at once. Instead, he chose the most important – temperance, in his view – and focused on that, only proceeding when he “suppos’d the habit of that virtue so much strengthen’d, and its opposite weaken’d, that I might venture extending my attention to include the next.” This deliberate striving for betterment, rather than perfection, is the core of continuous improvement.
Granted, Franklin’s strategy would be incomplete for a software development project. For instance, it doesn’t address backlog grooming (Franklin chalks this up to his “exceeding good memory”) and seems ill-suited for working as part of a team. Plus, I doubt the man could clone a Git repo to save his life. But Franklin accomplished a great deal in his life using these techniques. Scrum may be only a few decades old, but the ideas underpinning it have been tested for centuries.