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.

Competitive Salary

or a myth about the rating of personal needs...

The most important factors for most applicants are working with smart and interesting people, working on interesting problems, free lunches and other benefits, a nice office, and a boss who "gets" them. Way down on the list is salary, although that certainly has to be competitive.

Joel Spolsky, Joel on Hiring and Retention.
Business of Software Blog, October 30, 2007

You can find similar statements in different market reviews and even in some widely accepted theories like the Maslow's hierarchy of needs.

But, what does Competitive Salary mean? I bet, for most people it's equivalent to the statement, that the salary must be enough to support the style of life the person is used to. Usually, this amount is a bit higher than the sum of all current earnings.

So, the 1st thing a potential employee is looking at is the salary. Only after accepting proposed salary, she/he starts looking at other benefits the company can provide.

Want to argue? OK. Try to find a person, who will accept new job without asking about proposed salary amount ;)


P.S. By the way, different surveys give discrepant results. Unfortunately, there is no chance to check how objective such surveys are. There are some references to the surveys conducted in Belarus and Russia (target pages are in Russian):

• http://www.smix.biz/articles.php?id=38
• http://www.bybanner.com/article/2449.html

Salary Statistics in IT, Belarus

I have updated salary statistics information, but this time the figures were collected from Belorussian companies only.

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.


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.

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.


The next two images take into account the level of inflation. That explains why average salaries didn't show significant increase during the period till 2005. The recession in the beginning of 2008 is caused by a bit different reasons, but it's a topic for a separate article ;)

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.

Managing Personal Activities

Recently, I was asked about amount of activities that someone should be involved in:

- I have quite a few manifold activities, and I'm curious if being involved in such variety of things makes sense at all? Is it possible to estimate percentage of effort, that really produced expected return? Do I complete all the tasks, that are important, on time and in proper quality?

There are some good personal time management theories, that describe how to deal with such "increasing" number of responsibilities. However, there is also some other opinion that doubts if you need to do anything about it at all ☺

So we have:

1. The things (activities), that have to be done
2. The person (let's call him/her a manager), who is assigned to these tasks
3. The team (for the purpose of this article, the team size can be of any size including zero)
   
4. Limited time frame
5. Personal manager's preferences to one or other activities
6. Manager's perfectionism

The amount of work, that manager performs himself, is being controlled... automatically. With time, the manager delegates some of his responsibilities to team members keeping the activities that are:

• most interesting for the manager himself/herself;
• are so "important", that the manager can't afford giving anyone else;
• are so "complex", that can't be done by team members with satisfactory quality.

Actions

Until the manager doesn't feel personal overload and the results are positive, it means that automatic control system works. No correcting actions are required.

If the manager feels overworked, it most probably means that either the team size is too small, or that he/she has too high level of perfectionism. In this case, correcting actions can deal with team size, amount of activities, and the actual person's role.

If the work results are not satisfactory, it can be caused by one of the following: lack of skills/experience, lack of motivation, or recent enormous overwork. In most such cases, I would recommend to reform the team relocating the manager to another task.

Starting a Project

Most projects are quite similar in some way:

• You have to create code;
• You have to create some documentation;
• You need to provide introductory materials for new members when they join the team;
• You need to integrate parts of code created by different developers;
• You need to make sure that recent changes do not break old functionality;
• You need to track the progress;
• etc.

This list can be extended or even detailed if we specify some restrictions, like the projects are in Java, or the projects are Windows applications, and so on. But, for now, let's treat it just as a simple argument in support of the fact, that even if two projects look quite different, they probably have a lot of common needs, which can be combined and described by a pattern.

Of course, it's not surprising, and there are already a lot of methodologies (or processes) describing the rules that have to be followed to cover some or other project needs. And I'm not going to invent just another one technique. All I'm going to propose are some steps, that can be done in the beginning of a project. These steps do not contradict popular existing methodologies, but help people to follow their best practices by focusing on them from the beginning.

So the steps are:

1. Organize online collaborative environment for the project team (hereinafter, I'll be calling this environment wiki, however it's not the only possible solution). Having a place where every team member can write her/his comments about the project doesn't mean that all of them will provide valuable feedback by default, but if there is no such environment you can be absolutely sure that you'll miss documenting a lot of important information.
   Note: even, if you it's planned that only one person will work on the project, and this person is you, it's still worth thing to do. First of all, it will be a good place for yourself to store project references and materials. And the second, because the plans has a tendency to change :)
