Human Resource Management in Agile – Part 1

I think we all have been behind projects that were not successful. They can be both our own projects and projects for clients. This article is a continuation of risk management in projects related to Agile, but is an entirely different facet, that is, an introduction to human resource management in an Agile.

Technological progress in the past few years definitely requires increases in cash spent on the development of software technology. Although we all work with the latest technology, both in terms of tools to support software development and technology management, most projects still fail. Why? We can find cause in one of the four main priorities of each project, namely its time, budget, quality and scope.

If we know the causes of these failures, we can help not only ourselves but also our own leaders, executives, or our employer to eliminate the causes, or just to guard against repeating the same mistakes. We also teach individual teams how they should use different types of project management techniques in order to achieve success.

To begin with let us remember one thing. Despite the fact that we may master all the techniques perfectly, not every project will be successful. Making mistakes and to relate them to a change in the level of success is healthy, it is simply the natural order of things. I estimate that 30% of the projects in which I participated were unsuccessful, while 70% exceeded the deadline. This is the most correct process. Currently in a month, on average 10% of my tasks fail and exceed about 30% of the quarterly deadline. How did I get such a result? It is really very simple.

After each project the team will analyze what we have achieved and what mistakes we made during the project. Why are we doing this? Because if you did not analyze your mistakes they begin to grow and manifest in all the following projects. In fact, even if we have huge funds for the project, it does not mean that it will be money well spent and that it will return. Although we know companies that spend billions of dollars to promote their solutions, still some of their projects fail.

In fact, the money could be spent much better if the company would devote more attention to the analysis of the causes of failures of projects in such a way that in the future all the events that cause a great risk in our projects were found and eliminated as soon as possible. In this article, and two, maybe three following, we will address the human factor. What does this really mean? In total, this term is defined as all matters unrelated or loosely related to each other, such as communication problems at work, problems regarding the selection of teams, disappointing work, boss or client, lack of motivation to work, and high staff turnover.

Chaos Report and the Report of The Silence Fails

In fact, an analysis of the human factor and all the associated events that maximize the likelihood of risk in any project is able to provide truly valuable information not only to development teams, but also the project manager and the directors of companies that produce projects. If you really captured and adequately exploited it in this way, it would increase the opportunity to complete projects in accordance with the planned scope of activities, budget and duration, but not reduce its quality.

Especially for you I will give three top 10 lists of all the factors that affect the project, as shown in the Chaos Report. The success of each project will surely be affected by:

• Involving the client in the project

• Full support of management

• Clearly placed business goals of projects

• Fully optimized scope of the project

• Understanding and application of Agile methods

• Experienced project manager

• Good management of the budget

• Educated and experienced human resources

• Formalized methodology for project

• Use of standard development tools and infrastructure

Of course, some projects do not end successfully. They have the following factors:

• Lack of information input from the customer

• Incomplete requirements and specifications of the project

• Changing requirements and specifications during the project

• Total lack of support from management

• Lack of competence in the field

• No or very limited human resources

• Vague goals

• Improper timing of the project

• Application of new technologies

By contrast, failure to complete the project is defined by:

• Incomplete requirements

• Lack of commitment to customer

• Lack of human resources

• Unrealistic expectations of the customer

• Lack of support from management

• A change in requirements and design specifications

• Lack of any planning in project

• The famous words, “I will not need”

• Deficiencies in the management part of IT project

• Technological illiteracy

As you can see, studies show a direct link between projects completed successfully, failed, incomplete, or canceled, and the human factor. They also show what really influences the success of each project. What you should remember from this section? First of all, that the larger the scale of the failure of the project, the greater is the human factor in failures. So why do projects fail? The answer is obvious. This is because mistakes are made at the level of project teams.

Another report,The Silence Fails,defines five critical areas for each project. These are the most popular and most expensive in terms of repair and the achievement success. Now, let us mention them in this order:

• Pre-planning of the project – too detailed planning schedule, including dates and resources that have no reflection in reality and in fact condemn the project to fail

• Lack of commitment from the project sponsor – this situation occurs when the project sponsors are unable or simply unwilling to provide support to the team executing the project, and when they spend too little time and energy to bring the project to the end

