Looking Back (2009)

New Year's Eve: a good moment to look back at the year that passed and try to draw some conclusions. A friend of mine said once, "failure doesn't matter, it's only lessons to learn from". I agree with him.

Many people say that 2009 was a bad year, because of the economic depression, because of the shortage of jobs, because of the increased stress. I wouldn't call it bad, but difficult. The optimism that characterized 2007-2008 was harder to find. Many companies changed their strategies and rhetoric, switching from the confidence and growth-oriented speeches of the previous years to cost reduction policies or even lay-offs. For employees, the situation got tense. People are more afraid they may loose their job as management is putting more pressure on efficiency. Tension is floating in the air in many corporate environments. I will not argue here whether this is counterproductive or not, but I dare to say that even though employees are more focused on cost reduction and  usually tend to do their jobs more carefully, the amount of innovation and involvement has, somehow, decreased (I read such a statistics somewhere that, based on what I see around me, I am inclined to believe). People seem to have lost something from their excitement about their work as many of them have switched to survival / cautious mode. Everyone is waiting for the recession to go away and to see the labor market flourish again. News reports show that the quality of life has decreased in 2009. Has it or it's just the feeling that something bad is about to come and it's waiting around the corner? While for many it is, indeed, much worse, for others, who may have no apparent reason to complain, the months-long anxiety and the rumors surrounding them seem to have shaped in a negative way their mindset.

Since I am an incurable optimist, I say that most of the anxiety is in our heads and in the way we look at things (Arguably, right? Yes, for sure, and I will, probably, get a lot of criticism for the previous statement). If I take only the facts though, at least in my case, there hasn't been a decrease in the economic level or a substantial increase in the amount of hours I spend at work. I have experienced a lot of pressure though (but I would have probably experienced it in other conditions as well) and, sometimes, it affected my mood and my overall perceived happiness. For me, 2009 has been a year of many changes. Strictly factual, I would characterize 2009 as a moderately good year, because, most of the time, change presented unexpected opportunities (or, at least, it brought hope for the better).

We, as humans, don't cope well with change as it throws us into uncertain territories. We get anxious in front of the unexpected and most of us perceive it as frightening but, if we keep our eyes open and realize that something bad might happen anyway, maybe we could enjoy life a little more. For many, including myself, it is not always as easy as it is to say it, since it means a lot of energy, strong emotional balance, strong will and determination. As the false economic security feeling of the previous years is lost somehow, some turn to other values in life in search of balance and security. Is this good? Is this bad? I don't know and I don't have the slightest desire to debate it here - I guess it's just a normal, human, response to the turbulent environment.

2010 seems to be even blurrier than 2009 so what I wish for myself is equilibrium. I wish to always find strength to pass beyond all obstacles and seize the opportunities that lie past them. I wish to maintain a clear vision about what I want to achieve and have the will to achieve it. I wish that, at the end of 2010, I'll be a better man, more experienced and more knowledgeable, more warmhearted and at least as confident and optimistic as I am right now.

I wish everyone a Merry Christmas and a Happy New Year! May the joy of the season fill your hearts with happiness and warmth!

Disconnected Thoughts

The difference between a dreamer and a person of great success is that the latter actually does something to achieve his / her dreams.

Focus is slowly shifting from efficiency and order to extreme motivation, adaptability and innovation. Since we need to invent new ways to serve our customers, we need to find those people who are desperately motivated to do it (and keep them motivated :p).

The effectiveness of a research report is inversely proportional to the thickness of its binding - Todd Wilkens (Adaptive Path). I'd extend that to that the effectiveness of any kind of report or document is inversely proportional to the thickness of its binding :D

We are not our target audience! When we build a product, we need to understand the needs, the emotions and the ways our customers are doing things. We are not developing products for ourselves but for a wide range of people, with a diverse range of feelings and backgrounds and we need to see who they are and honestly empathize with them as persons, not as consumers.

Innovation - Random Thoughts

* You tell me that you are waiting for inspiration? Stop waiting and do something! Grab a pen and a piece of paper to scratch ideas all day long. Think of your current problem with all your mind, heart and soul. Ask someone. Prototype with all available tools. At work, at home, in the shower, in the car. Take a break and then restart the process. Be unsatisfied until you have all the answers.