2. Create a section in wiki, that have references to all other external project resources (version control system, file storage, dedicated project server etc.). From the beginning, this area can be about empty or even empty, but it has to be updated when new resources become added.
3. Create a version control environment for the project. I believe it's not arguable ;)
4. You'll need to define the workflow and track the progress, so create some To-Do in any format, that you are comfortable with and that conforms to your company practices. It can be MS Project Plan, SCRUM Product Backlog, one column with the tasks in a spreadsheet, anything... Nothing to write to the plan yet? No problem. Add just one item: "Do Work Breakdown and update the plan". Then start following your plan creating and updating new items when you got or explored new information.
   Note: it's a good idea to have some high level plan before step 1, because it's the good source for high-level project estimate.
5. Organize bug/issue tracking environment.
6. Need to create Software Requirements Specification? Do it... The only advice is to keep it together with all referred artifacts in wiki, instead of creating static Word document (if it's not contradict with existing company standards or with agreement with the customer)
7. Ready to start development? Cool! Start it from creating readme.txt and whatsnew.txt files. If you plan to deploy the results to someone else one day, you'll need some supplementary project files anyway.
   Disclaimer: if you are sure you do not need them, then you do not need them... Never do unnecessary work.
   Note: There is a good principle in XP: You Ain't Gonna Need It (YAGNI), which says "never do the work, that is not required yet". So I've ignored it here... I've ignored it here, because actually these files are required already. See the next items.
8. Create some fake project, add it to version control system, and build it (it can be simple "Hallo World" application).
9. Update wiki, adding information about project/solution files location and any pre-configuration steps that are required to build the solution locally.
10. Create the 1st deployment package. It's about empty... Anyway, create it.
11. Create the one-click-script that knows how to compile complete deployment package.
12. If you need to deploy your package to some place for testing purposes, create additional script that deploys the package to test environment automatically.
13. Describe this simple build and deploy procedures in wiki.
14. OK. So we have the 1st version of our application... 1st version?.. OOPS, we've just forgotten about a way, how this version can be identified on the test and production environment. Add the version info somewhere to the project in a way, it can be easily transferred to the target application. Make sure, that testers and users do always have a chance to find exact project build number that they are using.
15. Find a way to keep version information consistent among all related files (e.g. project file, readme.txt, installation script file, etc.).
16. If you are developing something, that should be installed by users themselves, it's a good idea to create simple installation scrip on this step, and include it to the build process. I mean to create it on this step :)
17. Integrate unit testing environment into the project before creating actual source code
18. Disclaimer: Actually, this step can be somewhere above.
    If it's a time to extend the team, you've got the 2nd team member, and have to make project introduction, then it's a time to create new wiki page: "Introduction into the Project". This page will be the start point for all new team members in the future. The content have to list all step-by-step instructions including but not limited to: project vision, link to a page with references to other external resources (version tracking; bug tracking; etc.), links to the materials that newcomer have to read. In other words, it should list all items that must be completed by new team member before he/she receives the 1st personal task.
    Important: Make sure, that each new person knows that she/he is allowed and encourage to add or modify the information in your team wiki, to create new issue records (bugs or ideas) in the tracking system, and to communicate with the rest team members.
19. Before the 2nd developer starts writing source code, establish continuous integration environment.

Of course, completing this steps still doesn't guaranty project success. However, it gives a good basement for the future results, and will help if the team continues using the system.


P.S. By the way, it's possible to create so called "project templates" and use them when new project is being started instead of repeating counterparts of the steps described above.