Fairly Good Practices from the Agile community (of which the design and management communities can learn a lot).
Category: Process
-
Product development workshop this October in NY
I’ll be giving a workshop at the New Challenges retreat in New York in October. I’m still massaging the format, but I want to workshop a situation where designers must use their creativity and design skills to simultaneously develop a product and its revenue source. Pencil in one hand, spreadsheet in the other.
-
Lance Armstrong’s giant heart
It turns out that intense, long-term cardio training actually enlarges the heart and therefore the amount of oxygen-rich blood that can be delivered to the muscles, according to this long-term study at the University of Texas…Lance Armstrong…improved his cycling efficiency by a phenomenal 8% as he matured from age 21-28 years… There is no doubt that Lance now possesses a big and strong heart that can beat over 200 times a minute at maximum and thus pump a exceptionally large volume of blood and oxygen to his legs. There are probably 100 other men on earth who have comparable abilities while each assumedly must have performed intense endurance training for at least 3 years and are now between the ages of 18-40 y. In testing hundreds of competitive cyclists over 20 years at UT, Dr. Coyle has found two other individuals with the physiological potential of Lance.
An additional factor in Lance’s improvement over the years is that he has learned how to reduce his body weight and body fat by 10 pounds (5 kg) prior to each of his victories in the Tour de France. Therefore, over all his power per kg of body weight has increased 18% while climbing-up the steep mountains in France.
There’s definitely a metaphor here for business, as companies that excel over time consistently apply themselves to excellence until it is rooted in their culture and not just the occassional project success.
-
The Agile Project Leadership Network
I’ve found the Agile Development community has a lot in common with the user-centered design community, and their methods — especially the spirit of them — is closely aligned. In case you haven’t been following their evolution, many different methods from Scrum to Extreme Programming sprang up and, seeing commonalities among them, the founders came together to write the Agile Manifesto and form the Agile Alliance. Soon project managers caught the bug, adopted the practics and just recently formed the The Agile Project Leadership Network (APLN) which incidentally is structured much like the Information Architecture Institute.
The APLN’s core principles reaffirm the human-centeredness and agility of their predecessors:
In order to consistently deliver successful results, great project leaders embrace the following practices:
- Relentlessly Focus on Value. Focus efforts on generating organizational value rather than managing tasks.
- Be Situational Specific. Use situationally specific strategies, not a one-size-fits-all approach.
- Manage Uncertainty. Manage uncertainty through client focused collaborative exploration and proaction.
- Continuously Align to Changing Situations. Choose strategies for leading within a dynamic environment.
- Lead with Courage. Confront reality with conviction and a dedication to purpose.
- Build Strategies that Leverage People. Challenge team members with opportunities to grow professionally.
- Design Strategies Based on Teamwork. Devlop and sustain a collaborative team environment.
- Communication Through Immediate and Direct Feedback. Maintain control through feedback, not prescriptive plans.
-
Engineering-Design love-in
In GM’s Design Push Picks Up Speed David Welch profiles Bob Lutz’s struggle to balance the priorities of accounting, engineering and design in an enterprise. This bit pressed the clutch down in my brain:
One of the first things Lutz did on arriving in September, 2001, was push designers and engineers to stop fighting and start collaborating. Now, when the two sides butt heads, they get together in weekly meetings to hammer out their differences. “It isn’t a love-in,” says chief designer Ed Welburn. “But in the last two or three years the laws of physics have changed.”
Now I realize this is a huge company, and the projects run for years, but we all know from having done this work that once-a-week meetings doesn’t count as teamwork. At the Skunkworks for example draftsmen and engineers worked in ajoining rooms, close enough to shoot rubber bands at each other. This helps people generate ideas and sort out issues while in the synthesis frame of mind, rather than the review frame of mind. Hopefully GM’s weekly meetings are a step towards richer interaction.
-
Kelly Johnson’s Rules for Skunk Works
I’m doing research on high-performance teams that can evolve how they work to changing environments. I see it in the best designers, agile programmers, engineers and others. And I’m not too surprised to see it in Skunk Works, a book about the famous Lockheed Advanced Development Projects group. The man who ran the group during the early years — Kelly Johnson (shown with the U-2 spy plane) — wrote up a set of rules that emphasize small teams, close collaboration, low ceremony, iteration and testing, relationships built on trust, and constant communication…
- The Skunk Works’ program manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.
- Strong but small project offices must be provided both by the military and industry.
- The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people.
- Very simple drawing and drawing release system with great flexibility for making changes must be provided in order to make schedule recovery in the face of failures.
- There must be a minimum number of reports required, but important work must be recorded thoroughly.
- There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don’t have the books ninety days late and don’t surprise the customer with sudden overruns.
- The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
- The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and the Navy, meets the intent of existing military requirements and should be used on new projects. Push basic inspection responsibility back to the subcontractors and vendors. Don’t duplicate so much inspection.
- The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.
- The specification applying to the hardware must be agreed to in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
- Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
- There must be absolute mutual trust between the military organization and the contractor with very close liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
- Access by outsiders to the project and its personnel must be strictly controlled.
- Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay, not simply related to the number of personnel supervised.
- Starve before doing business with the damned Navy. They don’t know what in hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy.
And a last rule passed on through oral tradition…
-
Simplicity and discipline
“We are stuck with technology when what we really want is just stuff that works. How do you recognize something that is still technology? A good clue is if it comes with a manual.” — Douglas Adams
It’s ironic that making simple products is difficult, but it is. It requires discipline to design simple products, discipline to focus on real-world use and experience of a product rather than guesses about use, and discipline to market the real value versus the sheen of extra features.
John Maeda’s seventh law of simplicity expresses a similar idea with an interesting phrasing, suggesting that the simpler thing becomes cognitively more…
The more care, attention, and effort applied
to that which is less, the more it shall be perceived
as more than it really is.
-
Premature optimization
“Premature optimization is the root of all evil (or at least most of it) in programming.” — Donald Knuth
I think you can replace the word programming with the word design and that would still be true.
-
Beta is the new black
Brett tracks the coinage of the phrase beta is the new black. While the idea isn’t news to the web-savvy, it’s still a scary concept to product developers in the corporate world.
-
Stuff vs. Process
We understand stuff. We’ve been dealing with stuff for millions of years, from soil to animals to teapots to computers. Cognitively, we’ve got stuff under control. Process is another matter. Many of us share the same way of lacing our shoes and brushing our teeth, but that’s about it. As a result I think it’s cognitively easier for people to understand how a thing will help them vs. a process. It’s easier for a company president to dissolve a business unit than to figure out an alternate process for making it profitable. It’s easier for a CTO to buy silver-bullet software than consider how people might work together differently to achieve the same ends (though I think there’s also a it’s-time-for-the-Jetsons effect). This doesn’t bode well for designers or business designers, who essentially sell a way of doing things.
Given this situation, we can:
- Point to other, successful people using process
- Show how the process leads to a better thing
- Talk about the process via metaphor
Here’s a simple metaphor of using process: my bottle of Tabasco reads:
Ingredients:
- distilled vinegar
- red pepper
- salt
…but obviously just mixing those ingredients together in the right proportions doesn’t yield Tabasco, you need a great process. “First, it’s a special variety of fully-aged red pepper. Then it’s the process. The pepper mash is allowed to ferment and age for up to three years in white oak barrels…”
-
Backwards process
A friend just reminded me of a story from some time ago. I was giving a short presentation at a financial services company on the user-centered design process. The audience was a project team. I threw up some slides illustrating the various activities: researching users, designing the interface, implementing it, etc. Toward the end, the database programmer said, “Ohhhhhh, I understand, you do everything backwards!”
That’s because his process was: build a database, slap on a user interface, and test it… the exact opposite of what I would do.
I wonder if this is a way to explain UCD to technical audiences? “OK, what I’m about to tell you may be hard to believe. But there’s this whole field of people achieving great results by doing everything completely backwards!“
-
What’s next for iLife: Film Direction
iLife let’s you be composer and editor with production capabilities that required an entire studio 15 years ago. The next logical step in consumer production is full-on film direction, a combination of simulation and multimedia that completes the DIY promise. An example of what amateurs are hacking together is Mike Fraser’s 100 years (Windows Media), made using The Sims 2 and set to Five for Fighting’s 100 years (iTunes). It’s rough but wonderful. Wait for the ending.
Update: Brett writes in to compare this to machinima, which it is, and which I should have thought of after discovering the hilarious Red vs. Blue last year. But what if Apple comes at it from the other direction – building a complete production studio on your mac, instead hacking together a movie using a game engine — it could suddenly own the commercial machinima market before others realized there was a market.
-
More on the Origin of Personas
Laurie Vertelney writes in after seeing my take on the Origin of Personas. …It seems like we’d been using scenarios for ages to do design work at Apple and at HP Labs before that. (mid-late 80s) I was personally inspired by some of the work at MITs Architecture Machine Group back in the early 80’s…
I’ve added more of her comments to that post.
-
Doblin’s Short, Grandiose Theory
Thanks to Zap — who invited me to a panel on design methods (.ppt) at the IA Summit — I finally got my hands on a copy of Jay Doblin’s A Short, Grandiose Theory of Design, an article from the 1987 STA Design Journal. In its seven pages Doblin presents a straightforward and persuasive argument for design as a systematic process. Quick notes:
- For large, complex projects, it ‘would be irresponsible to attempt them without analytical methods.‘ He cites the existence of a too-common ‘adolescent reliance on overly intuitive practices.‘
- He contrasts direct design in which a craftsperson works on the artifact to indirect design in which a design first creates a representation of the artifact, separating design from production in more complex situations.
- He outlines a generic process of design: STATE 1 -> ANALYSIS -> GENESIS -> SYNTHESIS -> STATE 2
- Analysis is deciding what is relevant, then detailing and structuring it
- Genesis is expressing the concept, what Terry Swack used to call expressing the intended user experience. In some ways it is model building.
- He demonstrates using a 2×3 matrix of performance/appearance vs. products/unisystems/multisystems (increasingly complex artifacts or combinations of artifacts).
- In the end, he brings it back to a focus on business, reminding us the core issue is to compete effectively
-
Marketing Personas
I spotted this two page spread in Forbes magazine. It’s IBM using a persona (“Lois”) to get companies to think about ‘customer centricity.’ It’s text heavy and superficial, but if it increases customer centricity than I’m all for it.
Similarly, Brett Lider points to Microsoft’s MSN personas. They’d be denounced by Cooperites based on the sheer number of them (one persona for every age group?). More sins abound: ‘Age 14-17, Amanda is at the pivotal point in her life where she is beginning to define her brand affinities.’
She’s age 14-17? Very realistic. She’s developing her brand affinities? Is that what her and her friends do after school? By putting a face on demographics they end up with a face on demographics, not a realistic depiction of a person that we can use our imagination to design for. But this is just a marketing tool, MSN trying to help advertisers advertise. Will it degrade the idea of personas for design? I hope not. Hopefully it’ll turn marketing on to the grooviness of customer centricity.
