War rooms and Serendipity
Most of us have had experience somewhere in student or professional lives with having to hit an important deadline. When fear of the deadline loomed, we often began circling the wagons with our collaborators to shorten communication cycles and cross-check each other’s work. A “war-room” environment where everyone is within eyeshot and earshot of one another, sustains momentum, minimizes “stuck” time, and creates a general esprit de corps that holds up well during the high tension times of tight deliverables.
A secondary and potentially more powerful effect of this type of work environment is the effect of serendipity. The effect of overhearing the ideas of others and using that as a spur for innovation cannot be underestimated. As William Pretzer, author of Working at Inventing (2001) describes Thomas Edison’s Menlo Park, NJ. lab:
“Far from being the sedate intellectual environment characterized by library quiet, Edison’s labs were noisy, crowded places that often seemed on the point of uproar.” (p. 56)
Suggested Read: Agile project management
Co-located Cross-Functional Teams
The power of having everyone work in the same room can be enhanced further if various project team roles co-locate. For example imagine the software team where the project manager, the software developers, the business analysts, and the quality assurance team are all housed within eyeshot and earshot. Suddenly, working out problems that previously required lengthy, drawn-out meetings are now being solved using “voice technology”. The amount of intra-team emails drops dramatically and the consequent productivity gain is realized, thereby further sustaining innovation momentum.
Quick standup meetings can be used to keep everyone up-to-date with one another. Simple “call outs,” where team members indicate what they’ve recently completed, what they are currently working on, and where they need help (if any) can be a very powerful “catch basin” for problems not being solved through serendipity. These meetings should be short (less than 15 minutes) and should not attempt to solve problems, but rather identify problems and request help. Small gatherings around point problems after the meeting are where the solutions should be sought. This gets the right people together without trapping non-contributors in lengthy boring meetings that breed disengagement and depletes morale and energy.
Visualization through Wallboard Displays
Having work plans and project artifacts pinned to a wall where everyone can see them supports a much more effective communication system that keeps all team members on the same page. While shared-drives and intranets have their place in maintaining project artifacts, the principle of “out of sight, out of mind” is at hard at work in deadline-driven environments. These wallboard displays create an opportunity for rich visualization that is often lost in the simple 2-D world of 19-inch liquid-crystal displays (LCD) and intranets.
“Make Mistakes Faster” Attitude
The idea of embracing making mistakes is one of the more difficult aspects of agile. We have been conditioned from grade school through college to avoid making mistakes or else we’ll get bad grades, which then translate into fewer opportunities. Societal and cultural norms are also a powerful force in this behavioral debate. Let us simply accept that if we spend all of our time avoiding making any mistakes, we would never get anything done. Thus, we know we will make mistakes. If we condition ourselves to make mistakes faster, we can correct them while they are still small and while there is still time and budget remaining to do something about the mistakes.
Many IT projects fail because they turn out to be one gigantic, slow mistake. Once we discover that a technology choice won’t work, a planned implementation will not succeed, or that a user community will not adopt a solution, the budget and time are usually gone. By using an iterative and incremental approach to software projects, we provide ample opportunities to check our work along the way and make critical adjustments.
An important qualification to this “tool” is that we MUST distinguish between the value of iterative and the danger in releasing too many completed versions to an unsuspecting user community. The value of a short iteration is found in the ability of the business sponsors to validate and adjust plans while they see the software coming to life. It then becomes an important business decision as to which of these increments are released to end-user community.
Management’s behavior will be a large determining factor whether this tool can be successfully used. If management’s rhetoric is “embrace change! Make mistake faster!” but management’s behavior is to express profound disappointment every time a little mistake is displayed, this tool will be abandoned by the team, and progress will slow immensely. The opportunity for innovation will then be lost.
High Sponsor Engagement
According to the Standish Group, loss of “executive management sponsorship” is one of the most common reasons for IT project failures (1995). The questions arise: “What tools can we use to increase sponsor engagement throughout the project? How could this work for large, lengthy projects?”
We must first recognize that sponsors of technical projects are seeking a business goal, not a technical one. We therefore must learn to bridge the communication divide between geek-speak and business-jargon. An iterative and incremental approach where sponsors regularly see and touch tangible progress is far superior to status reports, Gantt charts, budget reports, and focus-group study reports.
Also Read: Agile and SAAS
We must also find a way to engage sponsors in the planning process and thus must present them with understandable alternatives in the form of competing features as different price points. (To use a housing analogy: A three-car garage at $75,000 vs. a carport at $5,000). Too often, techno-babble filled, inflexible plans are presented to sponsors with only two choices: Yes or no. “No,” eventually becomes the most reasonable answer, especially if original estimates were low (which they usually are) and now time and budget pressures are all the executives can comprehend from otherwise incomprehensible status reports that usually translate to, “We’re really close,” and “We’ve been really close for several months now.”
Weekly or biweekly planning games, “show and tells,” wallboard displays of progress, and the palpable excitement of an energized team can create opportunities for high-engagement of sponsors, even when things don’t go exactly as planned. When “bumps in the night” occur, the sponsor feels like an empowered member of the team who rolls up their sleeves and helps find the solution rather than be overwhelmed by the problem.
Permission to Build a Learning Organization
“In the long run, the only sustainable source of competitive advantage is your organization’s ability to learn faster than the competition.” – Peter Senge, (1990, book flap)
One of the key challenges of innovation projects is that we are working in markets and technologies that no one fully understands and thus confounds standard human resource practices of hiring people with just the right skills to meet the needs of the projects. With innovation projects we must be learning constantly, but we still must get work done. Most organizations run cross-training and mentoring programs in fits and starts, and organizational learning initiatives often stall as soon as the budget axe swings. Yet, without learning, innovation will not occur.
Is there a way to build learning into the system? During the last 10years, I have discovered the most powerful managerial tool I have ever been privileged to use. It is a simple concept to describe: We pair our team members to work on the same task at the same time, and we switch the pairs every week. To use a nuclear energy term: It is organizational cold fusion. I get learning, cross training, and mentoring every moment of every day while getting the project work done. Quality skyrockets, productivity goes through the roof, and team members are energized. On boarding of a new person takes five minutes, and project teams can be scaled up and scaled down to meet work demands on a week-by-week basis.
The great managerial benefit is that I am no longer constrained by the traditional “tower of knowledge” problem of having only one person on the team who understands a particular aspect of the system, who then becomes the bottleneck for the project.
As the chief executive officer (CEO), I am able to give the team permission to build such a learning organization. Without my explicit and enthusiastic support, the team would only be able to steal time for learning while no one is watching.
Also Read: Agile planning process and methods
Many technical teams will schedule hours-long meetings to discuss and debate a particular approach, analyzing the merits and costs, arguing the efficacy and alternatives, considering the risks and the unknowns. It is often the case that a half-hour experiment could answer most of the same questions and eliminate most of the risks of the unknown. Often the answer found as the result of the experiment, defied the expectations of the experts.
Establishing a culture that regularly declares, “We don’t know, let’s run the experiment,” will produce far more innovations faster than one that says, “We’re not sure, let’s schedule a meeting next week to discuss it with the whole team.” A culture of experimentation will always outperform a “meeting culture”.