Are you here to produce better software?

Pete Deemer, the scrum coach and trainer was holding a question hour for one of the scrum teams in our company. One of the developer expressed resistance to testing code instead of a qa member testing the code.

Previously, the scrum master had repeatedly suggested to this team that developers should do some testing that normally QA does as they have smaller QA capacity. Developers were reluctant to do that.

The team member who brought up this point during the question hour strongly felt that scrum master is pressurizing them to do QA. The team member thought that he does not have the necessary skills (automation etc.) and in spite of that Scrum master is pressurizing the team.

Clearly it was a revolt against developers doing QA. Pete listened to him attentively while he was venting off his strong resistance for testing. After he was done with expressing his anger over the developers being asked to do QA, Pete asked a simple question: "Are you here to only produce code or to produce better software?". Pete further added, "if you think you are here for producing better software, then you should do everything that is needed to produce better software. That includes testing, setting up machines, merging branches etc!"

I think this question is a very important tool to scrum masters. Developers need to think again and evaluate why they are here. If the answer is - they are in the team to produce better software then they should be willing to do all the other stuff that developers generally don't like.

Sprint 4 - Long running Sprint Planning meetings

Since two sprints, we are noticing that the sprint planning meetings are going over 4 to 5 hours! Sometimes, we can't get a conference room, and we are forced to split it into two sessions.

After analyzing the reasons for these long meetings, we realized that our stories were complex and most of the time was spent in discussing requirements in the sprint planning meeting. Many times product owners ended up changing stories after discussing them with the engineers. Product Owners learn about technical dependencies over other stories or they choose to break up a story in a different way after discussions with engineers. Engineers even point out inconsistencies in the stories e.g. xyz tab lists contacts in ascending order, why is the order different on this tab? Most importantly, many times engineers pointed out the missing pieces in the stories.

This dialog between product owners and engineers needs to happen on consistent basis rather than just in a sprint planning meeting. Product owners should consult with experienced team members after writing a story. They can forward the newly written story to an experienced team member and ask for his/her feedback. They can ask the engineers to estimate points for the stories so that they can decide whether to break the story or not.

The team should help product owners to evolve stories. We have constituted a weekly hour long meeting for playing planning poker. Planning poker forces the much needed discussion about future stories between the product owner and the team. But these planning pokers are not sufficient as the focus of the meeting is just to know enough about story so that it can be scored. They should be supported by informal hallway discussions and mailing list questions.

Incremental, Agile QA

Incremental QA is highly desirable in Scrum. Scrum does not distinguish between development and QA as in waterfall model. It expects that the product feature you are working on is designed, developed and tested by the end of a sprint - One sprint does it all.

Here are some important characteristics of incremental QA:

1. QA developers are part of the team. Scrum does not distinguish between QA developers and other kinds of developers. They all are part of the same team and are equally responsible for the success of the sprint. The team is cross functional.


2. Builds are given to QA more frequently. Daily builds are recommended. We have even delivered builds twice or thrice a day depending on the issues QA has found. If the issue is simple to fix, fix it and deliver the build immediately. Your build process must be capable of delivering a build to QA in a short time.
   


3. QA develop automated tests while developers are coding user stories. These automated tests will be used in the current sprint as well as in future sprints for regression tests. Tools like Selenium and Fitnesse are used to achieve high degree of automation.


4. Close coordination is required between developers, release engineers and QA. As new features are completed, the changes must be pushed to QA environments as soon as possible so that QA can begin. This means you need to have an efficient process to create QA environments. As soon as a bug is detected, it should be communicated to developers and developers should deliver the fix as soon as possible.


5. Sometimes, partial testing is done. A developer may not be able to complete an entire story at once. He/she may deliver whatever has been completed to QA - may be 70% of the requirements. The developer communicates this to QA and expects QA to test only the portion completed.


6. Developers take up testing tasks, if necessary. They can test their peer's code if there aren't enough QA engineers available to accomplish the testing required for the sprint.

If your team is getting QA done in a way described above, you may pat your back as you have achieved the holy grail of incremental, efficient and agile QA.

How to start Scrum in your orgnaization?

I met a group of people who were doing Scrum without really understanding the Scrum values. They had a backlog, were doing daily scrums, giving demos and were doing Sprint review meetings. Product people were not involved. The demos were internal; the backlog was created by an engineering manager, QA was not included in the scrum; database design was done in the waterfall way!

