Real Scrum, Pseudo Scrum

Before we embarked on the current, real scrum project, we did a project with pseudo scrum.

A big project was on the way. An enthusiastic engineer and his manager thought of giving scrum a try. They approached the company's project management department and the like minded project manager picked up the idea. None of these were trained in Scrum. They started reading the bible - Agile Software Development with Scrum.

The three musketeers got buy in from some more people and the project began. While the project was in progress, they fumbled, they sinned. Their daily scrums went on for 45 minutes!. They did not track remaining hours and there was no burndown chart. Developers flaunted their individual achievements in the sprint demos. They could not fit QA in the scrum and had to resort to parallel staggered QA sprints.

But they did not let the scrum spirit die. They religiously followed the incremental approach, their design decisions were based on the team consensus. The stories were end to end. They wrote lots of unit tests. The incremental, iterative approach caught on momentum. The engineering enjoyed it, the product rejoiced it. Their good karma paid off and project was a huge success! QA was amazed with the code quality.

They were able to build a new website with a complex domain model in mere 4 months. The whole company was amazed with this success. The success got them thinking about scrum seriously.

Few months passed by. A new big project was about to come. The project management team, realizing power of the scrum, decided to get Scrum Master Certification training. The training opened their eyes. They realized what they did wrong, as well as their good deeds. The training was just about right for the people who have tried scrum once.

This is how the current project began. It is our first attempt to implement text book scrum - the real scrum. I will keep you posted about our experiences through this blog.

I strongly recommend - just try it out! Once you try it, you will realize why it works

Company Policies and The Team's Design Choices

Our company is becoming more and more corporate day by day. Ironically as it becomes more corporate, it tries to adopt more agile methodologies.

One of the company's director is an expert in databases. Some teams in the company regarded him as a data architect. Eventually he was officially appointed as the data architect few months ago. We were asked to consult with him for any database schema design or other database related issues.

The data architect then took it upon himself to standardize solutions across various teams. He came up with a database schema design for a feature and proclaimed that every similar feature should use the same schema. Everybody, albeit reluctantly, agreed with his schema design. Now when a similar feature needs to built as part of the sprint, the developer who was reluctant (let's call him "A') in accepting the architect's schema design has to face the data architect again.

'A' rebelled and came up with a simpler easier domain specific schema design instead of the architect's generic schema design. He emailed the design to the team on the mailing list. A team member (let's call him 'B') spotted the inconsistency and asked the developer to reuse the architect's schema. This attracted manager's attention and the manager too asked 'A' to get the data architect's approval.

A meeting was setup to discuss the design with the architect. As expected, the architect and the manager opposed the idea of deviating from the standard, already agreed upon design. 'A' is very unhappy as he will have to now code a complicated solution.

This incident raises many questions. Should the scrum master intervene? He did not and he should not. Design is the team's responsibility and the scrum master should completely leave it up to the team.

What is the manager's role? Should he be involved? This is the grey area. In an ideal scenario, the manager should let the team figure out the design. But in large corporations, they often have policies and procedures which cannot be thrown away because one team is implementing scrum.

What should the team do? Other team members should talk to the unhappy developer and try to comfort him so that his productivity is not affected.

Day 2, Sprint 2 - User Story Granularity

We are in sprint 2 of a project. People are debating about the granularity of user stories. Last sprint user stories were very easy - e.g. come up with database design. Such issues did not require any coordination between the team members.

In this sprint we have chosen stories with multiple components. People are getting anxious as they will have to now depend on other people to finish their work. There is coordination involved. For example schema design has to finish before the web application functionality or service layer can be built. If schema design task of the same story is chosen by developer A and web application functionality is chosen by developer B, developer B has to co-ordinate with developer A. Developer B cannot start before developer A finishes his work. To avoid this, developer B comes up with cool idea of splitting the story into two stories - database design and web application functionality where database design can be scheduled in this sprint and web application functionality can be built in next sprint. Developer B calls it as a Common Sense Approach.
This common sense approach does not make sense because of following reasons:

1. Scrum emphasizes on self managing teams. It is very important that the team learns how to manage itself and how to collaborate with each other.
2. The use cases or user stories are supposed to be written more in use case manner. They must be business oriented. The stories must not be engineering driven, but strictly business driven. The stories in sprint 1 were not written correctly. They should have been written more in business manner.
3. First schema design, then serially building functionality of web application sounds more waterfally. Using agile processes schema design and building web application functionality should be doable in the same iteration.
   

Scrum Master called a meeting to explain why we cannot have stories like "Come up with schema design". He drew the following diagram :

He explained to the team that Scrum encourages to build a narrow piece of end to end functionality instead of artifacts such as schema design so that it can generate maximum business value. This also facilitates the feedback loop thereby giving product managers a chance to refine ideas on the product. People seemed to be convinced.

Day 1, Sprint 2 - Who does QA?

Sprint planning meeting went well but in spite of spending 2 hours and 40 minutes we could not allocate all the time at hand. We had about 700 hours at hand, including QA. We were able to allocate only 430 hours in 2 hours and 40 minutes. There were two QA persons. They ran out of all their time. How do we handle this? We had following options:

1. Scrum Master goes to QA manager and demands more QA resources for the project
2. Developers take up some QA work so that amount of QA work required can be divided in QA persons and developers.
   

Scrum Master mentioning second approach was met with wide eyes from the team! No decision was taken in the planning meeting. We had to stop the meeting because the conference room was booked then after.

The Scrum Master spoke with QA manager but QA manager expressed his inability to get more resources. The idea of doing QA was discussed a bit in the morning meeting, but since most of the team was not interested in testing, the Scrum Master abandoned the idea of asking the team to qa their peers work.

It was decided later in the day that the team will work on infrastructure or any other issues they want to work on in their remaining time. That work will be considered "extra work" and will not be demoed in the sprint demo.

In true spirit of scrum, I think we, the developers should have taken up job of testing their peer's work. But I can understand that this is not easy to sell it to developers.