Oct/080
Software Testing Tips & Tricks E-Book Released!
My second e-book is finally ready!
I decided to continue the Tips & Tricks series, this time the book is about software testing and is not based on my blog writings. It covers software testing concepts which I think are the most important. Working on this book was again a great small journey in the land of writing, I’m still learning, but I hope you can recognize a lot improvement since my last e-book.
Take a look at the table of contents :
- Introduction
- General Testing Practices
- Basic Unit Testing
- Software Integrated Testing
- Regression Testing
- Stress Testing
- Testing Code Features
- Testing Graphics Features
- Automated Testing
- Generated Tests
Price : 10,00 USD – With 28 Day Money Back Guarantee!
I also lowered my earlier e-book’s, Software Development Tips & Tricks, price down to 10,00 USD.
Link : E-Books
Have fun!
Oct/080
Automation In Project Management
Overview
Automation is usually used by engineers to reduce the need of manual work on different kind of recurring tasks like :
- Testing
- Software Releases
- Etc.
But, it can also help project management for example to collect data & produce reports. Currently at work I use automation for :
- Update our sprint daily burndown excel. I have setup a system that will update it everyday at 4PM.
- Produce reports from our project tracking data. My system fetches the data from our project database (which contains tasks, milestones, etc.) and automatically produces projected dates, days left, days used, number of wrong estimations, how much work left in art / code, etc.
Why to use automation?
- You don’t have to spent a lot time doing things manually.
- Less errors, when you do things manually it is very easy to do something wrong.
- Easier to produce more critical data.
- and so on…
Where to start?
I currently like to write these things myself by using for example python, but there are also ready scripts and programs out there to help you to setup automated systems. Also if you happen to use Excel you can automate a lot of tasks in there -> Excel can even fetch data from your database or website. Learn to use your tools, if there are things that could be automated and you notice doing them regularly just do it and see how it helps you.
My experience :
During the time I have been using these I have already saved many days and reduced the number of errors in my reports & other data in general. The sad thing is that I see many managers still doing these things manually. If they would use automation they would have a lot more time to help the team instead of calculating some data that really doesn’t help to team to get the product ready. Nowadays I can use most of time helping the team to build the product itself by helping in programming and in all kind of support they need – I’m there for the team, they tell me what to do, not the other way around. This way I also know the product a lot better… there are loads of good points why to use automation to help you, so why wouldn’t you use it?
Sep/080
Chain Of Command & Learning Organizations
Clinton Keith wrote in his blog about how the chain of command affects inside teams causing delays :
http://www.agilegamedevelopment.com/2008/08/agile-values-individuals-and.html
The usual chain of command can also affect to building learning organization if it prevents interaction between people inside the organization. So let’s think about it from communication perspective. The way I often see it working inside organizations :
- Executive
- Manager
- Worker
- Manager
So, worker talks to manager who decides if he wants to talk to the executive or not, and so on.
The idea is to not prevent interactions between people, because if we only have one people to talk to we limit our chance to learn something new, which is the base idea of learning organization. I think many organizations have forgotten the original meaning of chain of command, it simply means who can command who (or do decisions), not who should talk to who.
The scary thing is that after a while people get used it. Scrum helps (teams), as it encourages people to talk to each other to solve problems, to get new point of views… This kind of mental model needs to be applied to whole organization.
Aug/083
How People React To Changes
This is probably one of the biggest questions for managers. How do people react if they change something?
Well, all managers who have done a change probably know that sometimes the change or parts of it will backfire immediately. This could be because of :
- The change you made doesn’t really work.
- Or the natural way of system reacting to change.
In the first case, it won’t work and you probably see it right away – it just doesn’t ‘feel right’. On the second case the system just does a normal reaction to change. It is natural that the system resists the change somehow as the thing you did is new and the system hasn’t adapted into it yet. Think for example cutting down a forest and building a town in there, what happens to animals living in there?
- Animals either die or leave.
- Animals first resist, but in a while they adapt and become ‘city animals’.
Simple example, but isn’t that the way the nature handles it? If it is true in nature why couldn’t the same rules apply to us also? We are part of the nature.
Manager needs to see the difference between these two. In the first case the reaction is probably so big that it stalls everything and manager needs to change things again. In the second case manager needs to see that the resist is just natural reaction and that it takes time from the system to adapt. The hardest part is to see the difference as it might take months or even years before full adaptation has happened, because of this the manager really needs to be committed to driving the change, otherwise he doesn’t have enough energy to run it through.
Driving changes requires continuous work, manager needs to be measuring the change all the time to :
- See if the status has changed to case 1.
- See if you can improve, continuous learning & improvements. The changes you make rarely/never are perfect immediately.
In order to successfully drive a change the manager needs to act as an example. He needs to be the one who has already adapted to the change and to show other people that it really works.
Jul/080
Driving Changes, For What?
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.
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.
May/082
News
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.
Apr/081
Back From Holidays!
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.