Category Archives: design

Posted on
by

I attended the May 2009 CHIFOO presentation today on the subject of what happens when design meets Agile development processes. Here are my rough notes from the meeting.

The speakers were:
Lane Halley (lane at cooper dot com)
Cooper
principal design consultant, and teacher at Cooper U
Jeff Patton (patton at acm dot org)
designing and developing using Agile
2007 award winner for Agile Alliance’s award
If you are familiar with Agile, you may want to skip to the 2nd section.
  • What is Agile?
    • Common myths: no planning, no up front design, no documentation, no handoff, self-managed teams, a fad that will go away soon, undisciplined, only works with small teams, an excuse for poor quality.
    • Software development has always been difficult.
      • There’s a long history. Standish Group’s Chaos reports still report most projects fail or finish challenged.
      • Agile’s strongest themes in response to years of failure in death march projects following waterfall-style processes.
    • Agile ideas germinated during the 1980s and 1990s.
      • 1986: Brook’s “No Silver Bullet” describes iterative and incremental development.
      • 1995: Schwaber and Sutherland document Scrum
      • 1997: Cockburn describes Crystal Methodologies.
      • 2000: Beck publishes Extreme Programming (formerly at Tecktronics)
    • These “lightweight” development processes had an image problem. à People with tough problems wanted strong processes, not lightweight processes.
    • Around this time, we start to see the design community and the agile community start to butt heads.
    • The term “agile” coined by lightweight process reps
      • Feb 2001: Agile Manifesto created, a common set of values among methodologies. Created by 17 representatives of different lightweight processes.
      • Since then, attracted other groups, such as lean development.
    • Manifesto for Agile Development
      • Link to it: http://www.agilemanifesto.org
      • Four values
        • Individuals and interactions over processes and tools
        • Working software over comprehensive documentation
        • Customer collaboration over contract negotiation
        • Responding to change over following a plan
      • “While there is value in the itoms on the right, we value the items on the left more.
      • For some, these were mom and apple pie statements.
      • See also the 12 principles in the manifesto.
    • Agile values motivate agile process
    • Agile success is measured through value alignment, not process compliance.
      • You can follow almost any process, and it can be agile, if your core values are agile.
    • What has emerged is a common process framework
    • Today Scrum dominates as the simple agile process framework of choice
    • Scrum describes only 3 simple roles:
      • The Product Owner: Describes that the product should be, and is ultimately responsible for its success
      • The Team: Everyone responsible for constructing the product
      • The Scrum Master: Makes sure the process is working, and all roles are collaborating effectively. Not responsible for making the product finish on time (that’s the product owner and the team), they just focus on making sure the process is working smoothly.
    • Scrum process framework (sometimes called the snowman diagram)
      • Product owner identified a potential product idea
      • Product owner supported by others creates the product backlog
      • In sprint planning the product owner and team plan the next sprint or iteration
      • The team works towards the iteration/sprint goals in a 1-4 week timebox
      • The team keeps progress visible with burndown charts and task boards
      • In the daily planning meeting / daily scrum, the team synchronizes daily in a short morning standup meeting
      • In a product review the product owner and team gather to review the results of the last sprint and reflect on how the product and process could improve
    • Today’s agile processes mix and match techniques from many agile methods: user stories, product backlog, planning poker, burndown chart, task board, test driven development, refactoring.
    • The scrum mantra “inspect and adapt” applies to the product and the process.
    • Agile process is tailored to the organization and team within the organization
      • Venture funded startup versus Large internal IT organization.
      • Mature consumer product companies versus venture startups.
      • Small collocated teams versus large distributed teams.
      • Everyone implements differently. Each implementation is a specific vertical implementation of process that works (or is intended to work) for the specific business environment. Since adaption is a key value, even if they started with the same process, the processes would evolve to become tailored.
  • Bringing UCD (user centered design) design techniques and Agile together
    • Some aspects of Agile cause frustration
      • Agile lacks tools to define business and customer needs and measure product success
      • An agile “product owner” may not accurately represent the user needs. It’s hard for one person to represent all the needs.
      • It’s hard to see the “big picture” when you’re building incrementally
      • Finding the right level of design documentation