* True innovation lies outside the boundaries set by rules. But we need rules to organize all the rest.

* There are at least two prerequisites for innovation: a clear set of constraints to deal with and an unsatisfied, extremely curious, always looking for improvement and tenacious set of mind.

* Innovation needs constraints, know-how and will. But, above all, it needs a well defined problem and people who are desperately motivated to solve it.

Book Summary: First, Break All The Rules:

The following ideas are not mine but they come from a great management book: First, Break All The Rules (a book based on a Gallup study on what great managers do to be so great)


Key Ideas:
1. The best managers reject conventional wisdom.
2. The best managers treat every employee as an individual.
3. The best managers never try to fix weaknesses; instead they focus on strengths
1. and talent.
4. The best managers know they are on stage everyday. They know their people are
2. watching every move they make.
5. Measuring employee satisfaction is vital information for your investors.
6. People leave their immediate managers, not the companies they work for.
7. The best managers are those that build a work environment where the employees
3. answer positively to these 12 Questions:

* Do I know what is expected of me at work?
* Do I have the materials and equipment I need to do my work right?
* At work, do I have the opportunity to do what I do best everyday?
* In the last seven days, have I received recognition or praise for doing good work?
* Does my supervisor or someone at work seem to care about me as a person?
* Is there someone at work who encourages my development?
* At work, do my opinions seem to count?
* Does the mission/purpose of my company make me feel my job is important?
* Are my co-workers committed to doing quality work?
* Do I have a best friend at work?
* In the last six months, has someone at work talked to me about my progress?
* This last year, have I had the opportunity at work to learn and grow?

Procedure

Procedure: a tool not a purpose!

As manager, I try to encourage people to solve problems and think outside procedures. If a procedure doesn't help solving a problem, maybe the procedure is too rigid and maybe we should think more carefully about it. Maybe it needs an update.

Management Creed

One of my main priorities as a manager is to develop people. I'm striving to create development opportunities for my team, to help them become better professionals, better as humans, better in communication, more organized and more effective. I wish all feel that our project is in line with their personal development aspirations. Only then I can obtain the 110% we need to finish within impossible constraints. I wish I never disappoint my colleagues, to be honest and fair no matter what the consequences, not to make compromises, care deeply for them as humans beings, with feelings, needs, hopes and dreams. Many times I fail to get that 110%, but then I know I've made a mistake somewhere - not in my creed but in my deeds.

Silent Hunter 5 Announced!

http://www.subsim.com/radioroom/showthread.php?p=1152450#post1152450

http://www.silenthunter5.com/

Great one! :D

Suggestion

Give people confidence and a tough milestone. Prepare the safety net and be amazed by the results. 

Comments on Not Asking Questions

Most of the people don't ask questions they think will put them in an inferior position or damage their image because they feel they should have already known the answer. Why? A better approach is, I guess, to understand that if you are a pro than you are a pro and people see and respect that in you or, if you are an aspiring pro, then the easiest way to become one is to learn - and people respect that also. By restraining oneself from asking, one gets to:

• Not get relevant answers.
• Consider many things to be understood a priori by all parties involved because "real pros already know all these simple things" - Do I need to say how wrong that is? How all people see things differently because they had different experiences?
• Miss ideas, suggestions. All unspoken words are a missed opportunity for lateral thinking.
• Be considered uncommunicative or, sometimes, even worse: arrogant or stiff.
• Understand things the wrong way, get wrong ideas, do wrong things.

I guess that, if one is in the room, probably he/she is there because someone has confidence that he/she has something to say so why not say it?

VERY IMPORTANT: no to fall to the other extreme: speak all the time because you think you have all the answers and have the right to monopolize the whole conversation. The point for asking questions is to let others speak and gather information from them by actively listening to what they have to say.

Thoughts On "Cannot Be Done"

We are valuable for what we can do and not for what we can't do. Before jumping to the conclusion that something is impossible, one should make sure he understood perfectly the requirements, that he studied in depth all possible scenarios, that he consulted all available resources and tried to find all possible angles from which the problem could be attacked. I'm not saying that everything is possible or that one should hide if a problem is insolvable. All I'm saying is that it's really not ok for someone to start a priory by "we can't do that" without making sure it cannot be done under all circumstances.

