In my last blog entry, I wrote about an agile review that I was preparing to conduct with one of my teams. This team began using the agile software development methodology in earnest in late July after receiving training. At that time, several experienced agile scrum masters and independent coaches were inserted to help guide the transition. I noted specifically that the team has some characteristics that make an agile implementation challenging and success uncertain: the team's overall size is greater than 80 individuals and growing; there are inter-organizational and leadership dynamics in play that could derail the implementation; and the technical environment (SAP), with its functional orientation, poses a unique technical challenge.
The data-gathering portion of the review ended on October 8. As hoped, the number and variety of input sources and forums for leaders, coaches, mentors, practitioners, and customers proved to be quite robust. Indeed, this review approach yielded more data than one could hope to analyze in a short period of time—particularly when other responsibilities begin to intrude. Despite my initial worries, gathering input is the easier part of the review. What remains is much more difficult: fully understanding the data that was gathered, deriving major themes, identifying recommendations, and implementing those recommendations, as appropriate.
While the review is still incomplete, some themes have begun to emerge that suggest the characteristics of this team's working and technical environment are not driving a significant number of unique challenges and problems. That is, many of the concerns raised by the team and their leadership are reminiscent of earlier agile implementation experiences: difficulty breaking down epic user stores, an initial inability to size in story points, general role confusion, problematic team communications, and getting good quality user stories and acceptance criteria. Nonetheless, there are some themes that do appear to be unique or, perhaps, this team has a different spin on an otherwise generic theme.
Iteration planning is of particular concern in part due to the functional orientation of the team and the underlying product. The functional orientation of the product makes planning an iteration challenging in that the stories selected need to match the team's composition or the work contour will be uneven. This implies that a potentially higher priority story might have to take a back seat to a slightly lower one because resources may not be available to complete it during the iteration. This is not wholly unique—other agile teams also run out of resources—but it is more acute because the functional breakdown of the team is so granular. To smooth out the work contour means you need to know more than just the team's velocity. As one colleague aptly put it: you need to identify and understand the micro-velocity by functional orientation to be successful. In addition, the team does not have a rigorous planning background to fall back on: they are learning it as they learn agile.
The technical infrastructure surrounding the application and the functional orientation of the product presents unique challenges. The inter-dependencies between modules (which also effect planning) are somewhat mind-boggling. Too, the ability to keep various environments synchronized has become an issue, though not one due to the implementation of agile. Regardless of the source, it is clear these items will need to be addressed as they are a systemic source for blockers during and after an iteration.
Meeting overload. One of the things that came through loud and clear was that practitioners and leaders felt that they were attending too many meetings. The team itself is distributed, so some "meeting creep" is expected, since in-person communications are not always possible. But, the prevalence of the sentiment shows that it is a larger issue than just adding a 15-minute scrum and another 15-minute scrum-of-scrums call during the day. While there are instances of people who do not need to attend certain meetings being expected to attend—much of which has already been rectified—we failed to consider the impact of these additional meetings on an apparently already busy meeting schedule. In fact, existing meetings have grown to encompass much of the same material covered in the scrum of scrums meaning we now have some redundancy.
More to Come
Preliminary insights are just that: preliminary. They only give a hint of the direction you may eventually need to follow. Assuming I can wade through all the data with my review team in a timely manner I am sure we can figure this out. I am also sure we will find a lot more.
Post a Comment