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.

Whose salary rises faster

During recent few years we can observe significant salary growth trend in most cities in Eastern Europe. The rates go high for all qualification levels, but does the speed differ for different levels?

The following graph is the result of some extra investigation, that was triggered by the comment to one of my previous posts (IT salaries in Eastern Europe). It shows the proportion between salary weights for:

• 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.

Before I'd processed historical salary information, I was sure that Juniors' salaries rise faster, and I had some explanation that seemed very reasonable to me:

• beginners have more areas to improve their personal qualification level. It's quite easy to move from nothing to the next stage in their professional career;
• junior's salary is usually much lower than an employer can afford. It means that it's not a problem for a company to keep her/his salary rising constantly thus increasing the person's loyalty;
• intermediate level professionals are most demanded on the market because they already have enough skills to participate in production process, and their salary still allows to be profitable.

But the figures show a bit different result. The next image contains the salary growth curve for an average IT specialist. X axis lists years of experience, 6 means 6 years of experience in particular area by October 31, 2007. You can see two graphs, one of them uses only present salary information. Another one is based on historical data for an average developer who started his career in November, 2001. These values are adjusted by the coefficient of inflation.


One more chart displays proportion between salaries of 4 mentioned categories (beginner, specialist, professional, expert). The values are also adjusted by the coefficient of inflation, so it looks like salaries were not changing during the period between years 2004 and 2006. Actually the change was just enough to compensate the inflation:

As you can see, my classification identifies only 4 levels of qualification. What is the next point in a career? - is a regular questions for almost everyone in IT. Actually, what is? I'm going to return to this topic in one of future posts, and review several options as well as the difference between employee expectations in IT and in other industries.


These 3 charts can not be re-republished without written permission from Serge Stepantsov, this blog author. However, anyone can post a link to this page.

Project Success

