As you know, I delight in writing articles on the Agile environment. Why is that? Because I like to advise people about the methodology of software development. Agile is really a very flexible approach to all processes of software development. But even that is not really very flexible, it has its own requirements that must be fulfilled and then it starts to work in Agile. The most critical of the objectives of Agile methodologies is always a very clearly defined vision of the product and to define all the goals for the team or teams working in this environment. In fact, the lack of these is a problem I meet very often. Why is this happening? The answer to this question is in the next section of this article.
Lack of good distribution decisions in organizations is really the nail in the coffin
There is one thing that still amuses me to tears. I’ve heard this a thousand times during counseling organizations implementing Agile methodology. What do I mean? Well, we have a paradox. Suppose we have a company which develops software and that some of its actions does not look as it had imagined. And then a manager or director comes up with a brilliant idea, namely, he talks about the implementation of Agile methodologies in software development. He says that thanks to our organization, all the problems of our company will be solved. Now Agile, in the minds of thousands of people who make decisions in companies, in their opinion is the cure for all evil in the world and the magical silver bullet which will solve all problems immediately. However, is this true? Yes and no.
It all depends on conclusions we draw from the use of Agile software methodologies. See, the advantage of Agile is that even by introducing Agile methodologies we do not get the ready-made solutions to our problems. Through the use of Agile all the problems will be very well exposed and thus we are able to correctly identify the source of all known issues.
Very often, if you’ll look at most organizations, and in particular this already, how they are managed, what can be seen is their lack of any vision of the future product. And even if there is such a vision of the product, it is not consistent, and there are problems with the vertical decision-making and decisions taken with regard to the vision of the product. In most companies, you know, very often operates what is called chains of trust. How does it look?
Now, usually this is that developers trust their managers in terms of a coherent vision of development. Then the managers trust their superiors that they already know how the product is to actually develop. Managers then have a higher level of trust that the management company or the director decides how the product must ultimately look and that they have all the information that is necessary for the project to grow properly. And at the end of the chain is such that the directors are confident that their superiors, the president of the company, has all the necessary information to manage the project.
More interestingly, the situation also works in the other direction. Most of the great presidents are convinced that the directors of the individual subsidiaries or divisions have enough power to take care of the final vision and product development. This stems from the assumption that the president of the company is certainly less knowledgable about the product than the director responsible for the composition and execution. The director of the branch again is not quite sure how it’s all supposed to look in the final version, but from what you have all kinds of managers? So the management of the company is encoded with deep confidence that will give managers ability to cope somehow, because they should have a lot more information from them about the structure of the IT project. Again, managers pass the entire responsibility on to the developers because of their ridiculous sense of the world, the programmer should know what he is doing, because the best of all known systems, which he is currently writing. And then somewhere at the end of the process, chaos really begins to reign.
One beautiful sunny day, it turns out that most of the decisions that are crucial for the project are taken quickly and on the backs of his superiors. What’s worse, most of the people who are the recipients of a beautiful theory of intermediate or finished product, start to put up with this sick situation in the project. When you get the final product ready, they start to think that these were the intentions of the project managers and a large number of other people who were responsible for the shape of the product. And who really was responsible for the shape of the product? When a customer is unhappy again the chain moves from top to bottom of the organization, and everyone gets the ears. The same client, when he realized his other projects, never again trusts a software company that pardon, screwed up the software they designed for him.
Here again, there is another thing that most managers do not mind at all. Of course, at the end of the block is a person’s decision-making, which in the case of failure of the project will get the most. It is the programmer. A disgruntled programmer has one major drawback, he knows all of the presidents of the company. Underestimated, the programmer likes to change their employer. And then what? He usually goes to the competition.
Countering the lack of consistent decision
The problem of consequences when making decisions is the first of these problems I have. Why? Because the chief advantage of any organization implementing Agile usually occurs at the beginning of the implementation of Agile methodologies in the company. Fortunately, Agile prevents hundreds of problems that may arise during the implementation. What’s better, the problem is really quickly solved, and completely pulled away mercilessly by all Agile project management methodology.
Many people mistakenly believe that they cannot do anything about the Agile problem described in the article, and it is full of truth. This methodology provides a lot of useful tools. Indeed, the use of Scrum helps us with things such as Product Backlog and the same role a person called Product Owner. Sam Product Owner is primarily responsible for the sequence of tasks that takes the vision of the team and the formation of products. However, for most organizations the selection of Product Owner is still a major problem. But on this topic, however, I will not elaborate too much here.
As a person conducting training often on Agile methodologies, I hear almost daily questions about the motivation of individuals and teams. Most of the answers to these questions are written by me in a series of articles on human resource management, which can be found on the website http://resources.infosecinstitute.com, but because of the reminder I’ll say it again, in a nutshell, is what I was describing. Remember that I really do not have any general principles that would define the brilliant ways to motivate people. However, one effective unwritten rule that people really can not be the motivating force for anything. You can of course create the right environment that will be conducive to both their work and motivation. You can also provide our people the right tools. If people are going to have both of these factors, they’ll be able to take advantage of this incentive. The main tools that we can give to our team, is primarily to define a number of basic values.
The first value, we can define to specify a particular direction, which is to follow the team. Do not tell developers text like, “Do I play.” Tell the team clearly that it is to be a board game or a card game where the scenario is clearly defined by all involved in the project. The next element is the establishment of a clear objective to be reached and the achievement will be the reward for all the teams working on the software. And here, as the owner of a consulting company in Agile, I noticed one thing. The teams that actually know what is really striving and know the full vision of the product, which is currently working, you really make the software much more effectively than teams that do not have any information or have limited access to information about the resulting product.
Let us return for a moment to Agile teams
Most of you read all of my previous articles on Agile. You probably know that the core of this methodology is to form self-organizing teams. You do not bother with what their role is, but to specify a certain area, after which the development team has to move, and then define a clear goal of what our team has achieved. We are talking about every team, no matter whether they are developers, the company’s IT department, or the company as a whole. The truth is that if the team does not have any clearly defined goals, it will move in a circle, and any success will be due to chance. Of course, each of the managers may need to define the limits, after which the team can move and minimize the area to move the team to the point that getting around this area will be conducted only in one direction, until the end. But in this case we do not have to deal with Agile methodologies, but with what is called Manage and Control and as we can see from the name, requires a truly continuous and strict control and full supervision.
In this series of articles I discuss the fundamental problems of all companies that implement Agile methodologies. Most of these problems are unfortunately met by almost any company. But no one no one ever promised that everything would always be nice, beautiful, and a bed of roses. All changes require us to always continuously work on them, but as they say, work ennobles.
Today, I described one of the biggest problems when people start to use Agile methodology. It is a lack of consistent and clear decisions, and that teams are given various, unspecified signals from the top and no one really knows what’s going on. Unfortunately, this approach always leads to chaos in any organization. But as I wrote earlier, Agile expose this problem very quickly, even though it does not miraculously heal it. So what do we do in a situation when it begins to occur?
First of all, quickly draw your own conclusions and let us examine the source of the problem. It may be that the problem lies within us and our approach to our beautiful company? Or perhaps it lies somewhere higher or lower in the hierarchy? Do not be afraid of being criticized, and indeed criticism of others. You do this so that no one feels offended by your criticism or upset. I can only wish you good luck. Finally, I want you to ask you to very carefully read all of my previous articles on Agile, which appeared on this website. For sure it will enrich your knowledge of Agile methodologies in project management companies.
In this series, I think there will be 5 – 6 articles. Their aim will be to try to change the thinking of those who still want to learn. Solve all the problems that will come into contact during the software development in Agile methodologies and management changes in the way most companies. Yes, believe me! Using Agile can manage every department in every company of the future!