DawnBringer3D

Almost every-time I talk to people from different companies and ask about who decided about their company values the answer usually is executives. If I ask do they understand or trust these values the answer is some mumbling : “yea we trust them, it means .. um ..” - ouch.

Company values should reflect the key values of the whole company, which means the values came from the workers, they said they believe in it : “hard work”, “honesty”..

Another thing changing the company values. This is something that most companies forget, it should, at any given time reflect the key values of the workers. It is important to keep it up-to-date, this way people inside the company have some guiding ideas.

So, executives, don’t lay down those values by yourself, ask everybody and make sure that you get at least one core value from each worker - if only 50% answers it doesn’t reflect the whole company.

A while ago I was driving loads of changes to our team, but now when I look back at them, most of them didn’t really succeed.

Most of the time I noticed that only thing we needed was a little kick now and then to remind people about ‘that thing’. We didn’t need full processes, we only needed some simple guidelines to follow. I started driving these changes because I had seen similar things working in big corporations, even I had used them, but those didn’t work in a small dynamic team. In short :

• Most of the changes backfired.
• Those changes that were driven didn’t get implemented as imagined.
• Don’t asume something is going to work only because it is working for somebody else.

What was the ultimate problem in here? I didn’t know what the team wanted - how did they wanted to do the development?

After that I have learned to listen the team better, I do not drive any unnecessary changes, or at least I try to avoid doing that, neither I drive any specific development methods like Scrum. Rather driving things I want to introduce new things to our team, that way I’ll be able to see very fast if the new thing is going to get any wind under its wings or not. Also this faster than starting to driving things that will probably fail, I have more time to do real development and let the team decide if the change is really needed.

The goal of development processes is to help the team improve, to make high quality products faster.

I have been thinking about chain of command lately as I have few times went ‘over’ my boss to his boss to talk about different ideas and problems. I hate the saying ‘going over somebody’ in this case, it makes people sound like traitors - and I think many managers think about it like that.

The problem I see with the chain of command is limiting the communication inside the organization. And that prevents learning inside organization, e.g. if we can always have a chat with only one person we can’t get different point of views and so on. In short, it prevents creating a real learning organization.

In my opinion managers should encourage everybody to talk to the upper management - talk to anybody inside the organization. I talk a lot about the upper management in this as that is the place where the bottleneck usually is.

Think about it, for example, what kind of new innovative product ideas the organizations have lost because of limiting the communication? There are loads of problems when limiting the communication inside organization : manager can forget, it is not in managers list of interests, etc. And when something like this happens we loose the great idea whet-ever it was about product or just improvement in general.

I think openness inside the organization is the key to build up a great place to work and learn at.

Boy was born last Tuesday at 8.11 PM,  3.395kg and 49 cm!!

I’ll be on holiday for a week studying this little miracle, wish me luck.

I have tried using the sprint retrospectives a few times now, but it always transforms in to something else. Now in my experience the problems in the sprint retrospective are :

• Doesn’t happen often enough. If the sprint length is over 3 weeks people will just forget some of the problems. And so will managers too, they aren’t gods either - some problems cannot be even solved right away.
• Too formal. People stress about having a sprint retrospective -> there should not be any pressure or otherwise the meeting will not help, e.g. people won’t tell the truth or in worst case don’t say anything.
• Takes too long. These kind of things should be kept short, raise the negative and positive things and let the manager take action points on them. You can have meetings about the problems later on.

Solution that we came up was having an ‘opening session’ at the beginning of every week to talk raise negative and positive things.

I think many of the concepts in the Scrum are very good, but in order to really get them working concepts must be embedded inside different teams - and as we are humans we all are different from each other. There are different teams that require different approaching styles. I think that is very exciting, to get these concepts working you must first know the people inside the team. Remember that they are the ones that must modify the concept to their needs (People Over Tools & Processes). Do not try to change people to use these processes, it will probably just backfire, instead let the people modify the processes for their needs.

It is sometimes hard to manage a team with artists and coders, because most of the time they don’t understand each other. I’ll present you two ways to manage them so that they are able to communicate and work together more efficiently.

Two Way Communication

Each side must have one person that is responsible for communicating with the other side - work as a translator. It means having technical artist and programmer with art experience. It requires both of these persons to understand the basics of each others work in order to communicate properly. As a second responsibility they must communicate the ‘results’ to their side.

‘High Level’ Meetings

When both artists and coders are required to attend to the meeting, do not go too deep in to either art or code design. Everybody should understand what we are talking about. For example if you go in to designing the implementation of our shader pipeline the artists will feel bored and annoyed as they don’t understand it. Artists probably just want to know what features they are able to use after it has been implemented. Keep the design meeting later with the coders.

One of the most important things today in software development is reacting to changes. The faster we can react the better.

Let’s take an example :

You are working on a software project that has been going on well for a while, but lately things have been progressing very slow due to many reasons (e.g. code architecture had to be changed, flu..) and you know that the the project won’t be ready by the deadline.

Now you have got two choices :

1. Have enough balls to take the ownership and raise the problem.
2. Or keep quiet and hope that everything goes well.

Let’s assume that you chose the second one, what will happen is that you’ll use even more energy to keep the deadline and hide it from the customer, in reality you are just pushing it further away.

Classical situation : pushing the system makes the system push back even harder and harder. The leverage isn’t in working more, remember you cannot change the time. Think the time as your ally not as an enemy, you’ll just need to get more time or drop features to reduce the time needed to complete it.

They key in these situations is to take the ownership and raise the problem, first inside your team and then to your customer.

Inform the customer as soon as possible and set up a meeting to think about solutions for the problem. The faster they know it the better as then they can made adjustments to their plans and so can you. Also it builds up a trust relationship between you and your customer.

Conclusion

The example was just one case, it doesn’t have to be a customer case, it can be any problem, for example inside your team or organization. The same rule applies for all them, there is no sense to not to raise the problem - hiding the problem usually always costs more in a long run than solving it. It is a bug and it will cost a heck of a lot more to fix later!

Ah.. I’v been soo damn busy at work. It means that I haven’t had time to do any of my own things (like writing here) or coding my small RTS game.

Here is a screenshot from it (full size) :

Looks cool, huh?

Let’s just hope that I find enough time to work on it, the hardest part is to get the damn art (like always!).

Until next time.

Yeah, I came back three days ago, but I’v been so busy at work that I haven’t had any time nor energy to write anything.

Holidays went very well actually, I learned loads of new things, programming something on Mac for example. I also managed to read a few books during the holidays.

But I’ll write more stuff later when I have more time.

Finally, a week after I got my first Mac, I have a Mac port ready for my 2D graphics engine. It is soo cool to be able to make same code run on two different platforms!

Only thing I had to do was to replace one file in order to get it running on Mac. The engine and test application code compiled very well, without any warnings or errors and ran correctly, which means I succeeded on making it portable.

Soo, now I just have to get Mac demo out for somebody who has a Mac, so that I can verify it works on other Macs also. If you happen to have a Mac, please e-mail me and I’ll send you the demo. Won’t do public release before it is tested.

Screenshot on Windows :

Screenshot on Mac :