Can we say that this group is doing Scrum - no! Most of the times, people tend to read one or two articles on the internet and think that it's a cool new idea, lets try it out. I think it takes much more to implement Scrum. The person or group of people initiating Scrum in your organization must be detail oriented. He/she must read Agile Software Development with Scrum first. The person should understand what real scrum values are and what they must do and what they can skip. If the person doesn't have time to study scrum in detail, get a consultant for coaching.

Scrum is a big paradigm shift from waterfall. The organization implementing scrum should first recognize the problems with waterfall process and understand how scrum solves them.

I also think that the team implementing scrum needs to have certain maturity level. When we started scrum, we were already using unit testing heavily; we had continuous integration; we had coding standards in place; we were using confluence and making documents in confluence (wiki) instead of using word documents. We already had collective decision making in place. All these things helped us a lot when we started with Scrum. I think Scrum is much more powerful if used with commonly acknowledged engineering best practices. If your team is not using any of these best practices, its better if you start with these instead of jumping on to the scrum bandwagon.

Daily Scrum Mistakes

Daily Scrum is a very useful meeting. Everybody learns about other team member's status and their road blocks. If the team is using a simple chart on the wall to enter work remaining, this meeting also reminds everybody to enter their remaining hours. Here are some typical mistakes people do in daily scrums:

1. Reporting Status to Scrum master : I have observed that many people look at the scrum master while giving their status. They behave as if they are reporting to the Scrum Master. Scrum master should purposely try to avoid this eye contact to make sure that the team member reports his/her status to the team and not to the scrum master.


2. Design Discussions : It is very easy to jump into design if a team member is talking about a design problem as his/her road block. Scrum master has to ensure that the meeting is limited to reporting progress and roadblocks and not solving the road blocks.


3. Missing people : If the meeting is scheduled early morning or late evening, it is possible that some people may not attend it. The meeting should be kept at a time convenient to everybody. The scrum master should ensure that everybody is present in the meeting every day so that he/she listens to the entire team's progress.
   


4. Requirements Clarification : Small requirement clarifications that take 30 seconds are ok, but all other clarifications should be deferred for off line discussion.

People may get turned away if the daily scrums are taking longer. The scrum master should try to finish daily scrums in 15 minutes. The best way to discuss design and clarify stories is to conduct these meetings right after the daily scrum. You can announce a design discussion meeting in daily scrum and ask interested people to stay back. This ensures that only interested people stay back and you don't have to go through overhead of scheduling a formal meeting. Quick, informal, stand up meetings are much more efficient than scheduled, formal, sit down meetings.

Scrum Team Composition

Scrum Team composition is very important for the success of the project. I have experienced it at many occasions. Many times, when an organization wants to take up a new important project, they tend to form an all star team - a team composed of all senior and experienced developers. Such a team composition poses following risks:

1. Senior developers are more opinionated than junior developers. Thus imagine a team of 5 people, all stars, discussing a design. Everybody will have different opinions. Many times the design choice is not clear, it's philosophical. Such heated design discussions can cause a rift amongst team members.
2. If junior developers don't work with senior developers, you loose a chance of training your junior developers.

An ideal team size is around 5 to 7. If you have a complex project that requires a much bigger team, then the project can be split into multiple scrum teams. Bigger teams tend to have multiple internal groups (with different school of thoughts) and hence struggle to arrive at a decision.

The teams should be cross functional. It should have all the skills that are necessary to complete end to end stories - front end, back end, database, testing etc. The exact mix of these skills depends upon the requirements of the project. It is possible to change the team composition every sprint if necessary. But the changes should be minimal because changing the core team every sprint will impair the desired velocity.

Scrum provides a platform for open communication and collective decision making. Open communication will immediately bring the philosophical difference of opinion to the forefront. The scrum master in most cases should not intervene design / coding philosophies battles. But if it starts going out of hand and affects productivity, it is important that the scrum master talks to them and brings everybody on the same page.

Self Organizing Team

A Self organizing team is a very powerful concept that liberates the manager from the agony of mundane tasks. In most cases people are not used to managing themselves and managers are not used to not manage certain things. Here are some problems the managers face moving towards a true self organizing team:

1. Managerial ego: Some managers think "What would the team do without me?" The team needs my help to solve problems”. And they get satisfaction from the fact that they were able to help their team at every single occasion when the team needed his/her help. But in that process, they forget that they are making the team more dependent on him/her leaving him/her less time to do the real managerial tasks.


