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.