Human Resource Management in Agile – Part 5
As I mentioned in a previous article, it is time to return to human resource management. We will focus here on the re-generation of projects in teams. But first, we will educate ourselves about the types of projects that can be implemented in the project team.
Types of projects we can pursue
What should you learn next?
What should you learn next?
What should you learn next?
Basically there are three types of projects in any company involved in the production of custom software:
- Projects in which the client pays for the time of the project team. These are the projects with the lowest risk, but the client has the most control over the work progess. He knows exactly what stage the project is at because he pays for the time of the project team.
- Fix type projects - in this case, the client has no control over the progress of the work. he has ordered the creation of applications to be ready at a certain time, and is interested in nothing more. In fact, projects like Fix are the riskiest projects, which may be taken to any company engaged in the production of software.
- The third type is internal projects. In fact, they are both types of projects, Fix and projects in which you pay for both the time and human resources. These are medium-risk projects.
However, the formation of each of these types of projects appears to be the greatest enemy of each. Keep in mind that the level of distress must always be reduced, so changes must occur. And it is a response to change that is included in the policy of Agile. As we all know, each of our projects has certain known and unknown areas. Some functionality may be taken for granted, while the remaining portion can remain a great unknown. So as you can see, each project must always maintain the balance between planning and changes.
An attempt to eliminate the risk in projects
In fact, to maintain a balance in the project is necessary because we will be implementing projects that have both of these factors, where we know everything and do not have to inquire about anything, as well as with new projects, where change is really all that is possible, and where we have to deal with changes all the time. In fact, innovative projects still rely on inventing something new, and then to test their ideas and reject those that are unrealistic.
In the case of the second type of projects we have a much simpler task. Then you just plan the work time and in turn we make certain pre-defined tasks. In fact, it is impossible to develop them in relation to one right approach, and it all comes out during the project. In short, the bases for policy in Agile teams are end-customers, the products, and people. Now we'll try using Agile methodology to completely eliminate the risks associated with human factors.
In fact, the core of any business working by Agile policy forms adaptive teams. What are their main features? There are four which characterize these teams. These are freedom, responsibility, flexibility and structure. Sometimes, however, there are inconsistencies and ambiguities. Then, the main objective of the team is to maintain a very consistent vision of providing the elements of the product created by the project. This is confirmed by its adaptability. This is very important when using any type of Agile methodology, and requires the use of teams that will be self-organized and have members with great self-discipline.
In this regard, it very much depends on the project manager and this should be a main priority in Agile methodology. The process of creating such a team is made up of many factors. The most important always will be:
- Attract the right people - it is always the most important thing during the project
- Define the absolute vision of the product, including the tolerances allowed in the areas of risk and the role of people in the team
- Another very important factor is to create well-functioning communication channels
- Creating an atmosphere that facilitates decision making
- Creating an atmosphere of a sense of responsibility in each of the Agile team members
- Help and delegate control of product development, and not its individual members control
In the case of Agile methodology, always attach great importance to obtain the right people. This follows from the assumptions of the same methodology, "the people and the relationships between them over processes and tools". So the word of any project manager is very important. Not only that, the project manager must be given the freedom to complete the selection of the project team, and also have all the time in the life of the project to focus their attention on a number of human factors, such as individual talent, skills possessed by the project team, communication within the team and beyond, as well as mundane matters as collegial relationships in the team. Only then can focus on the product and the processes take place within the company.
Note that in the case of Agile methodologies, all is related to each other as in the food chain. The truth is that without the right people to really build anyothing, if we do not focus respectfully on a given product, we will always have to deal with side effects. If you do not stiffen framework of the manufacturing process, performance degradation can occur, and sometimes you'll see the elements of chaos theory. Also very dangerous for the development of the software, as it turns out, for the most powerful teams working side by side in Agile, it is also their Achilles heel, that teams working under Agile methodology focus most of their attention on the individual competence of its members, and it really is the most critical factor in the success of every project.
Remember this one thing. If you have a competent team, then it will be better able to deal with all the tasks without having even explicit processes. The team can work by any methodology and process, and best of all, it will realize all the assigned project tasks.
On the other hand, is much different when you work with an incompetent team. In this case, even if you provide the best tools and processes, each project will end in great failure. In the case where we are dealing with software development, a very important role is also played by the end-user and management company. Without their full support, unfortunately you can not do what you will plan. Agile methodology is focused on facilitating both the relationship with the client as well as with a team of testers who feel the project fits into the end-user.
The recruitment process and its flaws
Guess what is the most common mistake I know of in most of the organizations that are trying to implement Agile methodologies? Well, very often we have to deal with the process of creating new project teams and hiring more and more new employees. What really happens? Most of the company's management and project managers to reach their developed programs and recruitment processes. In my opinion, the worst of them is that they try hard to fit all the candidates into a particular position or policies of the organization, which obstruct their personal development. They do not understand the simple fact that the Agile methodology was developed in a way that puts first the individuality of each of the working people and the unique strength of each of the teams.
In fact, if it's not Agile, a project team is matched against all the processes that are used in the project, and the processes are properly selected and chosen so as to be easy to adapt to the project team. All are based on the methodology, derived from Agile, such as eXtreme programing, Scrum, Crystal, Future Driven Development and Dynamic Systems Development Methodology. Using them, we see that all really put an emphasis on the people who make up the team, their personal talent, acquired and innate skills, commitment to work, and mutual co-operation and communication.
And here again we come back to a very heavy task that lies before each of the project managers. Now, each of its members must understand the purpose of the project, which consists of not only the vision of the finished product, but also such things as his own role and responsibilities he has in the project group. If the project manager is able to communicate in a clear and concise measure, it always helps the team to cope with not only the timing of the project and the time frame, but also allows you to fully identify all the tasks with the highest priority for the project along with their full reasons.
Let's remember one thing. The better the project team members understand the limitations of all types that occur in the project, the more we begin to help in this, but to also observe these restrictions. In addition, this is so that they learn how to make decisions based on compromise, to which they are forced very often in their daily work.
Note that none of Agile projects is a rigid design. All products produced by this methodology are always evolving, and very often the design team is growing. Then just come new members, and the entire project team begins to grow. In addition, during the development of software, often there are new problems. So a well-chosen project manager is the most precious treasure for every organization. It is he who makes the formulation of the product vision of the future an ongoing task, which is an ongoing project manager's duty when they manage Agile-based projects.
Communication and cooperation again
Note that the same authors distinguish between the Agile methodology together two very important concepts that are considered to be synonyms. These are communication and collaboration. What really is communication? In fact, it is only to send, receive and forward all information relevant to the development of the product. What, however, is the meaning in this case of the words together? This term is usually understood as a joint work of all persons belonging to the team. The correct result of a collaboration of individuals is always a ready product or a part thereof, and any decision is made together.
Both of these concepts are really very important for Agile methodology. As has been mentioned, the focus is always on the individual members of each project team, putting tremendous pressure on their talent and individuality, and constantly adjusting the processes taking place in the team to their specifications and the skills of their members. Note that if people can work in teams, in which both the communication and cooperation takes place without a hitch and without much resistance, the team achieves excellent results. These results are always much better and are at a much higher level than when the people in the project team are working individually with their own knowledge and talent.
Why is this happening? Why do we not usually leave to the people themselves? Why not put emphasis on building an atmosphere of conflict, which in the case of several teams determines the success of the project? The answer to this question is very simple. All you have to look at is what really determines the quality of the results of any cooperation. Here are the factors that I personally notice always stand out during the discussion of the results of cooperation in each project team:
- mutual trust
- respect for each member of the project team
- the free and unrestricted flow of information
- joint discussions
- active participation in each project
All of these elements must be combined in the process of joint decision-making. If you lackeven one of them, or as it is sometimes, it is inefficient, the quality of the project results suffers. In fact, for each project , to maintain these relationships is one of the main tasks for each of the leaders of the project. Typically, this involves the use of facilities, coaching, persuading, and silently influencing all members of the project team by himself to try to build healthy relationships in the project team.
The truth is that behind every successful project is always a perfectly harmonious design team. The creation of such a team is always a key task of every project manager. Agile itself also introduces a number of features. The most important of them is to reduce the number of documents that are created in each project by each project team. In fact, the methodology aims to reduce the technical documentation to an absolute minimum. If I had to estimate it all, I think the 80/20 rule applies here. In fact, 80% of the information is transferred in open discussions between members of the project group, and only 20% is based on the use of relevant documentation.