Non-Traditional Project Planning

Most methodology discussions today start and end with how Agile is superior to Waterfall in software engineering; in reality, many other methodologies exist, each with its own pros and cons. Leadership, enamored with being agile, insist on Agile – or at least the perception of – even when another methodology is more appropriate for the project, team, business domain, customer, whatever.

I view the bigger problem as methodology for methodology’s sake: application without understanding, execution without adaptation. Thou shall do X as defined by said methodology, and so you shall regardless of lack of perceived benefits.

A previous employer created a template to calculate planned hours for the project stages – design, implementation, testing, integration, deployment, documentation, etc. – based supporting values provided. My project was already implementing before planning was completed – yes, I know – but the project manager insisted on completing the template. Unfortunately, the planned hours generated were different with actuals for completed tasks, sometimes substantially. The Project Manager had no discretion to deviate and stipulated that planned hours were correct despite our protestations. Subsequently, the team ignored the plan and just completed the work.

This story and a recent visit to a museum (really!) had me considering other ways I’ve seen or heard of projects being managed.

Prime Numbers

Please bear with me – especially those who don’t understand baseball – it’ll tie together by the end!!

Love is perhaps too strong, but I strongly prefer prime numbers: not the million-digit primes generated by computers, but the more pedestrian, under-100 primes. Thank you APBA Baseball.

Background

APBA Baseball is a baseball simulation game where each player has a card representing his season: mainly batting, but also pitching and fielding. The “manager” of the player “batting” rolls dice which is looked up on the player’s card, mapping to a value between 1 and 42. That value is cross-referenced on a “game board” for the current situation – i.e., bases empty, runner on first, runners on first and third, etc. – to determine the final outcome of the “at bat”, which may also take into account pitcher quality and team fielding.

[NOTE: This is the basic or original version, the Master Game applies even more variables to the outcome.]

My father passed is love of APBA to me, and I created season schedules to play out over weekends and school breaks. The games’ scorecards – unreadable to anyone but me – were used to calculate season stats. Obsessive, yes, but digital gaming was in its infancy, and I couldn’t play Dungeons and Dragons alone.

Some values appear often and are fairly well-known – 1=home run, 13=strike-out, 32=fly-out. Others are more rare and provided unusual outcomes, of which 23 (a prime!) provides the most fun:

Runner on First: Runner out stealing and ejected from game for disputing umpire’s decision.
Runner on Third: SINGLE – pop fly falls, runner scores, 2nd baseman and right fielder collide and one is injured; right fielder is unable to play next three games.
Runners on Second and Third: Triple Play.

Games could even be “rained out”! And hence begat my preference for prime numbers.

Project Estimates Using Prime Numbers

In 2000, I joined a team implementing their company’s first web application to replace the PowerBuilder version which was costly to deploy/maintain/support across their international offices.

After refining the architecture and implementing the supporting framework, the team needed to estimate the effort to deliver a first release. We identified all web pages to implement and each became a task – stories in Agile vernacular – to estimate and prioritize.

Initially, each task was categorized as low/medium/high effort but what does that mean? I proposed assigning number of days to complete (story-pointing) and – sticking with primes numbers – suggested 1 day=low, 3=medium, 7=high.

[Yes, 5 is a prime number, but the high-effort tasks seemed substantially more than medium so we jumped to 7.]

The outcome: the most successful project planning I’ve ever been associated with. All but 1 task completed (reasonably) within the estimate assigned; the one outlier was immediately obvious and started early to minimize the impact.

I’ve also used (pushed) primes for other estimates: story points (where fibonacci numbers weren’t appropriate), sprint planning time reserved for unstructured work (support) as hours or percentage, etc.

Physical, Not Virtual

My wife and I recently saw an exhibit about the making of Guillermo del Toro‘s movie Pinocchio at the Portland Art Museum (through September 17, 2023). The movie is stop-motion, each frame an individual shot (think camera) of one or more models, with manual position changes between each shot appears as fluid movement when shown in sequence. The completed animation appears computer-generated when in fact it isn’t.

I was most fascinated by the videos of the animators working: position the model, take a picture, repeat ad nauseam. Some scenes took days to complete, indicated by animators’ clothes changing day-by-day.

[My grandfather somehow did his own using a 16mm movie camera, crude but effective.]

Post-Its and Rubber Bands

Not quite a story board, not quite a Gantt Chart, not quite a scrum-of-scrums, but easy to understand and easy as new info affects current state.

Production on Guillermo del Toro’s Pinocchio did not slow down during the pandemic. Crew members transformed their homes into workshops and continue look development and prop- and set-making on their own, communicating through virtual check-ins and digital schedules. Once the entire crew assembled in person, physical scheduling boards were created using a system that tracks each shot for every animation unit. Individual units are represented horizontally, weeks are pictured vertically, and rubber bands track animators’ progress. This board, which is one of dozens, was more than just a schedule; it created a physical space where crew members could gather to communicate, make decisions, and look ahead.

I particularly love the rubber bands, which seem to indicate dependencies between teams (and probably conveys other information as well).

Regardless of its daily use, the board facilitates work without injecting much bureaucracy: no context switching to update MS Project, Jira or spreadsheets. The simplicity is enticing.

Get-Outta-My-Way

A.K.A. less planning, more doing.

Have you ever been on a project where the bureaucracy – project planning, task management, status updates, dependency tracking, required meetings, etc. – hinders rather than enables delivery, risking the agreed-upon release date? Where the methodology states it improves overall engineering but engineers see no tangible benefit?

I have, multiple shops, multiple projects, both pre-Agile and Agile.

These projects reach a breaking point where they have no choice but to move into (what I call) the Code MF phase: heads-down development, bureaucracy be damned. The lead and senior engineers have the overall vision, they ensure interlocking puzzle pieces, they course-correct when needed, they actively communicate with the team, the remove roadblocks. Everyone focuses on writing code and getting solution out-the-door. Isn’t this why we became software engineers in the first place?

Does it work? Yes, more often than leadership will admit. Does it scale? Only if team sizes are reasonable, a la Amazon’s Two-Pizza Teams. The team needs to be mature, with the right combination of skills/experience, technology background, etc. But does it really work? Yes.

Conclusion

As long as software engineering remains an art and not a science, the question How should I approach planning this project? remains somewhat unanswerable as every shop, team, problem domain, tech stack, industry compliance, etc. are different. There is no singular answer whether Agile, Waterfall, 42, etc.: each can be both right and wrong, it all depends on the specific situation.

My recommendation is to objectively evaluate what your organization does and identify where small, incremental changes can benefit the teams. It’s unlikely your organization’s core methodology can be changed without a lot of discussion, but in the meantime perhaps you can make life better for yourself and fellow engineers.