(WEH: Isn’t it just common sense that if you see a gap, then you create a solution to that gap?)
    • There are best practices to overcome all these problems
    • Common ground: Interaction designers share many values with agile practioners:
      • Desire to build successful products
      • Focus on providing what people value
      • “user stories” instead of “features”.
    • Agile work styles have many benefits
      • Agile is about shared responsibility
      • Agile is about effective communication: you write things down to achieve clarity and because it will be useful, not just for the sake of writing documentation. [WEH: Using a wiki encourages this behavior.]
      • Agile helps you fail quickly
      • Agile is a more humane way to work: everything is done at a sustainable pace. Have retrospective, measure the rate at which work can happen.
    • Agile processes lead to good partnerships
      • No edicts: a user story is an invitation to a conversation, not an edict of what will happen.
      • …
    • Two different sets of expertise when Interaction Designer and Developers get together
      • Ingrid, interaction designer
        • HCI degree
        • Works on paper
      • Dave, Developer
        • CS degree
        • Ruby, Pivotal Tracker
      • Ingrid: focuses on the probable: what might we do?
      • Dave: focuses on the possible: what can be done?
      • Designer and developer need to be able to talk about both the big picture as well as the nitty details
    • If you’re a designer
      • Be a facilitator: Help people collaborate and evolve ideas in the room together. Don’t go off and develop a vision on your own. You need to bring everyone along with you.
      • Have conversations, not directives
      • Use visual communication: More time on whiteboards, sticky notes, paper. Less time on heavy weight design documents.
      • Help the team understand user needs, behaviors, and attitudes. You are the specialist in this, so you need to help other people. Again, not dictate the solution, but give them the tools to arrive at the solution themselves.
      • Question from audience: when can you challenge the developer?
        • Answer: you can challenge on what is possible. Your role is to prioritize what is really important. Where do we need to push the development boundary of what is possible, versus we can we live with it?
    • If you’re a developer
      • You are not the user. (Unless you are those guys at 37 signals and what you are building is a tool that you will use yourself.) We need to have a shared understanding that it is not us, and a shared understanding of who it is, not an idiosyncratic personal view of who the user might be.
      • Look for the common case
      • Learn design principles and patterns
      • Ask the questions “who is this for?” and “what problem does this solve?”
    • Changing role of interaction design
      • Before:
        • interaction design is a specialized role
        • interaction design done at the beginning of the process
      • With agile:
        • Interaction design integrated in agile process
        • Interaction designers participate in new ways
          • Front end UI development alongside developers
          • Work with product owner to articulate and validate the product concept
        • More frequently, seeing interaction designers as a hybrid role…
          • Interaction designers become product owners
          • Interaction designers become coders who implement the UI front end
    • The role of the interaction designer
      • Facilitate brainstorm sessions where everyone on the team can contribute ideas and jointly understand the implications of design decisions
      • Quickly iterate through different design solutions as low-fidelity sketches to help developers save time and make good decisions
      • Be the team member responsible for user experience.
  • Patterns for Success
    • Put UX in the navigator’s seat
      • UX is an important part of the product owner team
      • Become a design facilitator
    • Do just enough research and design to get started
      • Research, model, and design up front, but lightly
      • Plan for continual ongoing user contact for research and validation
      • (Prioritize the target users: “of the 12 users we eventually want to target, we’ll start with these 3”
    • Focus on the big picture
      • Identify and communicate the overall story of the interface so you can work on smaller parts while maintaining context
      • Be able to answer the questions of “Why are we in business?”, “What is this software for?” Be able to describe the context. What does this product do, and how does it do it, so that the users can accomplish what they need to accomplish? They take just enough time to see, they evolve it as they see more, and they help everyone else to see it.
      • Designers need to be able to operate with a low-fidelity big picture
    • Use good UX practices to support product development
      • Use parallel track development to stay ahead and follow behind
      • Buy design time with complex engineering stories (give the developers some tough problems to solve, so that the designers have time to work on other stuff. It’s balancing of resources, not just narrow focused on business priority.
      • Use RITE to iterate UI before development (you can iterate UI with paper prototypes, mock up tools, etc – so that what goes into development is known good UI.)
      • Prototype in low fidelity. Use paper if you can. Use code if you need to. Use the right level of fidelity. Start low, and move high only as needed.
      • Treat prototype as specification. Don’t add more documentation for the sake of documentation. Have a discussion about the prototype if needed.
    • Engage users continuously
      • Cultivate a user group for continuous feedback.
        • A pool of people I can go too, to show prototypes, get feedback. My pool is big enough that I don’t go back to the same person all the time. I should cycle through so that I am not testing with the same people, not more often than every couple of months.
      • Commit to regularly visiting, listening to, and collaborating with your users.
      • Leverage user time for multiple activities.
        • Example of bad case: you may have user research people who are different from your design people. This should be merged. Leverage the time to its fullest extent.
  • Questions and Answer session
    • What is the ideal seating arrangement?
      • Ambient communication is very important because there is less formal communication. The people who work together should sit together. Information flow is a property to be tuned. Information moves like heat through the room. Organize people in pods, or in big large tables.
    • Any successful teams that are not collocated?
      • Thoughtworks has development in Hong Kong and US. They rotate staff between locations on a regular basis. A couple of weeks each month.
      • Cross country Healthcare: Brought team of engineers from India into the US for a year. Colocated India and Florida engineers for a year, then moved the engineers back.
      • Have constant phone connections.
      • Have video cameras.
    • How do we engage with clients (we’re an agency)
      • Ideally you would want the client to participate to the extent that they can. Join you at your location.
      • Look at “innovation games”, a process to facilitate this kind of involvement.
      • Develop with the client a communication plan: how much do we communicate, what are the checkpoints?
        • But how far do you invite them in? You are making them breakfast, they don’t want to see you making sausage. (there will be some hard tradeoffs.)
        • But the more you engage, the more they want to get involved. The more they get involved, the more changes they make. In the end, they will usually be happy with something simpler and less expensive to build.

Posted on
by

Even the best social media site or wizz-bang collective intelligence Web 2.0 application has to adhere to some basic website usability principles. Here are 25 website usability points to inspect your site against. Very useful!

A few examples:

Section III. Navigation

Once people generally know who you are and what you do, they need clear paths to the content that interests them. Information architecture is a huge topic, but these points cover some of the basics.
12. Main Navigation Is Easily Identifiable
Almost every site on the web has had a main menu since the first browsers came on the market. Make your main navigation easy to find, read, and use. If you have two or more navigation areas, make it clear why they’re different.
13. Navigation Labels Are Clear & Concise
Don’t say “Communicate Online With Our Team” when “Contact Us” will do just fine. Your main navigation should be short, to the point, and easy for mere mortals to grasp.

Posted on
by

WhatWouldGoogleDoHere’s another piece to reinforce customer experimentation (doing stuff live with customers) versus customer research (doing focus groups, surveys, etc). This is from Jeff Jarvis in his book What Would Google Do?

Google vice president Marissa Mayer has said that Google is constantly trying to anticipate and interpret our desires so it can predict what we are going to do–our intent. It does that by watching our every move. When her team wonders whether a page should be this color or that, they don’t make the decision themselves, nor do they hold a focus group. They put both colors on the web in an A/B test that measures which yields better usage. “We’ll be able to scientifically and mathematically provide which one users seem to be responding to better,” Mayer told students at Stanford, demonstrating an engineer’s faith in numbers”.

Reblog this post [with Zemanta]

Posted on
by

I frequently find in my job that I’m the proponent for lots of  iteration and learning. Gifford Pinchot terms this “early learning beats better planning”. By comparison, many folks I work with emphasize getting it right the first time.

While I have nothing wrong with getting it right the first time (if you know what right is, if you have some way to test it, if it doesn’t delay you in getting something out), the problem with it as an approach is that practicioners don’t emphasize closed-loop learning and improvement the way that a “launch and learn” practioner would. So if it isn’t right the first time for whatever reason, you don’t have the processes set up and in place to monitor that, learn from it, and respond rapidly.
I came across an interesting anecdote (via Chanpory Rith, via Trent) from Art and Fear on early learning verus better planning:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.
His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot—albeit a perfect one—to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes—the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Posted on
by

OK, so I had previously found a summary of Kathy Sierra’s 2007 SXSW talk, and was excited to see that she spoke about ensuring the humanness of our help documents, FAQ, and other support stuff.

But after a little more digging, I found some great stuff that she wrote earlier that includes primary research citations. (This is the kind of stuff that’s good to have when you have to defend these ideas inside a big corporation.)
In 2005 Kathy wrote Conversational writing kicks formal writing’s ass. Some highlights from that include:

A study from the Journal of Educational Psychology, issue 93 (from 2000), looked at the difference in effectiveness between formal vs. informal style in learning. In their studies, the researchers (Roxana Moreno and Richard Mayer) looked at computer-based education on botany and lightning formation and “compared versions in which the words were in formal style with versions in which the words were in conversational style.”
Their conclusion was:
“In five out of five studies, students who learned with personalized text performed better on subsequent transfer tests than students who learned with formal text. Overall, participants in the personalized group produced between 20 to 46 percent more solutions to transfer problems than the formal group.”
They mention other related, complimentary studies including:
“… people read a story differently and remember different elements when the author writes in the first person (from the “I/we” point of view) than when the author writes in the third person (he, she, it, or they). (Graesser, Bowers, Olde, and Pomeroy, 1999). Research summarized by Reeves and Nass (1996) shows that, under the right circumstances, people “treat computers like real people.”
So one of the theories on why speaking directly to the user is more effective than a more formal lecture tone is that the user’s brain thinks it’s in a conversation, and therefore has to pay more attention to hold up its end! Sure, your brain intellectually knows it isn’t having a face-to-face conversation, but at some level, your brain wakes up when its being talked with as opposed to talked at. And the word “you” can sometimes make all the difference.

And then in 2007 she wrote Your user’s brain wants a conversation. An excerpt from that post:

Which would you prefer to listen to–a dry formal lecture or a stimulating dinner party conversation?
Which would you prefer to read–a formal academic text book or an engaging novel?
When I pose this question to authors or instructors, I usually hear, “You think the obvious answer is the dinner party and the novel, but it isn’t that simple.”
Followed by, “It all depends on the context. I’d much rather hear a dry formal lecture on something I’m deeply interested in than listen to inane dinner party conversation about Ashlee’s lip-syncing blunder.”
But here’s what’s weird–your brain wants to pay more attention to the party conversation than the formal lecture regardless of your personal interest in the topic.
Because it’s a conversation.
And when your brain thinks it’s part of a conversation, it thinks it has to pay attention… to hold up its end. You’ve felt this, of course. How many times have you sat in a lecture you really needed and wanted to pay attention to, but still found it hard to stay focused? Or how about the book you can’t seem to stay awake for… finding yourself reading the same paragraph over and over because you keep tuning out–despite your best effort to stay with it?
But here’s the coolest (and for me, the most fascinating) part of all this:
When you lecture or write using conversational language, your user’s brain thinks it’s in a REAL conversation!

This is some very cool stuff! Anyone have any success stories to share in making the change to conversational language in technical support content?

Posted on
by
I had the great fortune to get to see Ward Cunningham talk about the design principles of wiki, and then afterwards to chat with him informally in the offices of AboutUs.
Ward is a programmer’s programmer. You wouldn’t confuse his presentation with the slick production of some social media marketing guru, but his wisdom shines through. I was a moderately early adopter of wikis (circa 2001), and I’m been consistently amazed by the almost magical way in which they work. It was a real honor to hear Ward speak and get to talk to him.
Though my notes focus primary on the wiki side of things, I want to note Ward’s key role in helping to both define and create the legitimacy of the Agile development methodology. Creating the first wiki, the C2 Portland Pattern Repository, was in support of this community of practitioners and activists who wanted to document and advocate for how software was really developed, rather than how it “ought to be done”.
The presention was sponsored by CHIFOO, the Computer Human Interface Forum of Oregon. Their theme for year is collaboration: putting “us” in user experience
o       #chifoo09 hashtag for anything relevant to chifoo program for 2009.
Here are my notes for the presentation.
–          Ward Cunningham
o       Currently CTO at AboutUs
o       Influenced object oriented programming, design patterns
o       Invented first wiki in 1994
–          Design Principles of Wiki: How can so little do so much?
–          Wrote the first wiki to support the design patterns community. They were a community that had an email list. Within weeks, he knew that he did something good. And within a year, it was obvious that it was a success. He wanted to look back at the success that he had and understand it.
–          Big Impact. Small System. Eleven Principles.
o       “200 line program” with amazing impact
–          People build elaborate sites with special purpose sharing tools (i.e. a certain company in Redmund), yet those sites are dead. Yet a wiki is evidently alive. How can that be?
o       Eleven Principles
–          Wiki Definition:
o       Encarta: 11 words: Server software that allows people to modify web pages.
o       Brittanica: 608 words, only 60 shown without paying
o       Wikipedia: 3126 words
§         Wiki means quick in Hawaiian. WikiWiki means very quick, Ward too a bus in Hawaii.
§         Wikipedia page on Wikipedia gets 500 edits a year, with a lively discussion. It’s clearly “alive”.
§         Page appears in 90 languages.
–          Wiki versus Blogs
o       A wiki is a work made by a community. People try to come together to make things fit.
o       The blogosphere is a community made by its works. Each corner of the blogosphere has its own feel.
o       An individual wiki contributor can come and go without changing the identify of the wiki.
o       Wikis vs. blogs on Google search trends: blogs got the early start, but by 2006, wiki searches outpaced blog searches.
–          Q: question about wiki in education system
o       A: A key part of teaching kids to write is teaching them that there is value in what they write. What greater evidence of that would be to have them make contributions so well written that they contribute to a wiki?
–          History of wiki
o       C2 Wiki in 1994, wiki online March 25th 1995.
o       Wikipedia 2000
o       AboutUs 2008 (finally earning a living remotely associated with wiki)
§         A page for every domain name on the internet. Allows people to express what they are about.
§         The first Wednesday of every month they host a get together called Wiki Wednesday. Starts around 5:30pm. Have a beer with them.
o       C2 Wiki
§         Served off a little PC under his desk, connected to the internet over a 14.4 modem. Designed to be only text.
§         This one site has grown to over 30,000 pages about software programming.
§         The whole agile programming methodology got its start on C2.
§         Like AgileProgramming has over 100 pages specific to some variation of Agile, and 280 pages on variations of programming.
§         This site fueled a discussion about an experiential view of what programming was, rather than an argument about what programming ought to be.
§         People who are busy doing, don’t have time to write a textbook. But they do have time to write a paragraph.
§         Now 3 international conferences on programming based on C2, and 2 international conferences on wiki itself.
o       Agile development corrects dysfunctional behavior resulting from decades of misunderstood risk.
§         People misunderstood risk and attempted to defer programming as long as possible. The correction is that programming needs to start as early as possible.
o       Cool slide showing matrix about Agile, wiki, open source across the top, with correction, barrier, team, serves on the left side. Reproduced below.
This is a comparison of Agile as a movement to wiki as a movement to open source as a movement.
Agile
Wiki
Open source
Correction
Risk
Knowledge
Property
Barrier
Plan
Privledge
License
Team
Location
Attention
(people contribute for the attention that it gets.)
Merit
(team is pulled together across the internet because of mutual respect and trust)
Serves
Customer
Reader
Developer
–          How small is wiki?
o       SigWik: 4 lines, 222 chars of Perl
o       RikiWiki: 40 lines of Ruby
o       C2 wiki: ~200 lines of code.
o       It’s the “Hello World” of application servers.
–          11 Design Principles
o       Open: Should be a page be found to be incomplete or poorly organized, any reader can edit it as they see fit.
o       Incremental: It must be both possible and useful to cite unwritten pages. (This was pretty revolutionary from an information perspective. Before that, it was considered unreasonable to publish something hyperlinked unless the links went somewhere. So all the information had to be “complete” before it could be published.)
§         Cool story about building hypercard system on Mac that embodied this principle, an early predecessor of wiki.
§         “Being able to point to the empty spot on the table is necessary” for the creativity of design.
o       Organic: The structure of the site is expected to grow and change with the community that uses it. It’s always the right size for the community (co-evolution).
o       Mundane: A small number of conventions provide all necessary formatting.
§         People focus on their ideas and words, rather than the formatting. This was the problem with the folks in Redmund: you could put Word documents in there, and people couldn’t help themselves from using too much functionality.
§         Someone once asked “These wikis are useful, but do they need to be so ugly?” – Ward said yes, because he wanted people to believe they just needed to be literate to contribute, not an artist.
§         Wikipedia has demonstrated that there is a whole lot more markup that is needed for encylopedias, like for doing citations and mathematical formulas. The key is to keep it as simple as possible given what needs to be expressed.
o       Universal Principle: The mechanisms of editing and organization are the same as those of writing so that any writer can is automatically an editor and organizer.
o       Overt: The formatted and printed output will suggest the input required to produce it.
§         This only works if things are very simple. This is lost with Wikipedia.
o       Unified Principle: Page names will be drawn from a flat name space so that no additional context is required to interpret them.
§         Want everyone in the community to be able to use the words in their every day conversations, so the words themselves are useful. No hierarchy, no prefixes, no suffixes. If you have a word on the C2 site, everyone knows what it means.
§         This taught a whole generation of programmers new vocabulary, and over time even unified the vocabulary, so that over time only a single term would refer to a single concept. This is vocabulary construction.
o       Precise Principle: Pages will be titled with sufficient precision to avoid most name clashes, typically by forming noun phrases.
§         To make a link, you have to have two words.
§         Many connections are happy accidents. Where some might see a name clash, others would see a happy accident: a connection between two similar concepts.
o       Tolerant Principle: All input will produce output even when the output is not likely to be that which was desired.
§         I will not output error messages. Instead, the output is shown immediately as a feedback loop.
o       Observable Principles: Activity within the site can be watched and reviewed by any visitor.
§         This came from reading Wabi-Sabi, and also Edwin Schlossberg on interaction excellence.
§         RecentChanges is what gives that visibility. (And this came from the hypercard system.)
o       Convergent Principle: Ambiguity and duplication can be removed by finding and citing similar related content.
§         This is re-factoring.
§         It reflects the emerging evolution of ideas – what is in the system may be ambiguous because what is in peoples heads is ambiguous.
–          Wikipedia’s goal is to have neutral point of view – they are historians.
–          For C2, they were activists: this is the way the world really works. Their goal is not to be historians, but to evolve the thinking in that space.
–          There was a brief discussion of ThreadMode versus DocumentMode – the former is early in the lifecycle of a topic, when its all active discussion, the latter comes when the discussion starts boiling down to the consensus of the group.
–          Wiki Nature: wiki as a meme vector
o       People knew what wiki nature was, because it was wiki like.
o       It couldn’t be described, except by experiencing what it was it.
o       The C2 wiki become a destination for understanding wiki
–          Three things have to come together to have a winning combination:
o       Methodology: How we will learn? à (Piecemeal growth)
o       Community: People come together to help each other learn it. à (RecentChanges)
o       Technology: some small piece of technology to enable it. à (Hypertext)
–          How can so little do so much?
o       Sweet spot of new technology
o       Assemble, guide and transform community
o       Leave room for other’s innovation
–          Question: Was the design goal really transforming/manipulating the community or reflecting what the community was doing into the virtual world?
o       A: It wasn’t so much manipulative, it was bringing the disparate parts of the community together to have a discussion. They were proponents of Agile methodology, and the goal was to transform the naysayers, to explain the agile methodology, to try it, to explain how it works and how it addressed risk, it transformed the people who came to the community.
o       Comment: The community transformed itself.
–          There was a cool discussion of the theoretical influences, and discussion of the role of metaphors, but I was unfortunately fading by that point.
–          Ward had to dispel a notion of computer programmers as anti-social loners. When they were programming, they had a hard time discussing without fighting.
After the presentation, a small group went back to the AboutUs offices, where we continued the conversation over beers. As Hunter S. Thompson wrote in Fear and Loathing, this is where my notes become disjoint and confusing.
I asked about the feasibility of, or current activity in, creating a wiki that is a hybrid: it contains elements of explicit user feedback in the form of content, but depends on collective intelligence algorithms and implicit user feedback (clickstreams, rating of topics) on site organization and navigation. Is this still a wiki? Is it feasible? Does it violate any wiki principles.
Ward generally thought that it was still a wiki. He said that AboutUs was doing some similar things – where they once were asking users to write the content for a specific domain, now they are aggregating some of that. What he described sounded like what Derek Powazek described as “smallifying the task” in his Wisdom of the Crowds talk.
We also discussed how the concept of what a wiki is has changed as the public has become aware of wikis in general, and wikipedia in particular. Earlier, wiki really was the set of design patterns, and each person created their own wiki engine that embodied the design principles but whose implementation was customized to the particular needs of their community. (Hence MediaWiki is different than the C2 wiki, which is different from TWiki, etc.) Over time, the concept of wiki has solidified, so that people think primarily of community contributed encylopedia type knowledge in a MediaWiki environment. This can make it challenging to discuss novel implementations of wiki that embody the design principles but look and feel different than a traditional wiki. 
For Portlanders, there is a monthly Wiki Wednesday meetup at AboutUs on the first Wednesday of every month.

Posted on
by

I posted about Kathy Sierra’s SXSW 2009 Keynote address in which she talked about achieving breakthroughs. In the process found some great notes from her 2007 and 2008 keynotes on Brian Fitzgeralkd’s blog.

  • In her 2007 address, Kathy spoke about humanness being essential to our software and web applications. From Brian’s notes: “Being able to look confused and having the other entity respond appropriately is crucial to human interaction.” and “Help, FAQs, and user docs might not sound sexy, but they are the key to passionate users”
  • In her 2008 keynote, Kathy spoke about how the goal of your products shouldn’t be to have users crowing about your company or your products, but about how they, the users, now kick ass by using your products. 

Posted on
by

There’s a tremendous amount that’s been written about high performance teams. I’ve studied high performance teams as part of my graduate work, read about them as part of my professional career, and had several experiences with high performance teams in the workplace. Reading and studying about high performance teams has the unfortunate effect of making them seem quite complicated, when in reality, there are just a few practices that go a long way towards creating a high performance team.

My experiences have been in the realm of software development, but these practices should apply to other areas as well.

  1. End the day with a debrief meeting: At the end of your workday, take the time to meet and recap what’s happened. Who has accomplished what? Who ran into problems? What were those problems and what can be done with them? The end of the day is typically a time when everyone’s brain is tired, so it usually isn’t a time of great creativity. But it is a time of getting it all out of the table. Part of getting it out on the table is to share problems and successes to that people can sleep on those ideas.
  2. Start the day with a planning meeting: After a good night’s sleep, and with a clear understanding of where everyone is, the morning planning meeting serves to plan out the events of the day. Who will work on what? What coordination will be needed? Who will pair program together? What novel solutions to current problems came to people while they were in the shower? What are the critical few objectives that should be accomplished today? The morning planning meeting is typically upbeat, high energy, and quick: 20 minutes to 40 minutes (max) will serve to plan out the day in great detail.
  3. Start the week with a high level planning meeting, and end the week with a high level debrief: Just as the daily meetings serve to highlight the critical objectives for the day and develop a plan to meet those objectives, the weekly meeting serves the same function, but at a macro level. What are the business objectives to work on this week? What is the plan to accomplish those objectives? What problems meeting business objectives did you run into? This can take as little as an hour on Monday morning if objectives and a path forward are very clear, and as much as four hours if they are not. (But this is time well spent, as it ensures that the rest of the week is highly productive.)
  4. Have a simple, shared system of documentation: It might be a wiki, a Google group, a whiteboard, or a Sharepoint (make sign to ward off evil empire), but almost every high performance team will have a simple system of documentation that ensures the most important information is easily accessible and up to date. This will typically encompass at least the business objectives, the daily plan, the build environment, the architecture plan, and integration points documentation. Too much documentation is overwhelming and a time sink, too little documentation and people are repeatedly searching for the same stuff or wandering aimlessly. Personally, I highly favor wikis if you can get one in your environment. Tips for wiki adoption.
  5. Create a culture of personal responsibility: In a high performance team, everyone should feel comfortable doing whatever is necessary for the success of the team regardless of what the official scope of their job is. In fact, they should feel not only empowered to do whatever is necessary, but ethically compelled to do whatever is necessary. One day, the most helpful thing I might do is stay heads down developing my code. Another day, the most helpful thing I might do is go get lunch or coffee so that someone else can stay heads their developing their code. One day I might be developing a high level architecture, and another day I might be hand-editing every row of a 3,000 row Excel spreadsheet. (Yes, I did that.) The point is that regardless of skills, code ownership, or perceived importance, what is important on any given day and on any given part of the project varies, and flexibly adapting to this is critically important.
  6. Be social: The team that laughs together and plays together shares a bond that goes beyond mere workplace acquaintance. Those weekly and daily meetings are a time for people to bring all of who they are to the table. Getting lunch together is a great way to be social and create pockets of more innovation: what work lunch doesn’t at some point come back around to work topics? One of my teams had a practice of taking off every other Friday during the winter to go snowboarding. It was our motivation to kick butt Monday through Thursday so that we could go enjoy a day of snowboarding with a clear conscience. (Oh, and what did we spend hours talking about while snowboarding? Work, of course.) An actual conversation with our manager when we decided to do this:
    Us to Manager: “We’re all going to take Fridays off to go snowboarding.”
    Manager to Us: “You can’t all go snowboarding on Fridays, there will be nobody here to handle things.”
    Us To Manager: “You’ll be here to handle things.”
  7. Optimize decisions for fun: Obviously snowboarding, team lunches, and coffee together are both social and fun. But other decisions that take place can also incorporate fun into them. Silly as it may seem, but choosing the operating system, programming language, development environment, build tools, database engine are all technical decisions that have implications for how interesting and fun team members find their work to be. Sadly, in large companies these are decisions that are most often made either on the basis of perceived technical merit, or more often, based on existing corporate strategic alliances. A team that is excited to use a new language or development tool can, as a function of that excitement and passion, be ten times more productive than they would otherwise. Whereas, the technical differences in productivity are often quite small. So optimize those decisions for fun and interest, and you’ll get more productive and passionate teams.
  8. Avoid negativity: Few things can be more destructive to a team than negativity. Complaining and trying to place blame are huge time and energy sinks. If there is an issue, then the focus should be on fixing the issue. Not detailing the issue out, not trying to figure out who caused the issue, not belabouring the pain that it has caused. Only on trying to figure out what to about it. In fact, if you have a chronic complainer on your team, one of the best things to stop the complaining is simply to ask the person, when they bring a complaint to you, “What are you going to do about it?”
  9. Have at least one person who likes to work nights and weekends: Every high performance team I’ve been a part of has had one person who works nights and weekends. They just can’t seem to help themselves from staying up half the night to work. This isn’t a choice I would make myself, and I wouldn’t ask people to make that kind of a sacrifice. But if you just happen to end up with one person like this on your team, it will make all the difference. While everyone else is resting and getting their creative juices refilled, that one night person will have: fixed that build problem, solved the defect no one could find, figured out how to use the new GUI library, optimized the performance of the database, found a cool new IDE, and brought the build documentation up to date. And the next day everyone will “oooh” and “aaah” over what they accomplished. Be very nice to this person and buy them lots of coffee and chocolate.