by Plamena, Project Manager at Flat Rock The software community is moving from linear development processes such as Waterfall to a more incremental approach. The Agile process is now accepted as the better alternative to the traditional software development. If done properly, it can improve the quality, reduce the time to market and mitigate risks. However, the risk increases when Agile is not applied correctly. Unfortunately, it is quite easy to get it wrong and go overboard by becoming ‘too agile’. Here are 5 things you can easily misinterpret in an agile project: Planning Agile development minimizes the long term planning in favour of short term adaptiveness. This short term focus increases the risk of neglecting best practices that are essential to the long term success. The fact that the agile development prefers flexibility and adaptiveness does not mean that planning is redundant. Agile methods are adaptive, not unplanned. The team shouldn`t be short-sighted. Instead, they should pay attention how the solution will perform in the long term. The project stakeholders should also understand the importance of implementing best practices and recommendations instead of pushing for early delivery at any cost. Requirements Agile welcomes changes in the requirements even late in the development. The strength of the agile development is that it can meet the changing market conditions and give the customer a competitive advantage. Embracing change, however, doesn't mean that the scope is ever-changing. Changes are welcomed when needed but in order to create a working system, there must be some constants. And each change comes with a price. For some agile projects, the requirements change so often that they never see the light of day. Documentation Many believe that agile projects don`t require documentation. This is maybe the biggest misapprehension in the agile world. Agile isn't anti-documentation. A more accurate way to say it would be that Agile doesn't do documentation for documentation's sake. Ideally, the documentation for an agile project shouldn`t be too detailed but it should exist and be sufficient for the team to complete their tasks. Тhe documentation should be iteratively refined as the project evolves and the team is gaining greater understanding of the project's scope and problems. Micromanagement One of the main principles from the Agile manifesto is that ‘the most efficient and effective method of conveying information to and within a development team is face-to-face conversation’. Unfortunately, this gets misunderstood often and leads to absurdly frequent meetings that reduce the actual development time. Although being informed is important, you should not forget another agile principle – that the team should be self-organized and you should ‘trust them to get the job done’. Transparency Everyone can agree that transparency is important. Each agile team is supposed to provide full visibility of their work and time. This allows the daily fluctuations of each team member’s productivity to become visible. Such fluctuations are normal, but in many cases instead of looking at the big picture, the team is focusing on the small issue. This leads to people playing a game of appearing productive instead of actually doing their job. The team is afraid to make mistakes, which as we know are a vital part of any development process. This induces needless anxiety in the team members and at the end affects their productivity in a negative way. Agile as any other methodology is just a set of guidelines to follow. It is not a silver bullet as you can fail spectacularly with it as you can do with any other traditional method. If you choose to ‘go agile’, you have to make sure you implement it properly and not go into extremes.

by Plamena, Project Manager at Flat Rock

The software community is moving from linear development processes such as Waterfall to a more incremental approach. The Agile process is now accepted as the better alternative to the traditional software development. If done properly, it can improve the quality, reduce the time to market and mitigate risks.

However, the risk increases when Agile is not applied correctly. Unfortunately, it is quite easy to get it wrong and go overboard by becoming ‘too agile’. Here are 5 things you can easily misinterpret in an agile project:

Planning

Agile development minimizes the long term planning in favour of short term adaptiveness. This short term focus increases the risk of neglecting best practices that are essential to the long term success.

The fact that the agile development prefers flexibility and adaptiveness does not mean that planning is redundant. Agile methods are adaptive, not unplanned.

The team shouldn`t be short-sighted. Instead, they should pay attention how the solution will perform in the long term. The project stakeholders should also understand the importance of implementing best practices and recommendations instead of pushing for early delivery at any cost.

Requirements

Agile welcomes changes in the requirements even late in the development. The strength of the agile development is that it can meet the changing market conditions and give the customer a competitive advantage.

Embracing change, however, doesn’t mean that the scope is ever-changing. Changes are welcomed when needed but in order to create a working system, there must be some constants. And each change comes with a price. For some agile projects, the requirements change so often that they never see the light of day.

Documentation

Many believe that agile projects don`t require documentation. This is maybe the biggest misapprehension in the agile world.

Agile isn’t anti-documentation. A more accurate way to say it would be that Agile doesn’t do documentation for documentation’s sake. Ideally, the documentation for an agile project shouldn`t be too detailed but it should exist and be sufficient for the team to complete their tasks. Тhe documentation should be iteratively refined as the project evolves and the team is gaining greater understanding of the project’s scope and problems.

Micromanagement

One of the main principles from the Agile manifesto is that ‘the most efficient and effective method of conveying information to and within a development team is face-to-face conversation’.

Unfortunately, this gets misunderstood often and leads to absurdly frequent meetings that reduce the actual development time.

Although being informed is important, you should not forget another agile principle – that the team should be self-organized and you should ‘trust them to get the job done’.

Transparency

Everyone can agree that transparency is important. Each agile team is supposed to provide full visibility of their work and time.

This allows the daily fluctuations of each team member’s productivity to become visible. Such fluctuations are normal, but in many cases instead of looking at the big picture, the team is focusing on the small issue. This leads to people playing a game of appearing productive instead of actually doing their job.

The team is afraid to make mistakes, which as we know are a vital part of any development process. This induces needless anxiety in the team members and at the end affects their productivity in a negative way.

Agile as any other methodology is just a set of guidelines to follow. It is not a silver bullet as you can fail spectacularly with it as you can do with any other traditional method. If you choose to ‘go agile’, you have to make sure you implement it properly and not go into extremes.