Scott W. Ambler, a DDJ Senior Contributing Editor, Practice Leader Agile Development with IBM Rational, and author of several best-selling books conducted a research to find out how people define projects success, and provided some statistics to his reader (Defining Success. Dr.Dobb's Portal. October 31, 2007):

• Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.
• Scope: 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.
• Money: 79.6 percent said that providing the best return on investment (ROI) is more important than delivering a system under budget.
• Quality: 87.3 percent said that delivering high quality is more important than delivering on time and on budget.
• Staff: 75.8 percent said that having a healthy, both mentally and physically, workplace is more important than delivering on time and on budget.

In general, I like his approach and ideas. However, there is one thing that bothers me a bit. Despite of the fact, that Scott provides different rankings for different categories of respondents, at least 94.7% (there is no exact information about others) of respondents were IT people.

Having tough experience working with various customers, and being a customer myself, I wasn't able to identify which one of the following is usually more important: Quality, Scope, Time or Money. Each case is different, but almost all the time it's some kind of a compromise between those four variables.


Everyone would be happy to get even more than they wanted and, in additional, in supreme quality. But in real life we still have to worry about time and budget, which are usually (yet, not alway) general constraints. So I agree that quality and scope can be ranked on the 1st two places... but only after taking other constraings into account.

Who should sell

Disclaimer: it's about IT outsourcing service.


There is a popular slogan: In our organization, everyone sells!

Actually, this principle was intended to motivate all employees to think about customer needs while performing their everyday work. However, sometimes management goes further, and tries to use this idea wider delegating selling responsibilities to production departments.

From one side, this is a very good initiative, and there are a lot of arguments in favour:

• production personnel is usually more technical, so they can quicker estimate the complexity of requirements, propose different possible solutions, involve the customer in discussion;
• production team understands the needs of existing customer better than sales people do, because of day-to-day interaction;
• having technical background, it's easier to answer process-related questions, thus presenting the company on more professional level.

These arguments are quite strong to start thinking about deep involvement of technical staff into sale activity, at least with existing customers. Why not?

Actually, why not? I still think it's not a bad idea. It just have another side of the coin:

• The most important task for a development department is production. This is the area where they have to provide measurable results. If the results are not satisfactory, even a good marketing deal won't be considered as an affordable excuse. So production managers postpone sale activities to the sideline, and usually its turn never happens.
• Size of a development department is usually the same or even smaller than amount of work that have to be performed. It means that these people simply have no enough time to do something special for sales.
  
• Production department personnel is usually not well trained for selling activities, and most of them are not disposed for this role.
  

Again, listed items do not mean that sale activity is only for sales people. They just have to be considered.


Even more, if we talk about marketing not about just selling process, then developers are often really involved in marketing whether they know it or not. If they are involved in deciding what features to build [and how it will work], they are doing marketing (And the Geeks Shall Market by Erik Sink. Business Of Software Blog. October 29, 2007).

Self-Motivation

It's quite usual to see newcomers being quickly recognized by management for some their achievements. The most noticeable category of rising stars is students, who has just started their professional career.

This fact is not surprising. People in the beginning of the career are usually very motivated to move to higher levels. These guys do a lot to provide quick visible results, follow all (well, about all) corporate policies, do not forget to provide all required reports and so on. They have a lot of things to learn, and a lot of stuff to do to demonstrate that they are not worse than others, they are better! It's a good stimulus, isn't it?

So are students usually more motivated than experienced professionals? May be, but I would say it in a different way.

Beginners are motivated by the need to prove their professional level and their ability to take different role or position. Some of them spends effort to be recognized by colleagues and management, others stay goals just for themselves. Both of these types can make a good career, but the first category usually does it faster and a bit chaotic while career path of the second group is more stable.

every soldier dreams of becoming a general;
every lieutenant dreams of becoming a colonel;
and every captain wants to be a major.

IT is quite similar. While gathering more knowledge and experience, the aspiration is being reduced.

Professional life becomes simpler, people just focus on their everyday activities. They do not try to do something perfectly and to get some bonus for that single achievement. For them, good results are not something uncommon, good results are normal.

Of course, professionals also do need to be recognized. Not just for some individual output, but for the constant success. They do not claim to get such recognition, but if such regular good work is being permanently ignored, the person starts thinking about her/his job in a different manner...

The Elite Team

In the early 1970s, a vice president of one of our client companies sent around a memo on the subject of travel expenses to everyone in his division. You may have received similar memos on the topic yourself, but this one was different. It said more or less this: "It
has come to my attention that some of you, when traveling on expenses, have been traveling economy class. This is not an economy-class organization. This is a first-class organization. When you fly on business from now on, you will fly first class." Of course that memo cost money. The expense was very real and the only thing you could balance against it was an enhanced sense of eliteness. At least one organization thought that was a valid tradeoff. Couldn't happen in a real-world corporation, you say? It happened at Xerox.

Peopleware: Productive Projects and Teams.
by Tom DeMarco, Timothy Lister

This is a very good sample of understanding the team spirit background. To feel and act as an elite team, its members must not just hear slogans propagandizing that they are the best. Each team member must know that they are allowed to be different, and really to be elite.

PR and hiring expectations

Today, I was told the opinion, that company public relations (PR) does not have any effect on the number of candidates "waiting in a line to be hired for the company". A background for this opinion was a statistics, that didn't reveal any hiring increase after massive PR campaigns.

This statement is probably correct... in a case when we are talking about large well-known company.

But if potential candidate never heard the company's name before, or heard the name but still has no associations with it, then chances are she/he won't pay enough attention to a vacancy. The ad can just look like a hundred other similar ads from companies, that will never give a lot of new opportunities, and that nay go out of business pretty soon.


I completely agree that PR doesn't help to hire a lot, but on the other hand its absence kills company growth.

Maintenance and Development... The difference?

"I do not want to work on a maintenance projects", - that's what can be heard from software developers and from candidates quite often. At the same time, most of them can't describe their understanding of the difference between project maintenance and project development or, in other words, the difference between the things they don't like and that they do like.


Project maintenance phase "description"

Below is the list of items that people use to describe the project maintenance phase:

1. Bug fixing
2. In few months after beginning of the project
3. When software architecture is ready
   
4. After the 1st public release
5. When you have to update other's code

So, every project, that is being developed for some time by two or more programmers and that has not failed yet, is a maintenance project, isn't it?


Why it happens

Actually, I was not satisfied with this simplified answer that every project is a maintenance stuff, so I tried to get more information about people, who insists that hates those maintenance projects. After collecting and comparing the results during a period of 4 years, I've come to the following classification:

• Husband is the developer, who works on some particular project from the very beginning, who came through a set of successful public releases, who knows about that product and its code everything. Such persons can be stuck to the project for quite long period of time and fill comfortable enough. However, one day can start "a middle age crisis". This can be a good push for "starting new life". After this point, Father hates even an idea to be involved in new long "engagement". Such crisis can be very short or long enough, but in most cases the person returns to its habits and becomes ready again for new "long relationship".
• Researcher always tries to improve something. He spends part of his work day performing planned activities, and other part looking for new information, trying different technologies. This person can be really bored by the project if it requires 100% of his time and doesn't allow experiments. A lot of people pretends to be researchers, however only very small percentage of them really are. Most projects are still OK for a researcher, because most projects are happy about introducing something that improves the result. Maintenance projects are even a land of plenty for research, because they usually do have some time for improvements. If it's not the case, then it's better to use the researcher on a different task.
• Grandma is a person who pretends to be bored spending a long period of time on similar tasks. However, such developer does nothing to change it. Such kind of a person continue using a rotary phone and hate it, but won't try a button one because "it's too complex" and she "doesn't know how".
• Pseudo-researcher is a middle between Researcher and Grandma. Such person isn't afraid of reading some new documentation, however she/he used to reject most innovations because "there is too late to integrate them into existing project". I'm sure that you heard a lot of times a phrase like: "Well, the idea/solution is really good, but it's impossible to use it on current projects because [...here some generic explanation, that fits all current company projects, goes...]. Let's utilize it for our next projects".
  
• Hack-worker is a programmer, who didn't use to do his job in workmanlike manner. Doesn't matter, if he joined the project from the beginning or when some parts had been ready. This person performs activities ignoring all circumstances, which are not directly covered by the task description. If he needs to paint a wall, he'll never be worried about keeping the floor clean. Fixing a bug, such person can create two or three new. After some period of time, when the number of project-related problems becomes quite high, hack-worker starts hating the project, and other "maintenance" projects. His favorite is to start the project and to leave it before bugs have been revealed.

What is it all about?

Good question... This analysis is one of few things that I had done before I realized how to use the results. So I was just collecting the statistics because I was interested in finding a real reason that stays behind hating "maintenance activities".

But one day, when I was involved in consulting activity related to hiring process in a company that had several software project of different kind, I returned to the same question and found out a way to use this info.

As a result, we prepared a set of questions which helped the company to classify job applicants in one of 6 ways^*, and then select appropriate project for particular candidate or do not make an offer at all.

--
^* 6 ways are 5 groups listed above + people who doesn't make too significant different between programming and "maintenance".

Formula for Success

While reading Eric Sink on the Business of Software, I've found a quote that very closely deals with one of my first posts in this blog, the one about mistakes and activities:

Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. You are thinking of failure as the enemy of success. But it isn't as all. You can be discouraged by failure - or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember, that's where you will find success.

Thomas J. Watson, Sr., founder of IBM