BTW, requests that cannot be completed no matter what are very rare - usually managers and customers have a sense for what is absurd and what is not and don't ask for impossible things or, at least, are willing to discuss options. Most of the time it cannot be done because of miscommunication and lack of mutual understanding. Even under insane deadlines, something can usually be done, but may require changing the requirements and a close tracking.

How Do YOU Want To Be Treated?

Disclaimer: any resemblance to actual characters or facts is just a coincidence. This post does not discuss a specific person of event but

rather tries to underline the idea that people need to be treated with respect, regardless of their position.

Let's start by sharing a link: the ethic of reciprocity summarised in a well known phrase, rooted in the culture of many people: "do to others what you would like to be done to you" or, as it is known across the globe, "The Golden Rule".

Some managers may forget it, being blinded by their function, so they start patronising their subordinates. Others, probably driven either by incomprehension of their role - to service the team to do its job - or a sense of insecurity, position themselves too far from their people thus impeding informal communication or, even worse, rely solely on the argument of hierarchy to force the completion of their goals (instead of discussing personally and try to find mutual understanding). Don't worry! If the team doesn't tell you stuff, they will share it among themselves, behind your back :). I personally don't like hearing words like "subordinate", supervisor" or "hierarchy" when it comes to me and my men. It's not that I am an anarchist of some kind - far from me that thought - but in many ways I find them to be a relic of the past, of times when people were considered brute work force, with no rights and no dignity. Basic needs include food, water, a shelter and security but, right after that comes dignity. Every person needs to be treated with respect and be given a private space to react and sustain his ideas even during an argument. This is actually the reason why negative feedback should be kept private. I find it outrageous when a manager calls his team "a bunch of thick skins" or other names, either in private or in public. He should, under all circumstances, refrain from such judgements.

How I want to be treated by my supervisor is how I expect that I, in turn, treat my team and my team treats me in return - as partners. Me with my responsibilities, him / they with his / theirs. We are all here to build great products for our customers so we are sailing in the same boat, as they say. We should understand and respect each other's responsibilities and act accordingly. I don't mind being guided and shown what and why we go in a certain way but I do mind being patronised. I do mind if I am treated as an inferior being instead of being respected for who I am, for what I stand for and for what I do. I do mind if I'm being dismissed without first being listened or not be given a chance to speak my mind. I do mind also if my values are treated with disregard. Never forget that almost every human on Earth wants to be appreciated for his right judgement and I am no different - and chances are that neither are you! Even more, I consider myself a trained specialist, with something valuable to say. I want to be able to express my personality and have the space to manifest my ideas and thoughts especially because I believe that my greatest asset is my mind - that's why they hired me in the first place, right? Who am I? I'm not only Alexandru; these needs are not only mine, they are universal. So, don't forget: PARTNERS: your boss, your colleagues, your team!

Comment:

Some people may argue that not all men/women are the same in what they want and not every one expects to be treated the same way or have the same values as another one has. Totally true and this is precisely why I feel that my argument is solid. One of the first duties of a manager is to adapt his communication style to each of his team members as he, in turn, expects the same thing from his manager too - adaptability, respect, cherish diversity of thought.

Creativity and Innovation

This post is a collection of ideas gathered from others, ideas that seem so natural and obvious but many people fail to apply them when it comes to innovation and creativity.

• IDEO: build on ideas of others
• IDEO: stay focused on the problem
• IDEO: you don't have to tell people what to do. give them a great problem and they will do the job themselves
• IDEO: one conversation at a time
• IDEO: don't criticize
• IDEO: encourage wild ideas. You don't get to see the value of an idea first of. You have to live with it for a little bit
• IDEO: listening to your current customers can sometime stop you from being innovative. People are used to tell you what they already have plus a little bit more
• IDEO: start with the user experience and then build the technology to support it
• Sketching on a piece of paper is like brainstorming with myself
• Fail soon to get things done faster
• IDEO: give the user feedback
• IDEO: encourage diversity. As the product complexity increases you need more than one type of specialist: you need psychologists, designers, computer engineers, brand research, graphic artists and a lot more
• IDEO: most great ideas come from small, focused, autonomous teams
• PHILLIPS: focus on people, focus on user experience