2. Fear of losing touch with details: They always like to know each and every minute detail so that they are aware of everything and can answer their superior’s detailed questions. However, in some organizations this quality earns them respect.


3. Forced involvement in development issues: Sometimes team members have disagreements amongst themselves on various issues such as design choices, engineering practices etc. Inevitably, these disagreements then go to the manager to get resolved. Thus, even if the manager is trying to stay away, he/she gets involved in the argument to save the productivity of team.
   


4. Fear of not doing things the right way: Every manager has his/ her perspective on what is right e.g. right engineering practices, the right way to solve a problem etc. The manager keeps thinking that if he does not make the decision, the team will solve the problem in a "wrong way". This keeps the manager more involved in small decisions.

It is difficult to achieve a truly self organizing team. It is very tempting to use the decision making authority you have as a manager. But if that becomes a routine, most of your time will be consumed in making small decisions that could have been made by some other team member. It is difficult to resolve the above mentioned problems. You cannot make your team self organizing in a day. You have to train your team for months.

After working for months to achieve a truly self organizing team, the result is gratifying. The gains are phenomenal. You can save at least 50% of your mundane work. This gives you that 50% time to think about future architectures, long term career development of your engineers, attend conferences etc. Your job will be much more interesting than it was before.

Is Checkstyle Agile?

The sprint review meeting was going on. Some developers expressed their discontent over checkstyle enforcement in continuous integration. They were unhappy because sometimes checkstyle prevented them from delivering builds to QA on time. To support their claim, one developer said - "I don' t think checkstyle is agile".

Let's first understand what is meant by the word "agile". The agile manifesto mentions following principals:
1. Welcome changing requirements
2. Deliver working software frequently
3. Collaboration between business and engineers
4. Sustainable development
5. Continuous attention to technical excellence and good design
What is the motive behind coming up with such a manifesto? - More efficient and cost effective software development. Why this process innovation? - To develop software in the least amount of time with the best possible quality a. k. a. saving money.

Now let's examine what checkstyle accomplishes. It enforces the coding conventions there by producing maintainable, consistent and more readable code. Sun's website for coding convention mentions that 80% of the lifetime cost of a piece of software goes to maintenance. Coding conventions play a big part in improving maintainability and readability of the software when you have multiple developers working on the same code base. Other developers can quickly understand a piece of code if it adheres to a standard.

Everything mentioned above is in line with the principals of agility. Enforcing coding conventions will allow self organizing teams to develop software more quickly and cost effectively. A readable piece of code can be easily worked upon by multiple people. Adhering to industry's best practices is in line with continuous attention to technical excellence. Furthermore, adhering to a standard will make the development process more sustainable.

Developers will always try to come up with reasons to avoid such enforcements. Some developers will also argue that agility means flexibility and hence they should be allowed to break the rules. Flexibility in agility implies the flexibility of changing requirements and not the flexibility of breaking engineering best practices. It's the responsibility of senior team members and sometimes even scrum master to make sure that the team is adhering to engineering best practices. Using right tools such as, AnyEdit plugin for eclipse, checkstyle plugin for your IDE will allow developers to avoid build failures due to this reason. The Scrum Master should intervene at such occasions and help senior team members in making their junior colleagues understand the importance of engineering best practices.

How to fit QA in Scrum Sprints

Many scrum teams have a tough time accommodating QA in the same sprint. They end up creating separate QA sprints and staggering it with development sprints. Thus development happens in one sprint and QA in the next. So agile, isn't it? In the true spirit of Scrum, stories should be finished with the necessary testing in the same sprint.

Here is how it happens. Let's say our sprint length is 3 weeks. We have two dedicated QA persons assigned to our project. They are a part of the team. First two weeks developers keep working on their code (and unit tests) and QA persons play ping-pong. In the third week developers start delivering code to QA. Now suddenly our QA has work! As all the tests are manual, one week doesn't suffice. Some stories get demonstrated in the sprint demo without testing! The remaining QA work then gets included in the next sprint. They finish the remnant work in a week and again play ping-pong for one week. Thus the staggered cycle continues.

There is only one way to break this cycle – QA automation. Automating tests with a tool like Selenium saves testing time considerably. It increases test development time, but it reduces testing time considerably. Thus when developers are coding, QA persons can develop automated tests instead of playing ping-pong. Once developers start delivering code to QA, all QA has to do is run the automated tests!

