My experience with SCRUM and 9 engineering practices

This week, I read 3 papers:

1) No Silver Bullet Essence and Accidents of Software Engineering (Brooks Jr., 1987)

2) The chaos model and the chaos cycle (Raccoon, 1995)

3) Scrum + Engineering Practices: Experiences of Three Microsoft Teams (Williams et al., 2011)

I personally like the third one a lot, since it’s related to my experience of working as a software engineer. In the past, I did apply Scrum methodology and engineering practices in my projects, so I would like to share my experience about it.

 

I\Some definitions

-       Scrum methodology: an agile software development process to iteratively and incrementally develop software. For developer to receive credit for his or her work, he or she must demonstrate the new functionality at the end of each short iteration during an iteration review session. 

-       Flaccid Scrum: a problem of a team applying only Scrum methodology that project's progress eventually slows due to the fact that the team pay too much attention on deadline but not the quality of code.

-       Product Backlog: documents of features (requirements)

-       Sprint: current iteration

-       Sprint Planning Meeting: A meeting of extended development team (including from project manager to developer, tester..)

-       Scrum manager: Project manager

-       Scrum review, Retrospective Meeting...

II\Critique for (Williams et al., 2011)

This paper demonstrated a case that when Scrum methodology is used with 9 engineering practices (recommended by Microsoft), the result is a stable, scalable product on schedule. 9 engineering practices are:

1. Planning poker

2. Continuous integration

3. Unit Test-Driven development

4. Quality gates

5. Source Control

6. Code coverage

7. Static analysis tools

8. Peer review

9. XML documentation

The paper described in detail the context of the experiment, and how the three teams worked, however, the scope of the experiment is still limited and the result may not be able to generalized. (Although limited in numbers of subjects and difference in some aspects between subjects are nature of researching in case study in software engineering).

As a developer, I can relate this paper to my experience in some aspects:

1. Scrum
3 years ago I worked for a software outsourcing company in Vietnam. At this time I didn’t realize that the manager tried to apply Scrum methodology in project management (although there were still some distinctions):

-       He himself gathered the requirement to write Product Backlog.  This practice is not good practice, especially for large project. In my opinion, the project that we worked on can be categorized as medium. The fact that he wrote Product Backlog by himself led to discussion and modification of Product Backlog, although he was an experienced manager.

-       He then asked for developers to estimate time to deliver code for each features. However, each developer chose a part that they wanted to do, and they did not estimate for parts other than their part. Again, this was not a good practice, since each part was totally estimated on subjective assessment of only one developer.

-       We met daily at 8am for Daily Scrum Meeting. In my opinion, meeting everyday is too much and not necessary.

-       Each feature was assessed on “one-or-nothing” basis. 3 years ago, I was a in-experienced developer. This policy really freaks me out!

2. Unit-Test Driven Development

One good thing about this project is that we applied unit-test driven development. We used NUnit to write unit test for each function. The developer handled all these tasks, but the tester might check both.

One negative side, it put more stress on inexperienced developer. Deadline is creeping upon, while you are writing unit test for each function!

But it turned out that the quality of code is excellent, and we did not have to come back and fix code of the previous Sprints very often. However, what sometimes happened was that the deadline for each Sprint was extended sometimes. Working overtime is not a strange term to all of us.

3. Source control: Tortoisesvn

 It’s free yet powerful. We didn’t experience any big challenge working with it

4. XML documentation

I learn about automatically generating XML document for public functions in university, nothing special to tell about it.

If I am asked what I would want to do if I was the project manager, to which I will answer:

-       Planning Poker is a good practice that needs to apply. At the beginning of the projects, the whole extended team must gather and present about how they analyze the projects, how they estimate each features. Discussion would be held to find the closest estimation.

-       Estimation may also take into consideration the experience of developers. The purpose is that not to put so much stress on new developers.

-       Peer review should also be applied to help new developers.

-       Other positive activities that we implemented such as TDD and XML documentation will be used.

Reference

Brooks Jr., F. P., 1987, No Silver Bullet Essence and Accidents of Software Engineering: Computer, v. 20, p. 10-19.

Raccoon, L. B. S., 1995, The chaos model and the chaos cycle: ACM SIGSOFT Software Engineering Notes, v. 20, p. 55-66.

Williams, L., G. Brown, A. Meltzer, and N. Nagappan, 2011, Scrum + Engineering Practices: Experiences of Three Microsoft Teams: Proceedings of the 2011 International Symposium on Empirical Software Engineering and Measurement, p. 463-471.