How do we avoid what philosopher George Santayana warned of when he said, "Those who cannot remember the past are condemned to repeat it”. Today's platforms, frameworks and methodologies all help us learn from the past, and can go a long way to help assure our optimum success, but what would your approach be if your life depended on it.? Should it, does it, differ from your current approach, and what about the rest of your team. Is everyone on board? Is there a shared vision?
Consider this...do the following kinds of statements mean the same thing to everyone involved in your projects?
“We're a RUP shop”, ”They are CMMI level three”, ”This is an ITIL project”, “Our team is Agile”, “This client RFP specifies a Waterfall approach”.
RUP is a process framework whose creators intended it to be extended and individualized. CMMI levels are attained with great effort, but there is no assurance that they are adhered to or even appropriate in each project. ITIL is a vast collection of codified practices across multiple disciplines. “Agile”can just mean “we're flexible” or it can suggest a strict adherence to SCRUM. A Waterfall approach, one iteration and you’re done. Really? You and your team are all in the same boat, but are you sure you are all on the same page?
Danger sharpens the senses. What would your teams approach be … if your lives depended on it? How would you heed Mr. Santayana's warning? Would you all be in it together?
The Challenge:
Imagine an AP headline reading, “First Three Teams of Five to ‘Barrel Drop’ Niagara Falls in a Single Home Made Vessel Win 1 Million Dollars Each”. Not completely unrealistic given the proclivities of the today's occasional uber wealthy eccentric, and you may find the stories of some of the early Niagara barrel drop pioneers both tragic and fascinating. But what might we learn from them, and how might they apply to us?
In October 1829, Sam Patch, who called himself “the Yankee Leapster”, jumped from a high tower into the gorge below the falls and survived; thus began a long tradition of daredevils trying to go over the Falls. On October 24, 1901, 63-year-old Michigan school teacher Annie Edson Taylor was the first person to go over the Falls in a barrel as a publicity stunt; she survived, bleeding, but virtually unharmed. Soon after exiting the barrel, she said, “No one ought ever do that again.”
Does Annie Taylor’s warning sound familiar? By the way, several later daredevils did not fare so well, and it wasn’t until 1989 that a team of two successfully made the plunge, and by successful I mean they lived to tell about it, once they paid their fines and where sprung from jail.
How dis-similar is this fictitious challenge to the last internal project or RFP your team agreed to take on, knowing full well of the perils that await you, and of the rule bending you might engage, in order to assure your teams’ success? In both cases success depends largely on user and sponsor acceptance of the project deliverable. The aforementioned eccentric billionaire will only pay up if your team goes down together. And remember, if you spend more than a million bucks, or other teams “barrel drop”, er,....go live first.... then your team’s prize is zero, not to mention the consequences of being first to deliver, but with a tragically flawed design. What approach would you take? Would you take lessons learned, and not learned, from Sam Patch, Annie Edson Taylor, and those who followed them over the waterfall.
As I studied the fate of many a Niagara daredevil I marveled at how dissimilar each of their designs were, and wonder how closely each of their approaches mimicked current software development methodologies. From pictures I studied of actual “barrels” used in both successful and unsuccessful attempts, it appears none of them borrowed or learned much from those before them.
In one tragic example, a daredevil attempted to repeat his successful Niagara plunge elsewhere, but he failed to adjust his requirements properly to the new environment.
On July 2, 1984, Canadian Karel Soucek from Hamilton, Ontario successfully plunged over the Horseshoe Falls in a barrel with only minor injuries. Soucek was fined $500 for performing the stunt without a license. In 1985, he was fatally injured while attempting to re-create the Niagara drop at the Houston Astrodome. His aim was to climb into a barrel hoisted to the rafters of the Astrodome and to drop 180 feet (55 m) into a water tank on the floor. After his barrel released prematurely, it hit the side of the tank and he died the next day from his injuries.
source: http://en.wikipedia.org/wiki/Niagra_Falls
source: http://www.bay-journal.com/bay/1he/people/fp-taylor-annie.html
I learned many of these daredevils had used the non-iterative one shot “waterfall approach” that Winston Royce first described and warned us about in a software development article he wrote in 1970. He neither endorsed nor named this approach, but only observed that it had become prevalent as software started being used by people other than those who had written it. Winston thought it was a bad idea, instead favoring an iterative approach, but waterfall non-the-less became the adopted standard of the United States Military, and later, the standard of Governments, consultancies, and companies throughout the world.
source: http://www.youtube.com/watch?v=X1c2--sP3o0
An “If your life depends upon it” approach:
If it is your team chasing the one million, or even three million dollars for doing the plunge three times in a row, would you use a pure waterfall approach to go over the waterfall, or would you gather all of the collective knowledge of your team and leverage a hybrid approach?
My money, and life, is on an Open, Agile, ITIL, RUP Waterfall hybrid approach. I grant that this does appear perhaps an attempt to string together as many buzz words as possible in an effort to sound cleaver, but I suggest you may be surprised to recognize that even if your most successful projects fall squarely in one camp, they do borrow from the rest, even waterfall.
Open: No romance for “not invented here, or by Microsoft, etc”. An open source approach frees a team to borrow well documented and rigorously tested code from the community and use it without the burden of procurement or finance. There is little or no hard cost to trying multiple options, and creating solutions using open source projects as tools and building blocks.
There are currently over 250,000 projects available on Sourceforge, complete with user generated reviews and adoption metrics giving the user helpful information about each project, and world class commercial support available for most enterprise offerings.
Similarly, there are numerous options for canisters [barrels] that could be dug out of salvage yards and re-purposed for the barrel drop “application”. How about old brewers casks or refinery tanks that could be fortified and made habitable. They are already built and readily available, I bet we could even get a bunch of specifications regarding strength and durability that would give us clues as to which is most suitable. Think “Junk Yard Wars”.
source: http://www.tv.com/junkyard-wars/show/6391/summary.html
Perhaps not a direct correlation to the open source movement, but close. How many web applications are there out there that are “pure Microsoft”, yet leverage the open source Hibernate project for persistence? Uh, pretty much all of them.
Agile: We could study the successes and failures of previous Niagara drops, treating those as initial iterations, and continuing with an iterative approach, tossing a few of our own iteratively developed designs over the Niagara after having equipped them with crash test dummies and sensors borrowed from nearby abandoned automotive plants. Unless it is a complete failure, our first prototype eventually becomes our production model, presumably with minor changes and additions in subsequent test iterations all the way up until “production”, and then perhaps even between drop [iteration] two and three.
This notion was first explained to me by an old friend and colleague, Jon Kern, who in 2001 co-authored the Agile Manifesto. He and that cadre have come a long way since, and we owe them much. Words to live and work by, and in this case, literally. Reprinted below verbatim.
We are uncovering better ways of developing software [barrels]by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software [barrels]over comprehensive documentation
Customer [inhabitant]collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
And regarding testing, and the Agile/”Extreme” notion of build the test before the code, well, Niagara Falls itself is the test, and it certainly is already built.
source: http://en.wikipedia.org/wiki/Test-driven_development
ITIL: The Information Technology Infrastructure Library delves into some pretty specific managed service delivery disciplines with a collection of well documented practices, but at its core it is a simple framework for producing repeatable results. ITIL prescribes an approach where one enters and addresses lowest hanging fruit in a continuous cycle of Strategy, Design, Transition, Operation, and Continuous Improvement.
Just makes too darn much sense not to use the ITIL foundational framework to approach this challenge. Keep in mind we are planning for a second and third drop. ITIL owes much to W. Edwards Dimming.
RUP: Rational Unified Process is an iterative process framework which supports a one size and shape does not fit all approach to process, but does provide a standardized language around which groups can define and communicate their approach. We owe the term “Use Cases” to my old boss, Ivar Jacobson, one of the “Three Amigos” of RUP. He once told me that he blamed the term on his poor English skills, stating that what he really meant to say was “usage” cases. Creating a shared understanding the desired usage of a deliverable is central to success in delivery, and is a central element of RUP, and if RUP is not “Agile”, it is certainly iterative, and with RUP, everyone agrees on what the definition of “is” is.
Waterfall: One shot at requirements analysis, design, implementation, testing (validation), integration, and maintenance? No thank you. But on the other hand, how much iteration is required? Seems in this case the requirements are fairly binary. A reasonably safe and reusable Niagara barrel suited for five occupants and built on a low budget. Hence the statement which I have heard often repeated has some validity here, “a waterfall approach is best in situations where the requirements are well defined and unlikely to change”.
We think Annie Taylor took a pure waterfall approach (pun unavoidable) no evidence to the contrary exists. But would you?
