In today’s project-based IT environment, there is a widespread adoption of Agile to give the much-needed thrust to derive better value for the projects undertaken by enterprises across the globe. Everybody knows how Agile is beneficial in meeting complex market demands, but people are unaware of certain practices, which completely derails your Agile project from the go.
Below mentioned are 10 such dubious practices that destroy an Agile project.
-
By not creating a comprehensive plan upfront:
Many enterprises start a crash project with huge spending without having a comprehensive plan upfront. The main objective of Agile is to break those communication barriers and have the team members to work on what users need and not on something that is being pushed by a committee through big documentation. Agile teams are small and tight and it needs a simple communication channels to work efficiently.
Whereas in crash projects where you put all your resources in one basket at the beginning it does not give you ample amount of time to create a proper plan. This will create difficult situations for teams on many fronts from the beginning. The best way to go about a crash project is to have a small team of developers and architects who have worked successfully in the past and add team members only if they ask for them. -
By creating a fixed schedule and price:
You may as well argue that having a fixed schedule and price from the beginning will bring in the necessary discipline for a project from the start. But what you forget is that Agile is all about flexibility. Agile is user-centered, and tests are conducted as and when codes are being written and re-prioritizes requirements throughout the project lifecycle. With Agile, you will see reduction in wastage, as things that you do not need will ever get started in the first place.
Therefore, when you have an Agile project with a fixed goals, schedule and budget, it acts as a deterrent for Agile teams to improve on the features or to stay abreast with current market demands. It only creates friction within and outside the team and it deprives the project to realize the benefits of implementing Agile. -
Demanding huge documentation and lot of standards up front:
Agile is completely different from the traditional project management certification course and it does not required huge documentation and importance on lot of standards up front. Agile thrives on incremental add-ons and integration of certain key features with existing functionality to meet future complex demands. Though Agile requires careful planning, there is no need of using huge documents and frameworks such as ISO 9001, ITIL, Six Sigma, and more. They just act as a deterrent to the flow of Agile.
-
By not letting users to participate until the very end:
Though enterprises implement Agile, they still are sucked in to a mix of traditional project management where the user does not have a clue what is getting built. Agile projects need continual contact between the user and the developer throughout the project lifecycle. Agile is not just user-centered but it is also has all important connections with processes, team know-hows along with continuous user testing to avoid major bugs in the future.
Many project managers argue that they cannot afford to have a user on the team, but then you are arguing that you want to build a customized interior design for your home without visiting the site during its construction. Now that would be insane right. So why do you want to let that happen to your organization’s IT investment? -
One step forward, two steps back:
Agile project is all about collaboration between cross-functional teams who innovate on the move. To make this happen there needs to be a lot of continuity of effort and objectives. Some priorities shift here and there, but if the main objective / purpose of the project jumps like a wild horse, then all the efforts will go in vain.
So if there are regular interruptions of a longer duration with no continuity, the project wheel never gets a move on. Agile is all about continuity, and due to various factors if the projects gets restarted from a standstill point it is far worse than starting from the beginning. -
By caving in to the customer demands regularly:
Yes, this happens a lot and you cannot ignore it anymore. Some customers are a challenge to deal with. When you have such customers, the role of scrum master just narrows down to just defend the team from the external forces in order for them to be successful. And when the executive caves in for the demands of the customer where he / she is lot more interested in the money aspect than how his / her team is treated.
Agile experts believe some of the executives cave in to the customer demands just to satisfy their vested interests. In such scenarios, it is the team that is given the short end of the stick. When this happens, there is a lot of friction between the team, scrum master, executives, and the customer. In short, when you cave in to the customer demands regularly, your project’s fate is doomed. -
By not using best personnel for the job:
How many times have we seen that a project derail by not using the best available resources. Agile is all about having those cross-functional teams who collaborate to the best of their abilities and successfully complete the project. Agile experts are some of the smartest bunch of people you will meet. They know that it takes a team to finish the job and the team members must respect each other. If not, there will be communication gaps. Even the location of the team matters a lot, the team members to be within shouting distance, and the productivity rate goes down if the team is spread across different time zones.
-
By not sharing company goals and objectives with the team:
You may think who even does that, but surprisingly many enterprises across the globe do not share their goals and objectives with their teams. It is like you do not know the destination but you are already set for sailing. The best part is executives wonder why their teams are not being productive all along. It is because they do not know where the company is heading or what its main objectives are. The Agile teams will be scattered around different directions with complete chaos.
-
By not giving teams access to test resources until beta:
Somehow people believe the testing part of the project is dull. Because there is continuous building and changing or the product and there is an endless work of testing which can be a bore for the compliance team. Moreover, the test labs have limited availability for teams.
What could be duller than testing? Seriously, the continuous building and changing of agile software makes testing an endless chore for the users and a bore for the compliance guys. Besides, the test labs can’t afford to be available all the time. These are some of the arguments that you get to hear from project managers and other stakeholders in an organization. But Agile works on continuity principle where as and when the code is being written the test team will be testing for bugs. By testing throughout the project, beta version won’t be necessary at all. The software that you are building can just migrate into production when it’s ready.
Agile is all about flexibility and continuity, and you take away these two important components, then see how Agile melts down. The above mentioned dubious practices are some of the most prominent ones, there are many such practices which acts as a hindrance to your Agile project. Do let us know in the comments section if you think there are other such practices which could have been added to the list.