Obvious, isn't it?

Steve Jobs Quotes

• A lot of companies have chosen to downsize, and maybe that was the right thing for them. We chose a different path. Our belief was that if we kept putting great products in front of customers, they would continue to open their wallets.

• Apple's market share is bigger than BMW's or Mercedes's or Porsche's in the automotive market. What's wrong with being BMW or Mercedes?

Steve Jobs: 1955-2011

• Be a yardstick of quality. Some people aren't used to an environment where excellence is expected.

• Design is not just what it looks like and feels like. Design is how it works.

• I think we're having fun. I think our customers really like our products. And we're always trying to do better.

• I want to put a ding in the universe.

• Innovation distinguishes between a leader and a follower.

• It is piracy, not overt online music stores, which is our main competitor.

• It took us three years to build the NeXT computer. If we'd given customers what they said they wanted, we'd have built a computer they'd have been happy with a year after we spoke to them - not something they'd want now.

• Pretty much, Apple and Dell are the only ones in this industry making money. They make it by being Wal-Mart. We make it by innovation.

• Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.

• The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.

• To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.

• Why join the navy if you can be a pirate?

• You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.

Not Employees But Strategic Partners

One of the duties of a manager is to create a sense of urgency within the team. This is not without a purpose as delivering sooner means not only cheaper but also hitting a market window opportunity, enhanced creativity due to constraints, sense of completion and a lot more. However, creating such a state is very difficult as many managers (including myself) are not always able to come to their team with a solid answer to "why do we need to rush?" question. Most of the time, we mumble something like our boss told us so and we have to obey him. Quite lame, isn't it? There is, however, a powerful tool and a good reason behind the tight deadlines except costs - that is, the company strategy. Often neglected because managers think their employees are not interested, the long term strategy and the overall company vision give the answer to many questions concerning the project and its constraints. Communicating the strategy in a way that is understood by people will turn them into strategic partners rather than simple employees - a part of something bigger, something that makes sense and has a reason. They will better understand what is expected of them as they will see their place in the bigger picture. They will also grasp what is coming up next and also increase their loyalty because they have something to be loyal to. Every human being wants to catch a small glimpse of his future and if managers are capable unveiling the bigger plan (strategy) it will provide at least a partial answer to this natural human need. People who understand their role are much likely to give you trust and have the tendency to rally toward a common goal even if the future is cloudy. So tell your teams about the company strategy and you should be able to see miraculous results.

Why Become A Manager?

Many people don't understand or don't have a clear image of what means to be a manager so, I thought, it would be nice to drop in a few lines on the subject as I see it.

Beside the normal plan - organize - monitor - adjust activities and the tons of emails associated with them, for me the most exciting part of being a manager is where I interact with the team; it's the feedback, motivation, conflict management, team building, developing others activities that I really like.

A manager is "somebody who gets results through people", so one of the most important part of the job is... others. Many people would like to be promoted not because they want or have the skills to be managers, but because they see the job as a recognition for their good work and this should not be the case. The language doesn't help much as "promoting" means going up where being promoted to management means taking on a totally different role. It's a new job altogether, that can be a real pain for somebody who doesn't have the inclination or the drive to do it. It's the "best salesman" syndrome. You take the best sales person you have and you promote him / her as the manager of the sales department and, as a result, you loose a great sales person but you get a poor manager.

Unfortunately, the career paths in many companies don't help much as the management paths are well developed whereas the specialist paths may be not.

At first glance, the management career seems to be much richer and filled with opportunities. However, the best places to work are those where diversity is encouraged, where there is job rotation that don't allow people to become bored at work (e.g. after three years as render programmer, an engineer is promoted to... network programming and after that sound and so on). These places encourage horizontal move and cherish expertise. Good managers realize that creating an aura of glory for every job and for anyone that is performing great is the way to go and by doing so they make sure the talent is best used, people are motivated and come to work with pleasure. They encourage diversity, new ideas, teamwork (instead of competition for the manager's chair), innovation and respect among peers. 