I have been playing with Selenium recently. It's really a great open source tool for QA automation. I found Selenium RC very useful for web based applications as it allows automated tests to run in various browser environments - Firefox, IE etc. Furthermore, Selenium tests can be developed in Ruby, Java, Javascript, Perl, PHP, Python and even .NET! QA can choose the easiest option for them.

Handling QA in Scrum environments requires a paradigm shift. Many companies don't have QA persons with coding skills. In such environments developers need to step up and develop automated tests. Gone are the days when a person went manually through each and every page of your website. Scrum requires much more efficient QA and thankfully Selenium-like tools provide the necessary technology.

Meetings v/s Mailing Lists

Some companies have a meeting oriented culture. They summon a meeting to solve each and every problem, however simple the problem may be. A meeting for designing a database table, a meeting for reviewing code, a meeting for clarifying a story, a meeting for getting extra RAM in your computer etc. If you try to measure the amount of time spent by employees in meetings per week, it might surprise you. Meetings are an inefficient way of discussing a topic. I prefer to discuss issues via mailing lists over calling for meetings. I and a friend of mine - Ken Weiner came up with the following advantages of mailing lists:

• Mailing lists are more productive, people don't have to repeat what they said as they get enough time to digest it.

• Email keeps track of the entire conversation. Some wikis such as Confluence also have a way of archiving a mailing list to make it searchable.
  

• Every person gets enough time to read the email and respond to it. In a meeting, one might not get enough time to respond.

• In multi-location environments, mailing lists are the best ways to keep everybody informed about everything. That's how the entire open source development works. Video conference / conference calls may not be feasible every time.

• Attending a meeting consists of higher context switching. You might be in your best productive time and you have to drop everything to attend a meeting. I personally hate to do that.

• In meetings some personalities can overpower others because of their voice, posture or even position etc. Mailing list avoid such overpowering.

• Sometimes uninterested parties attend meetings for the sake of attending. Discussing a topic on mailing list can certainly avoid this. The uninterested person can simply delete the email by looking at the subject.
  

Try to discuss as much as possible on mailing lists instead of calling for a meeting. Mailing lists can serve as an excellent reference for future. Some collaboration tools such as CollabNet can even capture emails sent with an issue number in the subject as a comment to the issue. Tools such as Crucible will help you in doing efficient code reviews. Wikis can help you discussing a topic as well as archiving a mailing list. As soon as you start your Scrum project, you should setup a mailing list for all the stakeholders. You will be pleasantly surprised with the results.

How to Justify Scrum to Senior Management

Often many people say that it is difficult to justify Scrum to the senior management. I think there are two alternative approaches you can take to justify Scrum:
If the senior management is willing to listen , you can tell them about the following scrum benefits:

• None of the software development methodologies can predict the exact date of software completion with exact amount of resources. In most cases where inputs and outputs are not well defined, empirical process control model is the only workable model for software development. Read chapter 5, Agile Software Development with Scrum.

• Prioritized product backlog ensures that 80% of the business value is delivered in 20% of the time. Read Appendix D, Agile Project Management With Scrum.

• Product gets a legitimate chance to change their product based on sprint demos. There is no need to file a change request and charge more in case of a fixed bid and/or fixed date contracts. Scrum being a transparent process, it gives more visibility to the management than waterfall, which provides no visibility till the time the product is finally released.
  

• Once Scrum is in place, it is possible to estimate release dates roughly based on historical velocity data. In fact, you will be able to predict release dates of the current project with 80% probability after 20% of the work is done - within 3 to 5 sprints based on the project size.

• Scrum exposes problems earlier, there by giving a chance for management to cancel the project if necessary.

• If you are a high maturity company, then using Scrum will improve productivity and performance significantly as concluded by Jeff Sutherlands's paper - Scrum and CMMI Level 5: The Magic Potion for Code Warriors
  

If the senior management is not willing to listen, you have no choice but to do the analysis first and give them a date. You may not be able to score with a management not willing to listen to new ideas.

Point Score and Work Remaining in hours

A day before sprint 1 was about to end, the scrum master, team manager and scrum-trained developer were sitting in a meeting room trying to figure out the co-relation between velocity and estimated hours. The question in front of them was - What is the guideline for the team to choose stories? Should we give them a velocity number or the team should make a decision based on total number of available developer hours?

