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.