Some companies don't respect specialists too much. Sometimes great engineers are placed in some obscure corner, on small desks, when even the most junior manager has a bigger desk with natural light. Sometimes, engineers are not listened to and their opinion is not taken into consideration. Fortunately, these companies tend to bleed expertise and they soon become dry out of talent - natural selection, I guess. Even more, as organizations tend to flatten, less bureaucrats are needed and more emphasis will be put on highly qualified, high performing individuals. Not respecting or not paying enough your engineers is a deadly sin these days.

Organizations that cherish talent become more agile as management is moving from "paperwork" to genuine leadership and more managers spend their time making sure their star performers get all they need to perform (google "servant leadership"). Today good managers are those who are able to service their teams, to create a place suited for innovation, motivate individuals to do their best, lead the way by finding new opportunities and let the spotlight fall on their teams instead of their own ego. This, I guess, is the manager of today and tomorrow. What do you think? Is it for you? And don't think about the paycheck as in today's business world money is tied more to talent than to position and if you are not extremely good at what you do, no matter what that is, nobody is going to pay you anything (and the reverse is true also).

To sum up, my opinion is that you should become a manager if you like working with people. Not just being friendly to them, but to actually strive to create a better place for them to grow, become creative and also let them get the glory. Don't become a manager if you like your technical job or if you are the "do it yourself" kind of guy; choose a technical path instead, as technical paths will become more and more valuable as companies strive to innovate in order to survive. Find a company that cherishes creative talent and you should be safe and happy.

Note:

One of the main difficulties that arise when an engineer is promoted to management is that the main reason he or she was promoted is because he or she is seen as a person that "gets stuff done". As a manager, on the other hand, he or she needs to let this habit go and make sure that others "get stuff done", which is very different. Most likely this is why so many managers find it very difficult to properly delegate, thus frustrating their employees. 

Other articles that shed some light on leadership / management:

• AIESEC Bucharest Training
• Building High Performance Teams
• Empowering Organization
• Some Management Style Conclusion at the End of the...
• Difficult People
• Leader Role, Manager Position In the Team
• Project Constraints

Inspiring Game Development Article

How to Prototype a Game in Under 7 Days:
Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester

http://www.gamasutra.com/features/20051026/gabler_01.shtml

Quote from the article:
"
Handy Cut-Out List!
Setup: Rapid is a State of Mind

• Embrace the Possibility of Failure - it Encourages Creative Risk Taking
• Enforce Short Development Cycles (More Time != More Quality)
• Constrain Creativity to Make You Want it Even More
• Gather a Kickass Team and an Objective Advisor – Mindset is as Important as Talent
• Develop in Parallel for Maximum Splatter

Design: Creativity and the Myth of Brainstorming

• Formal Brainstorming Has a 0% Success Rate
• Gather Concept Art and Music to Create an Emotional Target
• Simulate in Your Head – Pre-Prototype the Prototype

Development: Nobody Knows How You Made it, and Nobody Cares

• Build the Toy First
• If You Can Get Away With it, Fake it
• Cut Your Losses and "Learn When to Shoot Your Baby in the Crib"
• Heavy Theming Will Not Salvage Bad Design (or "You Can't Polish a Turd")
• But Overall Aesthetic Matters! Apply a Healthy Spread of Art, Sound, and Music
• Nobody Cares About Your Great Engineering

General Gameplay: Sensual Lessons in Juicy Fun

• Complexity is Not Necessary for Fun
• Create a Sense of Ownership to Keep 'em Crawling Back for More
• "Experimental" Does Not Mean "Complex"
• Build Toward a Well Defined Goal
• Make it Juicy!

"

How To Make a Successful Game?

There are two conditions for a successful game

• basic, implicit requirement: the game hits the shelves
• the game is fun enough for enough people to buy it and make it profitable

The fun part is, in term, defined by quality and gameplay:

• Few bugs, no showstoppers
• Smooth game experience, accessibility, gradual learning curve, no unnecessary frustration
• Minimum workload for the player
• High quality audio and render, beautiful landscapes, credible animations and behaviors
  
• Interesting setting, meaning, learning value
• And many more

