Are we motivated well?

Yesterday, one of my friends forwarded me the link to very interesting presentation on motivation factors, and I want to share it with you. The style is really impressive, and some findings are quite surprising:



Few years ago, I wrote about Self-Motivation indicating that beginners are more motivated because they want to be recognized. The video above describes it as the natural need of mastery.

Does it mean that quick salary growth can kill this need of perfecting oneself and reduce both performance and personal value significantly?

What happens to task board stickers when a sprint finishes

What do you do with completed story stickers when a sprint finishes? I believe that most people just throw they away.

Some time ago when I was visiting one of our scrum teams, I noticed the following scrum rose, which illustrated amount of user stories completed during the sprint:
More petals this flower has means more stories completed during the sprint. When there are several scrum teams working on the same project, they can even use such roses to illustrate overall project progress and dynamic during recent sprints.

Disclaimer: the picture was taken without permission from that particular development team. So I'll remove the article if any team member asks me to do it.

Time Management :)

IT Salaries in Belarus (Year 2009)

Long time since my previous post... Well, as it was expected year 2009 was a busy one, and it brought a set of changes both to IT industry and IT labor market.

Beginning of January is a good time to look back at the previous year, so I'm publishing updated salary statistics that was collected from Belarus software development companies.

While combining this statistics I have not been using any materials available in public domain, so do not be surprised that provided charts are significantly different from information available on dev.by and some other web sites. Yet, several sentences, which explain the meaning of the charts, were copied from one of my previous posts on the same topic.


The first image contains two curves, that reflect proportion of the actual salary values in comparison to the maximum value reached during this period of time. Please note, that two lines differ only in the rate between USD and Euro currencies.

As we can see, average salary in USD/EUR equivalent returned to the level it was 2 years ago.




The second chart shows salary growth level for different categories of expertise. In the terms of this article, the following terminology is being used:

• beginner - entry level technician (0 years of experience);
• specialist - intermediate level (1-2 years of experience in particular area);
• professional - advanced level (3-4 years of experience in particular area);
• expert - a professional with 5 or more years of experience in particular area.

Average went down for all categories, however most experiences specialists lost less than others, which is not surprising because companies tried to keep valuable players especially in this crisis time.



On the next chart, you can see how much IT people earns in comparison to Experts' salaries. Please keep in mind, that Expert's salary doesn't mean highest possible salary in the industry. In this data, it's the average among IT professionals having strong experience in particular area.

As it was stated above, the difference between Experts' salary level and other levels of expertise was increasing during the last year and a half.



The next two images take into account the level of inflation. It might look strange, but last year (2009) was better than 2008 for most IT specialists in terms of the purchase power. Average salaries in USD went about 12.5% down, but local currency exchange rate changed much more outrunning the inflation.


The last chart shows, how the salary grows while a person gets her/his IT experience. Red line uses historical data from the previous graph. Blue line uses only up-to-date salaries and assumes that they are not changing through time for each level of IT employee expertise.



NO charts or source data from this article can be re-republished without written permission from Serge Stepantsov, this blog author.

Why customers do not want Agile

In one of my recent article s I wrote about misunderstanding of Agile development term in the community of IT specialists. Now, I want to share my notes about interaction between customers and software development teams who pretend to follow agile. In other words, I want to continue the topic why customers do not like Agile even with developers who think they do know what Agile is.

One of Agile development principles is close interaction between developers and a customer. Extreme Programming, for example, insists that the customer has to be on site. Scrum says that the customer (product owner) is completely responsible for maintaining the Product Backlog.

Well, it would be ideal situation, and developers believe it has to be such, and otherwise Agile does not work!

Really? If you believe in this conclusion, then forget about Agile... forever :) or, at least, postpone until you learn this methodology better.

If you believe that Agile can also work in real world, which is far away from being ideal, then let's continue.

Let's think about the reasons why customers do order software development service instead of hiring personal programmers The reasons are simple:

1. They do already have their own IT team (by the way, it can be a one-person team - the customer himself/herself), need to extend it, but can't do it by hiring new employees.
2. They do not have IT department, so they want to find some professionals outside who will solve their IT problem.
   

In the case of staff augmentation, the customer usually already has their own development process. It might or might not be Agile. But it's already established, and to change it we have to show that our approach is better than their existing. So to start following Agile we have to follow Agile showing its benefits. Hm... to start follow Agile we have to follow Agile. Seems like a dead end.
Actually not, if we say it in a different way: to involve the customer with his local IT team in Agile, we need to follow Agile ourselves demonstrating value of this methodology.

In the second case, the customer expects that a software development company will solve her/his IT problem completely, not just code some his ideas. The customer expects that professionals will say how to implement his idea and even to recommend some extends. Of course, she/he doesn't want to create hundreds of papers that we call story cards and toss them to some Product Backlog. All they want is to receive what they need :-)

So, the customer do not want Agile, until it's explained as a set of extra bureaucratic steps required from her/his side.

The solution is really very easy: do not expect the customer to do the work they wanted to avoid when ordering your service, and you will see they do not mind Agile :-)

IT Salaries in Belarus (October 2008): crisis or just an expected trend?

I've updated salary statistics information, so graphs on Salary Statistics in IT, Belarus page shows fresh values.

We can clearly see that average salary went down last few month. However the trend looks quite similar to one, that we could see during the same period of time in 2006 and 2007.

The only sign of the crisis is the difference in salary equivalent in Euro. But it's still doesn't mean significant problems in IT business.

May be it's too early to make conclusions.

Wrong interpretation of Agile Methodology term

