Tuesday, April 21, 2009
There are two modes of operation in an organization, Open and Closed. The Open mode is essential for creativity. It invites thought, relaxed contemplation, and examination of ideas. The Closed mode is fine once you have solved your problem and have chosen a course of action: without the Closed mode nothing would get done. But an organization that stays in the Closed mode will fail to improve and will miss creative solutions to its problems. Using games captures two of the five essential elements of creativity: Confidence/Permission, and Humor.
Confidence/Permission: Criticism is not allowed in creative sessions. Allow all ideas to be put into play. Allow junior members to speak first, and don't allow senior member to ridicule them. People must feel they can take chances with incomplete or unreferenced thought. As ideas are tossed around, allow the ccasional illogical transition. This is often the key step to a new view of the problem and a better solution.
Humor: Humor is an essential part of creativity. A main element of humor is the unexpected connection of two unrelated concepts. This is also a key element of creativity. Enabling humor starts the brain's analogizing mechanism.
Often organizations try to eliminate humor because they feel it detracts from proper decorum, denigrates those in charge and leads to insubordination. This attitude comes from a confusion between "serious" and "solemn". It is possible to be serious about something and still maintain a sense of humor about it. And if you desire creative solutions, you MUST maintain a sense of humor. Organizations that insist on solemnity will forbid humor in all forms, keep in the Closed mode, and outlaw creativity. What you will find in these organizations is that people's natural humor and creativity, channeled away from the business process, will leak out in underground ways --- usually in jokes directed at the organization's management.
Friday, April 17, 2009
Recently I had a chance to go through certification in facilitating Innovation Games. Innovation Games are a set of 12 facilitated collaborative activities designed to help identify customer needs, define requirements, understand product/service usage, and design future products and services.
The different activities, or "games" address different aspects of the creative process: generating ideas, sorting ideas, prioritizing ideas, and pruning ideas.
As important as the activities themselves are, are the processes behind them: determining which activity (or set of activity) to conduct, how to prepare, how to monitor, how to organize, how to complete and how to extract maximum value.
The games can be used across strategic, tactical and operational horizons.
Why games? More on that later.
Wednesday, April 15, 2009
John Cleese (yes that John Cleese) tells the story of his "favorite childhood superhero, Gordon the Guided Missle". In each episode, Gordon would be given a task. Setting out to accomplish this task, he would be constantly told how he was wrong: too low, too high, target to the left, target to the right, etc. He was always wrong. Always mistaken. However, he never despaired, and grew more confident with every correction. Finally, at the end of every episode he would reach his target successfully, and everyone was happy.
The lesson Cleese wants you to take is that it was because Gordon was willing to be "continually" wrong that he was ultimately successful. Gordon's "Process for Success" depended on feedback. It depended on "tracking the moving target" by constantly changing his direction. Viewed from the larger perspective, Gordon's ability to consistently deliver successful results was more stable because he included feedback and a willingness to admit mistakes. Even more so, an eagerness to make as many small mistakes as quickly as possible before they became big mistakes.
The theory behind system stability from feedback goes back to Von Neumann's Cybernetics and the original work on System Theory. Systems that can flex are inherently better than those that are rigid. You can see this in everything from ancient Japanese earthquake-resistant buildings to metabolic mechanisms to eco-systems to market economies.
Why should an endeavor as complicated as buiding software be any different?
You know you are going to get feedback. Do you unit test? Of course. Why? To feedback the test results into better code. Does your team do regular system builds? Pre-production tests? Beta releases? Customer-reviewed prototypes? Feedback, feedback, feedback, feedback.
Grab hold of this live wire. Consciously use this power.
But this can be scary. What keeps you from being electrocuted instead? What about the "feedback" when you put the microphone in front of the speaker? Tulip-mania and the dot-com bubble? Haven't you seen the Tacoma Narrows Bridge video (http://www.civeng.carleton.ca/Exhibits/Tacoma_Narrows/)?
Won't constant feedback, from customers or users, just as easily lead to cost overruns? Drive the project "into the ditch"? Everytime I talk to customers they add more features! And we have a fixed-price contract for a specific deliverable!
As with any tool, feedback can burn your hand or cook your dinner. Software development must use controlled feedback. It will depend on being explicit about the why's and what kinds of feedback you solicit.
As I hear the doubts ("so, how do I control this feedback?") I ask you to consider the following "homework" question: What keeps your unit testing from eventually generating an infinite number of bugs? Why doesn't each "fix" create even more bugs?
John Cleese' quotes from his speech on "The Importance of Mistakes"; any errors or misinterpretations are mine.
Padulo and Arbib's "System Theory" was my basic text on linear system theory.
Tuesday, April 14, 2009
That's ridiculous, everyone said, because the whole machine would completely bog down when those checks were made. The project was scrapped.
Flash forward to computing power that makes such spell and grammar checks trivial. This is the sort of exponential change that people like Ray Kurzweil talk about.
Personally I don't think AI will get to the point of "real" intelligence (whatever that is), but will be able to quite convincingly fake it.
And, if instead of refrigerator-sized Lisp Machines we can house the software in machines that look like Tricia Helfer or Summer Glau, count me in.
Monday, April 13, 2009
There are still organizations that claim they do not use an iterative development process. Why is that? Wasn't this argument settled long ago?
The so-called non-iterative methods, such as waterfall, are most often used in organizations where the dominating culture is that of Mistake-Avoidance. This can come from a number of sources: don't waste the taxpayer's money, we can't tell the business people we made a mistake, or simply management that has never developed software using modern IDE's.
Non-iterative methods are used even in organizations that do not manage by fear. In talking to the IT department of a southeast asian central bank, I discovered they were happy and well adjusted, but insisted they did not use iteration. Projects lasted between 9 to 36 months. Delving deeper, it turned out that, yes, once fielded they did get feedback from users of changes, fixes, and enhancements, and yes, they collected those over a period of 6 or so months, at which point they would often start a new version of the application. My claim was that their iterations were just very, very, long.
Short iterations (e.g., daily) are empowered by modern IDE's. Iterative developement is essential for delivery of effective software. Management's avoidance of iteration centers around a fear of chaos and loss of control. "How do you know you are done?", "How do you budget and staff the project?", etc.
The analogy I like to use is that of the Sailboat and the Locomotive. Iterative development is captaining a sailboat---a method designed to handle changes in wind direction, currents, crew, revised destination, etc. Non-iterative development is a locomotive, meant to be predictable and repeatable. It is possible that in a restricted domain and problem space that software development could be organized to run like a train schedule. Beware if there is ever a bridge out, though.
Software professionals need to think, plan, act and manage more as sailors than conductors.