Digitally Indigenous Content

Scrum and the Copernican Revolution, Parts III & IV Outline

Note from 2025: Embarrassingly, I never completed this 2009 blog series. I have, however, had people ask me how it ends! In that spirit, I’ve attached these “notes to myself”, also from 2009, for parts III & IV.

Does the Agile / Scrum software development paradigm encourage innovation, or discourage it? We continue to discuss this topic here in part III of our little fantasy. In part I and part II, we pretend that the idea that sparked the 16^th Century Copernican revolution in astronomy happened during the course of a Scrum-based effort to develop version 173.92.3 of the Earth-centric model of the universe that had been originally proposed in the 3^rd Century B.C. 

As we saw in part II, you as Scrum master of Nick Copernicus’ Scrum team have become a believer in Nick’s proposed “Sun-centered” or “Heliocentric” architecture. However, using some introspection you have also come to realize that from the Product Owner’s point of view there are risks both in adopting it, and also in not adopting it. This is the age-old innovator’s dilemma—when to stick with something proven, and when to consider abandoning it for something potentially better.  There is no ready-made answer to this question, and the stakes are very high either way. 

Note that from our perspective here in the 21^st Century the choice may appear obvious. However, try to put yourself in the mindset of people who have had a great deal of success in predicting the motion of the heavenly bodies using an Earth-centered approach for almost 2,000 years. The approach has been highly successful and, undoubtedly, become very comfortable and familiar to successive generations of developers and managers who grew up with the system. The criteria for success are clear. It is very disturbing to have our fundamental assumptions questioned, especially when they seem to be working for us. Yet this is how innovation happens—it invariably takes us out of our comfort zone. The real question is—when is it worth it?

You and Nick have resolved to go back to the Product Owner and try again to sell him on the idea of a radical refactoring of the architecture, moving from the current model where @@@

Before you speak with the Product Owner, you and Nick will discuss your proposal with the whole Scrum team at today’s stand-up meeting. They are, of course, aware of the general ideas and status since you and Nick have been raising it as one of your “what I did today” items ever since the idea first came up. The team has been generally neutral to positive on the approach, with only one descenter—a curmedeonly senior developer—but until now you have not asked the team to commit one way or the other. Last night before you and Nick left the office, you posted a notice to the team to expect an extended standup—45 minutes rather than the usual 15 or so—where you will ask for their buy-in.

==========================================

Decision: leave one of the more accurate planets “as is” and shift resources onto a tiger team to develop a prototype of Nick’s model. Work goes on in parallel, and you will demo both heliocentric and geocentric models to the King—if it looks like he’s in a good mood.

==================================

Part III

King gives the go to try the new heliocentric model after seeing the spike. You tell him it’s less observationally accurate. Product owner jumps in and says to start putting epicycles on the circular orbits. 

King rewards everyone on your team—and the PO—with a house.

Part IV

Eliptical orbits. It’s several generations later, and the scrum master’s family still lives in the same house. Family lore tells you your grandparent was scrum master on the project that originally developed the heliocentric model. You are now using techniques of test driven development and a “fail fast” approach. Ty Brahe is the test lead; John Kepler is a software engineer who has idea about elliptical orbits.

If you choose not to refactor, then you run the risk of your competition (other Monarch’s sphere development teams) doing it first, and your Monarch coming to you and saying “why didn’t you guys think of this?”!

Fail fast—elliptical orbits

There are a couple of questions to ask yourself first, however:

1. Will the refactored architecture help to meet my business requirements?
2. Do I have the right business requirements?

In the case of Mr. Copernicus, however, this would have resulted in problems down the line—because his original model was less accurate than the epicycle-centric approach it replaced. It was not until Kepler and Galileo developed the concept of planets moving in elliptical rather than circular orbits that the Copernican model became truly accurate.

 So let’s examine a couple of options:

1. Let’s assume we have great automated test coverage against well-defined interfaces on top of a well-encapsulated architecture.  This would allow us to do a “spike” which re-factors the architecture while continuing to be able to test it via the same API’s with our existing test suite. Such a spike could become a story in the next sprint, with its priority driven according to business requirements. In the astronomical case, the test suite would consist of observational data for the positions of the planets, and the interfaces would allow selection of a particular date and time. Automation was not available in Copernicus’ day and in practice test execution speed would depend on the number of monks and other workers who could be enlisted for the task of computation using the new system, and comparison to the published observations.
2. Let’s assume that the architecture is “tightly coupled” to the 

Credits and references

To see how both models explain the retrograde motion of the planets, see the animation at http://www.sciences.univ-nantes.fr/physique/perso/cortial/bibliohtml/epiclc_ja.html and http://alpha.lasalle.edu/~smithsc/Astronomy/retrograd.html.

Photo of planetary motion from http://antwrp.gsfc.nasa.gov/apod/image/0312/retrogrademars03_tezel.jpg

Kepler planetary data tables from 

http://www.hps.cam.ac.uk/starry/tables.html

Images from wikimedia.org