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.