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 four”, ”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 our approach be if our lives depended on it? How would we heed Mr. Santayana’s warning? Would we all be in it together?
The Challenge:
Imagine this Associate Press headline: First Team to ‘Barrel Drop’ Niagara Falls in Homemade Vessel Wins $1m. Maybe not even that far-fetched given the proclivities of today’s uber wealthy eccentric! We may also find stories of some of the early Niagara barrel drop pioneers. Both tragic and fascinating. But what might we learn from them. Do they apply to us? And do we really need to go all the way to Niagara Falls to get it?
In October 1829, Sam Patch, who called himself “the Yankee Leapster”, jumped from a high tower into the Niagara 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 were sprung from jail.
How dissimilar 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 team’s success? In both cases success depends largely on user and sponsor acceptance of the project deliverable. The aforementioned eccentric uber wealthy provocateur will only pay up if your team goes down together and is the first to successfully live to tell the story! 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 blame the History Channel!), 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.
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.
An “If your life depends upon it” approach:
If it is your team chasing the $1m, or even $3m 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 do something else?
My money, and life, is on an Open, Agile, ITIL, RUP Waterfall hybrid approach. So…this does sound like an attempt to string together as many buzz words as possible in an effort to sound clever. But…you maybe 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”.
This might not be a direct correlation to the open source movement, but it’s close. How many web applications are 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 a great deal. 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.
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 much darn 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 Deming.
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, 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) as no evidence to the contrary exists. But would you?
Let’s start with “Iteration 0”. This sprint is completely devoted to user experience. The point is to get out of habit of thinking of Java Beans and database schemas and start thinking about people. Here are tasks that need to be accomplished:
Subscribe via RSS