There are also many more variables, conditions and restriction like, budgets, sales forecast, tough competition, marketing, distribution, etc... How do we achieve all that? It may seem impossible at first but some people just do it. For a successful game to be produced, a series of skills and roles must be defined and assumed. It's not only a one man's show as it was in the early 80's but rather a team effort, based on creativity, technical skills, organizational skills, artistic vision, communication and, above all, passion for the job and strive for self improvement.

The game core team usually consists of:

• a producer (project manager)
• an associate producer
• an art director (gives the unity in terms of looks and the overall artistic direction of the game)
• a creative director (handles the core gameplay mechanics, responsible with the fun element)
• a lead game designer (manages the game design team)
• a lead game programmer (manages the game programming team)
• graphic team leader (manages the graphic team)

These people are responsible for the project, each with his own role and expertise. It's not only them, it's actually the whole team but these guys are generally accountable. They must be, by default, highly motivated and have full faith in project. These guys should explain to the team the means and the purpose of what they do, be convincing and also be a role model for each and every other team member. They are the leaders, they provide the vision and the organizational framework for the project and so, they are not allowed to disrupt the team in any way, they must be coherent in their actions and coordinate among themselves accordingly and must have the talent to ignite passion in the rest. A negative behavior is not tolerated in front of the men. They must understand not only the fun element of a game but also the business requirements and adapt their actions accordingly.

Foot note:

There are two main things that must be taken into account when building a game:

• complete it and mitigate risk
• strive for new, for fun

These must be kept in balance for the project to succeed. The first part is mandatory and is more traditional: "define tasks, deadlines, complete them in time" the other part comes from the team (core or not) and their passion. If the passion is not there, the game will not be a success even if it is completed in time and has only a few bugs. (actually, if the passion is not there, the game will also not be completed in time because it's just too much work to be done and too many challenges on the way). So passion is the key ingredient in this business.

The Pragmatic Programmer - An Exceptional Book

A must-read for any programmer and not only. Doesn't cover a specific technology or programming language but rather focuses on the mindset a true, pragmatic, effective programmer should have. Short, easy to understand, full of clear, concise explanations, tips and quotes.

http://www.pragprog.com/the-pragmatic-programmer

Quote - Bugs And The Agile Way

"1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream."

Full article:

http://agilesoftwaredevelopment.com/blog/jackmilunsky/accounting-bugs-agile-way-2

Leader Role, Manager Position In the Team

Why I Like My Job and The Gaming Industry

a) It's truly dynamic. Technologies change, evolution is very fast and one has to be very competitive in order to keep pace
b) It's highly challenging and fosters creativity and self improvement. It's like living on the edge. In order to stay in the field you really have to be number one
c) It's a vast domain. It's not only about management, programming or methodologies. It's also about what is fun in the world, about how to make people enjoy themselves, about military technology, submarines, weapons, airplanes, warfare, usability, player psychology, mythology, history, beauty and art. It's about cutting edge hardware and various development platforms and constraints: PS3, XBOX, DS, PC, iPhone, etc
d) It's international. Ubisoft, for instance, has studios allover the world and it is possible to work abroad for some time if you really want to and you're good
e) Everything being so cutting edge is also about promoting the right people
f) It's because imagination is really important
f) It's because it's damn hard

Being Agile

Being agile means focusing on features and the product as a whole. Being agile means to iterate and, after each iteration, have a working version of the product. Being agile means to deliver predictable value on the short term and act with the client's priorities in mind all the time.

When presenting Agile (Scrum) to programmers one of their main concerns that rise up is that their code will become spaghetti in no-time and that too much time will be used for changing what has been done. The general perception is that they need do hacks now to deliver an increment and then clean up the to deliver the next increment which means loosing a lot of precious effort. It seems so at first, but what is wrong with re-factoring? Yes, hacking is bad but hacking something quickly as proof-of-concept and have the designers test it quickly can eliminate a lot extra work needed to polish something that may be thrown away. And yes, once the proof-of-concept is validated, management expects the programmers to ask for time to clean up their prototypes and turn them into fully working, state-of-the art pieces of engineering that is then merged with the main development branch.