Year 2008, 7 years since the term Agile Development combined a set of practices and methodologies under one common name, more than two decades since Scrum was introduced... And the concept is still being widely misinterpreted.

It's OK, when far-away-from-IT people who needs to buy some program or to order some software development service know only that agile is the modern trend, and that everyone says agile is good. It's even more OK, if they didn't hear about agile development at all.

But did you hear from software outsourcing company managers and programmers that customers do not want to have agile on their projects? I heard about it a lot. So many times, so I decided to try understanding the reasons, and started analyzing each separate case.

After several interviews, the pattern was beginning to emerge. I continued the process to make sure the statistics is valid, and found out only two exceptions. Both these exceptional cases were the typical samples of outstaffing, where the customer was IT company itself, and they just needed several more developers to close hot positions. Of course, nobody wants to change already established process just because of few more external people.

But the general reason was quite unexpected to me: customers didn't want agile development because they needed an estimate. They wanted to know how much the project was going to cost.

See the problem? Customers mix agile development with time-and-material billing model extended with programmers' anarchy ;-)

Actually, it's just consequence of the problem. The reason is worse. Customers get information about software development from us: programmers, testers, project managers, IT sales people. So it means that most of us either can't explain or even do not understand the principles of the methodology, one of the most popular methodology. This in its turn probably means that most of us are not being interested in anything out of scope of current task. Pity :-(


P.S. Back to the topic. I know at least one outsourcing company that found a way to use this global misunderstanding of Agile term. They built the marketing strategy which promotes agile development in its original sense, but highlighting that it differs them from others. So simple, clever, and still honest enough.

Update (August 2008): Salary Statistics in IT, Belarus

The latest collected salary statistics results include information for May, June and July. Updated charts are available on the original article page: Software Project Upside-Down: Salary Statistics in IT, Belarus

The best strategy won’t help you a bit if you can’t execute it well.

Have you ever been in a situation when your boss has an idea, which she/he thinks is very prospective to implement? The boss explains the goals to her/his subordinates, and directs them to follow the instructions and to start integrating the idea. Subordinates argue a bit describing disadvantages and potential problems... But she/he is the BOSS, so they finally go and pass the strategy statements to their subordinates.

And the company starts moving towards newly stated goals?..

No. Actually no. What really happens is the resistance that increases on each level of company hierarchy. Managers do not believe that the idea is really good. They pass it to their subordinates, but they add their own distrusts while describing the tactic steps. Even if they do not give any negative comments, for subordinates it still sounds like just some more extra work they have to do to satisfy "top managemer's whim".

Football is a game of strategy, but even more, it is a game of execution. The best strategy won ’t help you a bit if you can ’t execute it well.

© Eric Sink on Business of Software, 2006

That's true. If you have a good idea, and have thought over the strategy to reach the goal, make sure it will be executed perfectly! Otherwise, you'll just loose some of your employees' work time and reduce their motivation.

How can it be done? The answer is quite easy to say but yet much harder to do. The 1st thing is to make sure that your direct subordinates share you enthusiasm about the goal, understand and accept the strategy, and are allowed to provide their comments and thoughts about it.

Actually, giving the chance to participate in strategy development is important not only to rise people's enthusiasm. This feedback can be really helpful, because your direct subordinates know more than you about people who is on the next level of company hierarchy. The people who report to your have different information flow, so they can and do know something that is not included into the picture you see yourself.

The most natural learning center for most organizations is at the level of that much-maligned institution, middle management.

© Peopleware. Productive Projects and Teams. 2nd ed.
Tom DeMarco & Timothy Lister

I was participating in several discussions where people were arguing about the meaning of middle management term. As used in this article, middle management means the next level under your own position in the company hierarchy. Just don't forget that these people knows something that you do not know, and their knowledge can be really useful to improve and execute your strategy in the best way!

Why it worth to read generic management literature

Actually not, if you are completely satisfied with your current position and don't want||plan to change anything in future.

If your case is different, then there are at least several reason to read a few management books or take special courses:

1. There are some things that are being taught everyone, who ever takes management courses. Among those basic knowledges, there are some items that look quite interesting and thus are easy to remember. People do remember those items and start referring to those statements in their business or even personal life (at least for some time after learning the topic :-)). It usually worths to know what are they talking about to understand them or to argue. You don't have to take this information too serious, but it still makes sense to get it. Among such basic staff, I can mention:
• Maslow's hierarchy of needs (or just Abraham Maslow pyramid);
• Urgency / Importance quadrant by Stephen R. Covey. BTW, there are also some more popular things introduced by Covey, so I would recommend to read one of his books;
• Conscious Competence Learning Model.
  
  
2. Sometimes such reading is fun:
• Peopleware. Productive Projects and Teams. Tom DeMarco & Timothy Lister;
• Screw It, Let's Do It by Richard Branson;
• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco;
• Life Inside a Bubble by Igor Ashmanov (the book is in Russian).
  
  
3. One more interesting category is "courses/manuals" for top managers. A lot of them are too obvious, some advices are really stupid, but anyway it worth to read to understand your bosses :-) Really, when you read this kind of literature, and find a lot of recommendations your boss follows or better has just recently started to follow, there is quite high probability that she/he will follow other instructions from the same source. I won't provide exact references in this article to avoid unnecessary rumors in the companies that I was working with. However, the rule does really work!
   

Disclaimer: if you are a technical specialist and believe that it's your right way, don't spend to much time on managerial staff. Few books on this topic is more than enough to get an idea what is this all about. Keep your valuable time for more important things, keep going through IT news, learning new technologies and increasing your professional skills.