Scrum Issues And Organizational Change

We are working on quite a few client projects where Scrum is being implemented at the project and/or grassroots level in companies. In some cases, the "management" had got the concept of agile development and specifically, Scrum, pretty quickly and wanted to do it properly. In other cases, there was a willingness to try it, but need to mask it to upper management. (Both of these have approaches in their own rights, and probably worthy of further blog entries).

In terms of client engagement management, I find that I spend most of my time making sure those who are doing it (grassroots, masked, or otherwise) really do follow the rules. This makes for some interesting engagement management, when you are not actually part of the client project team (ie you are a chicken with "special mentoring powers"). In the last week, we have dealt with the following issues:

• Product Owners creating a Product Backlog with tasks mixed with features (so, get rid of the tasks)
• Non-Finetix resources, who are supposed to be part of the Scrum team, breaking ranks from the team to do a whole lot of "cya" (an ongoing re-emphasizing of team dynamics and encouraging the team the provide the corrective action)
• Product Owners being trying to make technical design decisions, masked as "I only want to make sure this will work going forward" (so, general beating up of the Product Owner and reinforcing the fact that the Owner only needs to know the "What" and not the "How" - also, "why should are we designing for something not in this sprint's requirements again ?".. pleasant amount of silence to that one !)
• Teams trying to over-engineer the data gathering of tasks, estimates, actuals, work left, etc. (so, you only need to worry about the work (and time) you have left to get the Sprint completed)

The good news is that some of these cases come from newly formed Scrum teams which are only in their 2nd iteration, and that actually did a great job on many other levels first time around (one of our teams total work done was only 2% out from what they estimated). And they delivered, which is the most important thing.

Based on our conversations with folks at our seminar last week, and with some of our current clients who are looking to expand out their "grassroots" agile development, it seems that we hit many issues very quickly in the adoption of agile in larger organizations or at the enterprise-level. Most of the issues, however, seem to be derived from the resistence to change that exists as a result of historical problems. Examples:

• Analysis, development and QA teams are in different locations, so how do we have a cross-functional co-located Scrum team ? (There are a few ways around this, but the cause seems to be "well, if we are going to fail in development, we might as well do that cheaply by offshoring it").
• What does middle management do, when full-blown Scrum is adopted at the enterprise level ? Found some decent discussions here from the Scrum Alliance
• How do we build an agile organization which is multi-faceted in terms of its functions and alignment (e.g. analysis, management, development, QA and aligned by line of business, domain and techonology expertise,) ? Some further discussions here
• Existing development methodologies and minimum standards/expectations for documentation (CMM Level 2 in most cases). Many of the controls are in place because of the poor performance (people, process, etc) of the existing development methodologies. Becoming "light" on documentation and upfront "specification hell" is very tough for orgaizations to move away from. At the end of the day, there has to be some mutual agreement about ensuring the "right" level of documentation is left as a residual of the project, rather than being created upfront. Secret is to get them hooked on the delivery and wanting more of that ...

Rant over for now ...