As both a corporate employee and a professional consultant, I have been involved with projects which have followed the agile development lifecycle. This year marks the ninth year for me to be working on or with agile teams. Looking over nearly a decade of agile development, I've concluded that there have been three core challenges projects have struggled with in trying to be fully agile.
#1 — Use of the Right Business Resource
The idea of having an agile team work in small segments (sprints) to continually deliver functionality sounds great to everyone sitting at the stakeholder table. From the technology side, continuous progress and results are easy to visualize — yielding value to the corporation. From the business point of view, features and functionality are delivered in small segments — avoiding the challenges associated with waterfall-based release cycles.
Where I have seen challenges, is with the business not offering up the *right* resource to be a member of the team. More than one time in my career, the business initially agreed to provide a resource, but later only allowed for a small percentage of the individual's time — which led to stories falling through to the next sprint due to the inability to gain proper understanding and to provide demonstrations of the functionality. What made things worse is the case when the individual provided doesn't have the breadth of knowledge to be an active member of the scrum team. In this example, the business manager referred to the person as a "liaison." This basically translated into the liaison having to continue to work with the individual who should have been on the team all along - acting as purely a messenger.
Without the right dedicated business resource in place, agile teams will continue to struggle to reach the performing stage, as defined by Bruce Tuckman.
#2 — Lack of Dedication from IT decision-makers
Similarly, I have seen a situation where Information Technology (IT) itself fails to fully dedicate resources to the agile team. In one example, the team was performing quite well until a legacy application encountered an issue. Since two of the agile team members maintained the most knowledge of the legacy application, they had to stop their sprint work in order to work on the legacy application. Instantly, the burn-down chart became a burn-over chart.
What made things worse in this case, is that the fixes to the legacy application led to future enhancements, which were placed on the same two developer's priority list. Here, the IT leadership made the decision to impact the agile team instead of working toward reallocating other resources to work on the legacy application.
Without IT itself dedicating full-time resources to the agile teams, the agile team will also struggle to reach the performing stage.
#3 — Not Following the Cadence of Agile
The last challenge that I have faced... and faced the most, is with projects failing to truly follow the cadence of agile.
The first example is as simple as the stand-up meetings. I recall being on one project where the daily stand-up meetings of a team of five lasted as long as 45 minutes. While I attempted to mention taking the conversations outside the stand-up, doing so did not yield the results I expected. The thought was that everyone should need to hear this information. I did not agree, given the contract resources which did not need to understand most of the details discussed.
Another example is how multiple projects failed to schedule all the necessary meetings. The most common meeting that was not scheduled, was the sprint retrospective. I did not understand this thought pattern, since the retrospective provides an opportunity to discuss the positives and negatives during the past sprint. I've also seen where retrospectives were scheduled, but were not considered a high enough priority for everyone on the team.
Lack of understanding the components of the agile lifecycle will result in teams not reaching their full potential, which has the same result as the two other challenges noted above.
At the highest level, it is easy to see why agile development is popular and preferred over alternative lifecycles. However, challenges quickly emerge when either the business or IT group fail to dedicate the necessary resources required to build successful agile teams. Additionally, understanding and following the agile cadence is just as important to guide each agile team toward the goal of reaching the performing stage.
Have a really great day!