Common Agile mistakes

Common mistakes Agile are:

Extend iterations
Under the motto: "we can not finish this in a short period, therefore we choose a longer one'. This is a fallacy: apparently the requirements must broken down further or to fall off. Prolonging the iteration would only hide the true problem! It may also be that there are still some old improvements that need to be picked up.

For example, an unstable development or test environment reliance on specialists and test managers who are not sufficiently available. A short iteration makes problems more visible so they can be addressed accordingly to higher management.

Change the true purpose of an iteration
Short iterations ensure focus. If changes are permitted during the iteration, the will disrupts that focus. This brings of reduced attention to the risk of quality along with it. Moreover, the risk increases that there is little or no value in realising that iteration.

Only identify blocking issues
Any matter which lowers the productivity of the team, is an obstacle and must be reported! So waiting for answers, the temporary presence or absence of a contact, slow-working equipment, clumsy methods, team members who don’t feel happy because they are just unhappily devorced etc etc.. These are all points that deserve to be addressed.

AINO: Agile In Name Only
In other words, the operational introduction of Agile processes the recommendations mentioned in previous articles. The rituals like the daily scrum are done every day, stickies on a board, or use Agile terms, it is still (ofcourse) no guarantee for Agile success. Make sure you understand the values and principles behind Agile, only then you will see results.

Too fast and too much emphasis on tools
Agile is about collaboration and human interaction. Tools can thereby support, but should never be an end in itself. Great attention to tools is often an indication that something is not going well in terms of communication, coordination or workmanship. Often most digital tools are used on fancy hightec Online-departments where there is a hidden motivation-problem, communicationproblem, and a department cultural problem that is not addressed but disguided.

Documentation
Relevant here is the second value from the Manifesto for Agile Software Development, "Working software over comprehensive documentation. It is not the intention of Agile in order to produce no documentation at all. Product documentation, or the documentation that is needed to use the product (continue) or modify it is definitely needed. However, use documentation not to communicate, but to capture decisions and to describe the operation of the product.

All results will be delivered, they should have a purpose and an interested party, as well as the needed documentation to use it. This should be looked at critically. Project documentation, for example, or those which only documentation is required during the product development, need no big documents. It is, after all, close collaboration and face-to-face communication. In this way, it informed everyone, without too much project documentation.

Fixed-price
Often we work on the basis of fixed-price contracts. A fixed-price contract does not invite cooperation and can throw a spanner in the works for Agile. With this type of contract, risks are bought and the emphasis on work is to get things done ‘as cheaply as possible’. It stimulates the realization of a product as efficiently as possible. However, interim deliverables and fast integration are thus discouraged. Another problem of fixed-price contracts is securing content and time c.q. money. This means there is no space to deal flexibly with new insights. This increases the risk of neglect of quality, only later to be discovered by the customer/client.

At the start of a project everything is considerable uncertain about the effort and planning. To slightly remove this uncertainty, the team can only carry one or more sprints before a fixed-price contract is drawn up. In this way, the team know its speed of velocity (storypoints per sprint), knows the matter and the environment. This allows the team as a whole in a pokergame to make a good estimate of the actual costs and time.

Another option is to establish a fixed-cost contract (fixed budget), rather than a fixed-price contract. This is the true fixed amount of work, but the exact contents may vary: it is possible to 'trade off' requirements. This creates space for the necessary maneuverability. The Product Owner may make these requirements then appropriate in the fixed-cost contract. Exceptions are projects of legislative requirements which all must always be fully implemented according to the law, here you can look at gravity in which these requirements are adjusted. Again, the Product Owner may determine the gravity and weigh the risk of being fined by the government for non-compliance.