Knowledge Transfer

Knowledge transfer, information and change should be communicated in a way that will not trigger people's natural defense mechanism and resistance. Ideally, it should be demonstrated by practice and coaching and introduced gradually (however, that is not always possible). The process should also have a human, personal touch. Bombarding people with documents, links, articles, plans is a dangerous way to go. If too much information is presented at once, especially in an impersonal form (email, for instance), it never gets read or understood and, a priori, is considered a threat or something that is worth resisting to or, in most cases, a useless managerial caprice. Change is easier to implement if the team is prepared in time, by sending those documents way in advance and request comments on them, by talking about the advantages and issues, by asking questions to identify possible threats and bottlenecks (no, you don't know everything and everyone has a valid point of view), by fostering learning and identifying and naming issues with the present setup. Talk, be personal, ask, understand what others are saying and remember that knowledge transfer should always be bidirectional.

Debate Invitation: Design Documents Versus Mock-Ups*

I'd like to argue that user interface mock-ups, fake screen-shots plus annotations and verbal stories are, most of the time, a better design tool than spreadsheets, word documents or functional diagrams. While there are other valid arguments for / against them, I find the following rather strong and applicable to a wide range of possible scenarios:

• One of the main requirements of any software package is usability. The interface should be simple to use and intuitive and therefore, after a mental movie and a mental proof of concept are created and some ideas scratched down, developers should proceed with it right from the start. If the concept cannot be easily fit in a fake screen shot, then there might be something wrong with it. If the mock-up is not explicit enough by itself (and some side, contextual, annotations) then it might be too complex (and difficult to understand and use) and should be rethought.
• A UI mock-up provides an early feedback on whether the design is consistent. In the process of making the mock-up, one usually reviews its whole mental movie and his/her design notes and tries to blend them together in an accessible format. This way, elements that don't fit very well or don't provide enough value are discovered sooner.
• A mock-up is by far a cheaper validation tool than a full implementation, allowing you to spot a lot of the possible issues, very early in the process.
  
• A mock-up can be a great starting point for a debate or a brainstorming session.
  
• Unlike functional diagrams, mock-ups usually do not contain implementation hints. The construct is based only on what the user / player sees and, therefore, allows the programmer to choose the best architecture possible without any algorithmic suggestion. What I've seen is that programmers tend to take design specifications as architecture specifications, blocking opportunities for extensibility, clean code, better algorithms - UI Mock-ups are a step away from this danger.
• Mock-ups are simpler to grasp and provide better visibility to the design intentions.
• Product validation is easier to do when testing against a pre-made mock-up. It's there or it's not there - more difficult to forget features.
  
• Nobody likes to read lists or long documents. If ever read, long docs are read superficially and, again, some details can be lost and never get implemented. Such a missing feature is hard to discover during validation.
  
• Most of the time, lists and other types of documents have to the reader a different meaning than that intended by the designer (nobody understands exactly the same thing and everybody ends up with another mental image of what's required). If mock-ups are not on the paper, they are constructed differently in everyone's heads, leading later to arguments, difficult and costly implementation changes and frustration.
• The process of verbally explaining mock-ups triggers ad-hoc brainstorming sessions and clarifications. Communication and knowledge transfer is fostered as is friendship among team members.
  

What do you think?
------
Note:
* by UI - mock-up I mean a user interface design suggestion or a fake screen-shot of some relevant in-game (in-application) element or moment, polished to some degree

Blog To Follow On Agile Methodologies

Here is a blog to follow: http://agilesoftwaredevelopment.com/

Some highlights:

10 Principles of Agile Project Time Management:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/10-principles-agile-project-ti

The 12 Best Questions for Team Members:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/12-best-questions-team-members

Professionalism = Knowledge First, Experience Last:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/professionalism-knowledge-first

Kano Customer Satisfaction Model:
http://www.12manage.com/methods_kano_customer_satisfaction_model.html

SCRUM:

http://agilesoftwaredevelopment.com/scrum/simple-product-backlog

http://agilesoftwaredevelopment.com/scrum/simple-sprint-backlog