If we are going to use the total number of available hours for picking up stories from the backlog then what is the purpose of velocity? Why do we estimate stories in points? Why use different units? Why not just use hours so that this whole estimation is uniform in hours ?

They had only one sprint worth of data. The team was new to Scrum. The manager felt strongly that they should give some guideline to the team so that the team does not overburden itself or does not take up little work. He also wanted to know the correlation between points and hours.

Here is what Ken Schwaber says in his book - Agile Software Development with Scrum "This (in our case the questions raised above) question indicates the difficulty shifting from a pert chart-based, time reporting structure to an empirical approach"

There is a difference between assigning a point score for a story and estimating hours for a story. Point score is the effort. Work remaining is the time (hours). The point score for a story is an approximate score. This score is used in velocity calculations. Product owner and the scrum master use this for release estimation and planning.

The team only uses estimated hours while picking stories for a sprint. They pick a story from the backlog and estimate the number of hours after clarifying requirements with the product owner. Estimating hours require more understanding of the story than assigning a very rough point score. Furthermore, estimation should be preferably done for tasks - at a finer granularity than story. A story should be divided into multiple tasks such as testing, coding, writing unit tests, coding UI layer etc. That makes a story more predictable. The team only deals in number of hours and specifically remaining number of hours. On realizing this, the manager stopped deriving the correlation between effort and time.

Why Agile is hard?

I was talking with some developers and a manager of a company in LA about their Scrum implementation. They told me about various problems they faced - no buy in from business, inability to estimate exact dates etc.

Interestingly, at the same time, I happened to listen to Why Agile is Hard - The java Posee round up 08 podcast. Same problems were discussed in the podcast. The podcast mentions many interesting books and websites for agile followers. If you are an agile devotee, you should definitely listen to this podcast.

The developers from the company also talked about implementing Scrum only in the engineering team without getting buy in from the business. The business will give them a document of requirements which will be translated into user stories by a team lead.

One developer even told me about doing database design out of scrum sprints to avoid future changes. I think this is fundamentally wrong and against the spirit of Scrum. This is a typical case when unit tests are not implemented. Code without unit tests is difficult to re-factor hence developers tend to think about future requirements; there by defeating the purpose of iterative and incremental approach

Their other problem was accommodating QA in a sprint mainly because the testing was manual. I tried convincing them QAing within the sprint instead of doing staggered QA sprints. I suggested that they should try to automate the tests. While developers are working on the code, QA should work on creating / changing the automated tests.

They hadn't read the bible - Agile Software Development with SCRUM (Series in Agile Software Development). I suggested them to start with the book. Careful reading of this book will answer many of their questions. I also agree with one of the person in the podcast - start with small changes. Specifically for people who don't have unit tests. They need to start with unit testing first.

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.

The begining - Sprint 1

The team has been carved. The team seems too large to me. It has 2 QA persons, about 8 developers in one location and 5 developers from another location. There is a team of 3 product managers. It is decided to conduct daily scrums using video conferencing. Furthermore these developers are not dedicated the project alone. They are going to work on this project along with fixing maintenance issues. The scrum master and one of the developers from the team are Certified Scrum Masters. They are eager to implement scrum as they have been taught in the class.

Obviously, there are two problems with this setup. The team is too big and people are not dedicated to this project.

The chosen sprint size is 3 weeks.

The team attends the planning meeting. Maintenance issues are assigned weekly. The developers only know about their next two weeks load. They don't know their third week load. Everybody picks up stories considering their other commitments. The team ends up picking work worth only 150 hours for three weeks! Going by 6 hours per day per developer (if they were dedicated), they should have taken up at least 1014 hours worth of work!

The trained developer and the scrum master then walks up to the team's manager and requests him to do the following:

1. The team should have dedicated developers as much as possible. People should be freed up from their other tasks if possible or else, people should be aware that they can delay / refuse to accept fixing any maintenance issues if they have picked up more work from the sprint.
2. The team size should be reduced

The manager first tells the Scrum Master that he is putting everybody on it so that they learn the new product we are developing and they get trained on Scrum.

The trained developer and Scrum Master keep pursuing this issue with the team's manager. They tell him that without having dedicated developers the team will never gain momentum and if they don't know about their other commitments at the time of planning meeting, they are likely to take little work because of unknowns. The Scrum Master also shows him his training manual that specifies the ideal scrum team size to be 5 to 7 members. Finally the manager agrees with this and promises to correct it in the next sprint.