a) Agile starts from the premises that specs change over time and that the client is free to change his mind anytime after an iteration. This means that is very likely that the feature we try so hard to make room for will not be implemented after all, and that it's very likely that another feature will be requested that breaks the initial architecture. This also means that you need to make your code modular and flexible and be ready for constant refactoring. Good specifications means good enough to start working with and good architecture means something very simple that allows you to build modular code. And then clean it up!

b) Preserving the teams constant over time ensures that that the product is known and understood by everyone. The team takes full ownership of their code, cherishes it and keeps it tidy because, after all, they are the ones who suffer first if it becomes unmaintainable (then comes the whole product as it cannot be delivered on time, then come the customers that may receive poor quality as the result). Since the code ownership is shared across a small team, peer-reviews are constant and, if a culture of constant refactoring is in place, the code actually becomes better and better as new features are added - instead of constantly decaying.

c) Scrum is a tool that allows programmers to keep their code tidy and clean. It guarantees that during the sprint no one will interfere and that they are free to do their job as they see fit. Traditional models allow leads to randomly assign tasks, change specs all the time, in a word create chaos which is the prerequisite of hacks and unmaintainability.

d) Working in small teams leads to better understanding of the source code and knowledge sharing. Code becomes more uniform and has increased quality because more people work on the same areas, share ideas and help each other. Teamwork also minimizes the danger of having some programmers that are the only experts in some areas of code, just because they were the only ones assigned to those areas ever.

e) Traditional models have the risk of loosing track of what the project is all about and get lost in technical details. It is easy to loose a great amount of time developing some sort of cool technology that everyone is very proud of that, from the client's perspective, has very little or no value at all. Especially during the "technology development" phases clients, become very nervous and anxious because they have little visibility of what happens and they see no apparent progress. Therefore boxing technological changes in fixed term sprints increases client's confidence because he/she has at least some sort of deadline visibility and the illusion that that black hole that eats his/her money will, eventually, end soon.

More on this some other time :)

Leader

A leader is someone who is capable of developing a solution for a given problem and be able to do whatever is necessary to implement it. He must be able to act with courage and with the company values in mind. He must always have a proactive, optimistic attitude but should also be pragmatic in terms of risks and plans. He should genuinely believe and always make sure that his personal interest is in line with that of the company. He should be able to motivate people and have enough people skills as to make others follow him not by the means of force but by good will. He should be able to convince people to trust and follow him and not let them down. The role of a leader (formal or informal) should always be a positive one – he is the one who makes things happen.

A Jack Welch Story

The following story is allegedly attributed to Jack Welch and, therefore I will presume the same.

A manager comes to Jack to ask for help in a delicate matter. Jack joyfully offers his assistance but warns his subordinate that the next time he/she comes in with a problem he/she will be fired. "Why?", asks the employee stupefied. Jack answers: "You are hired here to solve problems not to report them to me. It may happen that you ran into something that you can't handle by yourself but such a problem is unlikely to occur more than once in your career here so I'm more than glad to help you. But if it happens more than once though, it means that you are not that good and maybe we can find somebody who does better."

While Jack surely is quite radical in his approach, he has a good point. A manager who goes to his superior whenever he encounters a more difficult situation is a weak manager. He/she has no intrinsic value on his own. Leadership comes from the ability to solve problems and not forward them up the hierarchy. I'm not implying that he/she should hide things or be afraid of consequences of his own actions. I'm not implying either that he/she should never ask for advice or even help. What I'm saying is that, if he/she always feels the need to go "upstairs" for interventions than he/she should seriously ask himself/herself - "Am I really adding value to the enterprise?" And one more thing: if you need to go to your superior, BE PREPARED! Make sure that you have all the answers to all the questions, that you have perfect arguments, discuss them with somebody first. Otherwise you will only make a fool of yourself.

BTW, (Jack Welch in Romania)

http://www.standard.ro/articol_45402/jack_welch__romanii_nu_pot_ajunge_in_tinerete_manageri_in_vest.html

http://www.standard.ro/articol_46708/exclusiv_tmc___jack_welch__credem_ca_oamenii_incearca_cu_disperare_sa_reuseasca.html

http://www.standard.ro/articol_46800/jack_welch__catre_top_manageri__de_ce_este_atractiva_romania.html

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