My first training pt. III

Heading to bed, taxi to airport leaves in 6 hours. I’m so excited :-). I just hope my luggage clears Charles De Gaulle airport so that I have clothes when I arrive in Kuala Lumpur.

I’ll try to update my blog with my feelings during my stay in KL. Stay tuned!

I would read that book but, …

Every time I read an interesting book I try to usher others to at least skim the book before declining to read it. Almost every time my gentle suggestions get turned down. There are numerous reasons for not reading that book, here are the most common ones:

1. It is work related, why would I want to read anything related to work?
2. I don’t get paid for reading
3. I will not read anything work related on my free time
4. I have too much work to do

With a little bit of persistence and correct wording you can get over these obstacles. Let’s start with tackling those rejections!

1. You want to do a good job, thus you must improve yourself and your skills. By reading you will learn new things.
2. You get paid for doing good work, becoming a better employee should then mean that you get paid better?
3. You spend half of your waking hours in work. If you do not enjoy it, find a new job that you like. If you do enjoy, then becoming better at what you do will make the work even more enjoyable.
4. If you improve your skills you can achieve more in a shorter time. Become an expert. Start by reading related books.

Now, there you go. Start ushering people to read and learn. Self-improvement is continuous effort.

Introducing new roles

Usually when an organization takes the path of an agile transformation, they have to revise the roles they used to have. Previous project managers are now product owners with new tasks and responsibilities. There are scrummasters without real power and then there are teams consisting of people with mixed backgrounds. There might even be an agile coach guiding the people in their daily work, new roles and environment.

It is extremely important that the new roles are introduced properly. Your old fellow coder may be the new scrummaster, not doing the same job as they used to. Not actively contributing to the code base, testing or release efforts. Old line manager could be the company’s new agile coach. Wondering around and giving advice instead of direct commands and without direct responsibility of the deliverables.

It is sometimes very difficult to perceive these new roles without proper introduction. The old habits and command chains must be cut by introducing the new roles. A higher level manager could introduce everyone’s new roles giving a clear signal that the management is behind them and the change.

It is much easier to act as a scrummaster/agile coach/product owner when the people around you know your new role and the new tasks and responsibilities it brings. And that the new role is supported by the management level. This creates an image that this is not just the usual organization change on slideware and that things will not continue as before.

You have to make the change credible. Otherwise succeeding will be much more difficult.

Applying Kaizen into yourself

I have spent countless hours thinking about personal motivation and enthusiasm and how big role they play in individual improvement.

When you are enthusiastic about something you are at an excellent position to absorb as much new knowledge about that subject as possible. Use this opportunity and improve yourself.

Try to take conscious steps to get the most out of your enthusiasm. If you are interested in a new programming language, buy a book or participate in a FOSS project. Start to code a simple application with the new language.

The point is that you are extremely open to new ideas and knowledge when you are enthusiastic. Take advantage of it!

This way you can set a new status quo for yourself and start the improvement cycle that leads to continuous improvement. There is no end in sight for learning new things.

Kaizen.

The importance of inspiring co-workers

Everyone has stepped into their office feeling that they would rather be somewhere else. We get mired in our daily work from time to time. You can do much by yourself with self-guidance. For example, turn the situation upside-down and think how well you can do your boring chores. Do them with excel!

This does not always work as we are mere humans after all. One way to get over this is to see your fellow developer/tester/geek/wizard blazing with energy after he/she has found something new or is just enjoying the art of writing beautiful code. You can ooze energy from your fellow workers.

If you find yourself fascinated with something new, let it show! This is a good way to stealthily help your fellows to gain motivation and enthusiasm. Inspire them by being passionate.

Enthusiasm and passion are what separates good coders from the great. And in my humble opinion, anyone can become a great coder. You just need to find your passion for it!

Large Systems and Scrum

“Release early, release often” goes the Scrum mantra. What to do when the system to be released seems to be too big for that? I have identified just two ways.

1. Big Bang -release
2. Small incremental releases

The problem with a big bang release is that it requires a lot of synchronization. I mean a lot. From us it has taken roughly 2 three week sprints from 3 teams altogether. That is too much for a single release. Our customers have their on myriad ways of accepting new versions and thus we have chosen to release according to the worst case scenario. Some customers are more than happy to accept incremental additions and fixes but some require 4 months of testing before taking a new version into production. Understandable, maybe. Wise? I don’t think so. By accepting faster release cycles and deployment schedules the customers would open the doors for faster fixes and new features.

On the other hand small incremental releases will force the system to be split up into independent components that are generally easier to upgrade one-by-one than the whole system. These smaller components are easier to test and easier to deliver. By lessening interdependency you improve the quality of the system. Your system becomes more resilient, easier to upgrade, maintain and fix.

But to get this through the management level is currently beyond my means. I need someone to calculate the ROI for me :-)