Jun/080
Chain Of Command : Good Or Bad?
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.
Jun/083
I have a son now!
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. 
Jun/083
Problems On Sprint Retrospectives
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.
Jun/080
Working With Artists And Coders
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.
Jun/080
Are You Able To React?
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 :
- Have enough balls to take the ownership and raise the problem.
- 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!