• Ignoring the priorities – is to ignore the priority tasks of the project team members to which they are assigned. In the case of Agile projects, it will as soon as possible provide clients with tangible evidence that the project does not stand still and deliver even the minimum value for the customer’s business

• Hide the actual status of the project – sometimes it so happens that the leader or team members do not signal any problems that occur in the project, in the case of Agile projects this is minimized by a short project meeting at the beginning of the day and feedback at the end of each working day

• Full team match – some team members do not have the knowledge required to implement the project, though now less frequently it happens also that team members do not want or for whatever reason are not able to engage fully in the implementation of the project.

Selection of the Project

We have seen that the success of the project is due to the team and its leader. A good leader will have far more responsibility than authority to run their project. In projects related to the Agile methodology, the leaders’ hands are tied. Each team is made up of high-class specialists who belong to different groups of jurisdiction. Sometimes it happens so that team members are only temporarily assigned to a project, and in fact have their own superiors, which can be a source of confusion in the team and is really one of the main causes of the failure of projects.

The leaders then can not really do anything, because team members do not appear in project meetings, fail to meet deadlines, do not have the required competence and do not set ambitious goals and challenges. This is the main constraint for each project leader. In practice, if the leader can not invite other people to the team, there is no chance for the replacement of inefficient workers. This causes a feeling of powerlessness in the leader, because he does not have formal authority over the members of the assembly.

Theoretically, in the selection of people to the project team there are two problems. For example, a person who has been assigned to a project can be detected by other participants in the project as an incompetent. Sometimes a leader, afraid to address the matter right away in a clear and open manner, goes the easy way out and commits to the project more human resources than needed to perform tasks associated with the project. This approach increases the cost of the project leader.

Additionally, it creates a certain kind of work environment in which team members do not work together. There is also another common problem: Our leader is forced to declare the need to assign specific individuals to the project. But then he must negotiate with the leadership of both companies and other project leaders. Sometimes it just happens so that a person has a completely different, higher priority in another project and there is a conflict of interest between the leaders of the projects. This leads to a situation in which the project leader is not able to effectively address all critical areas of the project because of the unavailability of human resources. If at any time there exists even one of these reasons, the success of any project is very seriously threatened.

In conclusion, remember that if leaders are having trouble coping with the problems within project teams, regardless of branch, 4 to 5 projects end in part or full failure. It in then that the planned budget or delivery time is exceeded, and even if they manage to avoid this, the product delivered by the project team has either limited functionality or a reduced quality.

Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:

  • Dual Certification - CEH and CPT
  • 5 days of Intensive Hands-On Labs
  • Expert Instruction
  • CTF exercises in the evening
  • Most up-to-date proprietary courseware available

The worst thing in all this is that very few companies still realize how serious the impact is of the human factor in the failure of IT projects. Methods of management in companies are divided into three groups: those focused on people, technologies and processes. Agile is a method of management which in total takes into account all these three factors on par with each other. Most business owners do not underestimate the processes, technologies, and human factors. This is because most of them are overly attached to the procedures. But it should be noted here that in the case of white collar workers or scientists, such as testers, hackers and programmers, a truly enormous role is played by their knowledge and intuition and the ability to quickly adapt to changing conditions.

Summary

In this article, we defined all the practical factors that contribute to the failure of project teams. But still the most important of these is inadequate quantity and quality of human resources selection. What happens? Now, those teams generally do not have sufficient knowledge for a smooth implementation of the project, and therefore can not perform their tasks. Sometimes it also happens that the members of the team are unable to communicate with each other and work together. There is then an unhealthy rivalry.

Now consider how many teams are in our company, and let’s do an experiment. Take one of these teams and for the time being let’s put it outside of favorable work conditions. Give employees a tiny box for a desk, and raise the noise level. Thanks to this, in a very quick and easy way we can put and end to all of our projects, the project team will hate us for sure.

This is the end of this article. I hope you liked it. In subsequent articles, I will tell only of the same good practices during the construction of the project team. Later we’ll see how it looks in the case of Agile, Agile compared with other methodologies, while at the end I’ll show you by example how it looks in my team, and why so we manage to reduce the risk of failure.

Sources:

http://www.projectsmart.co.uk/docs/chaos-report.pdf

http://www.silencefails.com/