The Dirt on Scrum Development

Using the Wikipedia article on Scrum development (http://en.wikipedia.org/wiki/Scrum_(development)) as my starting point for discussion below, this posting will detail my own experience. In this case, I was part of a very large team working to produce a complex portal application. Although we had not dictated we were following "scrum" (having simply deciding to follow an Agile approach), I see now where this fit in with my experience.

Characteristics:

Our project had a process skeleton in place, with a set of practices and predefined roles.
Our predefined roles included a Product Owner (a customer voice representative embedded on site), stakeholders, a program manager who filled the ScrumMaster role, and a Team of subteams (a requirements team, a framework team, a database team, a developer team, a test team and a training team).


Evaluation:

One setback our team faced was that our practices changed over the course of the project as we started to determine better what did and what did not work. As a result of the learning curve to implement new practices, there was some delay in getting the project really churning.

The boundaries of our roles started to blur as people stretched outside of their area:

• Developers started trying to fix framework problems or make database changes
• The database team started to add or modify tables without notifying the team, which caused compile errors
• Developers observing problems during unit testing started driving requirements
• Requirements folks started trying to drive design

In looking back, as part of the developer team, our "sprints" were two weeks long in duration.
During this time, we created our package of "potentially shippable" software.



Roles:

The Wikipedia article defines "Pig" roles of a Product Owner, a ScrumMaster (or Facilitator) and a Team. "Chicken" roles consist of Users, Stakeholders (Customers and Vendors) and Managers.


Evaluation:

Our project became a failure as the Product Owner wrote User Stories that were so vague that it was hard to match up with the list that the requirements team had produced. Stories were prioritized and placed in a Product Backlog.


Our project also failed because the ScrumMaster tried to be the leader of the team, a situation which was implied as he happened to be a program manager for the company. Wearing two hats for him was a problem.

After months of development had gone by, it was also revealed that the Product Owner was not accurately conveying the voice of the customer. In addition, the Stakeholders had signed off on the prototype initial look and feel (i.e. show these tables on these pages), and when it was built out that way, numerous changes were requested. Of course all this snowballs into a list of RFCs which dramatically increased the scope of the project and produced delay.

Meeting:

This method calls for a daily status meeting, or scrum, also called "the daily stand up". The article describes the specifications and what is to be covered. Following each sprint cycle should be a "sprint retrospective", which is basically a lessons learned.


Evaluation:

I'd say that our team held to the principles of the scrum meeting pretty well. The only issue we seemed to have was that the ScrumMaster had to be continually reminded about obstacles in our path of success. The ScumMaster was always being pulled into higher level management meetings, and as a result was unable to act effectively. Our retrospectives enabled the team to define additional required training or cross-training opportunities for team members. In addition, this created a chance for people to visit with folks in other roles to see how one area of work impacted another. This lead to increased understanding and anticipation of the needs of another team.

Artifacts:

The Product backlog is a high-level wish list of what should be built that everyone should have edit access to, with the Product Owner setting the business value and the team defining the development effort.

The Sprint backlog is a granular, unassigned task list broken down into units less than sixteen hours wherein team members sign up for tasks as they wish.

The burn down chart is essentially a task list for a given sprint that indicates which tasks have been completed and which are still remaining (claimed or unclaimed).

Evaluation:

In our project, the Product backlog was not open and editable by anyone other than the Product Owner. The ScrumMaster would provide the development effort only based on sprints. As the project fell behind and the scope kept increasing, the customer demanded that we stop all work and match each requirement (I'm talking in the neighborhood of 50,000 + reqs.) to the corresponding item in the product backlog. I also think that the Product Owner may have not had adequate tools to track a project of this scale. I would recommend looking into workflow products other than just MS Project, which became a beast for the Product Owner to manage effectively.

In our case, I'd say we never implemented the Sprint backlog as described above. The developer team was broken down into different folks being responsible for different component areas of development since the requirements list was so massive. As a result, if your component had work listed for the next sprint, then you had the duration of the sprint to get it done.

Our developer team implemented a burn down chart later in the game, and this became an unanticipated source of animosity. While it was later used for reallocation of resources, it initially became a source or pride or embarrassment. Some developers finished building their assigned components quickly, while others appeared to be lagging (though no fault of their own, this was often due to external dependencies such as database updates or a completion of a linked component). The whole team never had a consolidated accessible burn down chart.

Adaptive management:

Concerning the general practices of Scrum:

We did have the customer heavily involved. However, debate raged within the customer organization as to the selection of the Product Owner and stakeholders. It became highly politicised as each organization had a different vision of what the end product should be and how it should look.

As an agile process, we did provide frequent, functional intermediate deliveries, which allowed requirements and priorities to change. However, with this comes an increase in scope and change in project schedule.

One thing we clearly were missing was a plan for Risk Mitigation, Monitoring and Management. Only when the project was way over budget and delayed numerous times did we put a plan in place to tell the customer that if they wanted change X, here was the cost, and make them approve it.

While we did have some transparency for module development, it seemed to only exist from a given team's perspective. I do not think that we shared a complete overall vision. At the developer level, we only ever seemed to be aware of planning in regards to the current sprint.

We did provide routine stakeholders meetings via the sprint reviews (which as mentioned above had an impact on the project schedule), but what we did not have in place was a mechanism to alert the customer of potential schedule slips.

Conclusion:
While I think that with some modifications, Scrum may be a workable model for development on SMALL applications, I think that large-scale enterprise application development is hampered by it. The Scrum article describes the Team as "5-9 people with cross-functional skills to do the actual work." We had at least fifty developers on this project and were comprised of at least six sub teams! Hopefully this article provides some lessons learned to other organizations.