Common Road Blocks to Being Agile

Why is adopting Agile sometimes difficult? Many companies have had a lot of success implementing Agile, but many are still going through the transition

One of the most positive outcome of Agile is ,It promotes teamwork, gives the Scrum members frequent positive feedback, as well as sense of being involved in important decisions and having control over the Application.

 Here is the list of factors that can freeze transition to Agile.

Ø No team - Without the Scrum team, there is no Agile. The team comes together for a definite period of time, it consists of people who know each other, are comfortable with each other.Random groups of individuals, resources provided through shared services,multiple billings and partial allocations just won’t do. The management should carefully consider each team structure, size, as well as roles and personalities, and give the team time to form and norm.

Ø Isolated teams - An ideal Scrum team is co-located. Sadly that’s not always possible. Having team members in different geographical locations and time zones can definitely reduce the team’s ability to collaborate. If the team cannot be co-located, technology can help getting the scrum members closer together. Video conferencing, screen sharing, instant messaging are simple ways to establish trust and promote communication.

Ø Workload - Too much or too little work can impact the team's ability to establish its pace and start performing. Expecting the team to work on multiple projects in parallel and constantly switch gears can be confusing. Companies deeply involved in Waterfall are used to quickly scale the resources up and down to answer the needs of each individual project, but in Agile the planning should revolve around the existing teams.

Ø Product Owner Involvement – It is not enough to reorganize the Dev teams to adopt Agile. The  Product Owner have to be deeply rooted as well. They need be ready to build roadmaps and draft backlogs keeping current happenings in mind. Assign the Product Owner role to one of the team members. It can be a Business Analyst or an engineer (developer or tester) who will be in touch with the Product Manager when he or she is available and communicate the requirements to the rest of the team.

Ø Unplanned Branching technique – Do multiple teams submit code changes to the same branch? Are hotfixes and releases shipped out of the same branch? Do developers check in code that didn’t pass the build or unit test? Each of these factors might become a showstopper and prevent the Scrum team from delivering a meaningful incremental slice of functionality at the end of the sprint.

Ø Cumbersome deployment procedure to QA environments –Deployment to QA environment may require time and effort, regardless of whether it's a client-server or cloud based solution. The hand-off between developers and testers should be an easy hassle-free process.

Depending on technical process, there might be a need to submit tickets, engage deployment teams or DBAs,setup new environments, as well as refresh. These activities put the sprint deliverable at risk.

Ø  Regression testing – A long manual testing cycle at the end of the release is typical for complex large scale legacy systems. One remedy is continuous integration and Automation testing. If that’s not available, Scrum teams can deliver small chunks of completed functionality at the end of each sprint through the patch and have a “hardening” sprint (or number of sprints) at the end of the release to perform a full-blown regression testing.