Subtle things in SCRUM – 3 Testing teams

This is another aspect that we discovered over a period of time. At the start once we decided to follow scrum, we took each of the team, trained the team regarding scrum & team lead were trained to be a scrum master. Then one fine day we decided that everyone (dev & test) will follow scrum. A typical scrum team is self organizing. Team members pick up the task from the sprint backlog and burn them during the sprint. Each team works for the success of the sprint and adds a shippable increment to the component. And at the SOS (scrum of scrums) level all teams add a shippable increment to the product. This is the ideal situation that every one of us expected.

The reality was something different. At the end of the sprint we added an increment but it was not shippable. The bugs were found after the sprint delivery. The moment we had substantial number of bugs it cannot be called as a shippable increment. After some brainstorming we found the root cause. We took the conventional team setup and converted them to scrum teams. So we had development teams and testing teams. The development teams concentrated on adding new features. The testing teams took the last sprint delivery and tested the software. The target for the development team was to add more and more features. And the target for the testing team was to find all the bugs. Since the testing happened in the next sprint a sprint delivery became a shippable increment only after spending 2 sprints. We wanted to shorten this to a single sprint.

The solution we followed was to merge the testing and development teams together. Now a typical team contained a set of developers and testers. During the sprint the development and testing happened in parallel. Teams ensured that the bugs were resolved within the sprint. Those bugs which cannot be solved in the same sprint were scheduled in the following sprint. Now over a period of time the increment we added in a sprint became shippable increment. The lesson we learned was “development & testing goes hand in hand & scrum teams are cross functional”.



Subtle things in SCRUM – 1 Sprint Planning

In the past I was leading a team of 8 developers and a tester. We followed the Scrum method for close to 4 years. In this series of posts, I am planning to write things about Scrum method that I learned by practicing it. It is mostly out of my personal experience.

One of the major tasks in Scrum is sprint planning. Our regular sprint planning happened like the following

  • The product owner comes up with a list of features, bug fixes and refactorings that can be taken up in the sprint
  • I find out the team’s availability. (Actually taking all the planned vacations, trainings & holidays into account)
  • Next we break down the features into smaller work packages
  • We all sit together and estimate the work packages (using planning poker)
  • Then we pick up work packages that is equal to the availability
  • And finally we assign the work packages to the team members

This was working fine. But then over the time I found that we missed our team goal even though majority of the work was done. After some analysis and retrospective I found the problem was the last step.

  • And finally we assign the work packages to the team members

This step of allocating the work packages to the individual team members divided the team into individual members. So if someone completes a work package the next one was chosen from the team member’s pre-allocated subset. Sometimes this created situations where a work package of high importance to the team’s success was stagnant because of an overloaded team member. And another team member is busy burning some less important work package.

So we learned our lesson and stopped allocating the work to individuals upfront. We planned the work packages without assigning a name to it. Now once someone completed a work package the next one was chosen based on the team’s priority. It also made the sprint planning a lighter exercise.

This is a subtle thing which no one taught me in the scrum master training. And I learned it after failing couple of sprints.



Performance Evaluation

This year I am designated as an architect. And I am not responsible to do performance review for the team members. But in the past when I was a manager this used to be a long, tedious and time consuming job(I had 9 team members that time). So I thought this year may be just look back at the last couple of performance reviews. If some of my old team members are reading this blog then they may know which instance I am talking about but the point here is to look at the process as a whole how it happened in the past.

Preparation Phase

As a manager I have to remember all the work done in the past by each team member and also the various key events that happened. If I go unprepared then already it will look like I am not concerned about the team member. Also doing a fair review without preparation is not possible. So here is the list of item that I prepare before going to the meeting

  • The tasks allocated to each team member and how he performed it.
  • Specific instances where the team member helped other team member and the team.
  • Specific instances where the team member had created trouble for the team.
  • The major plus points of the team member.
  • The major minus points of the team member.
  • What is my expectation? What I look forward?
  • How the team member has performed with respect to previous years expectations?
  • If the team member joined in between then take the feedback from the previous manager.


Then comes the real dialogue with the team member. Utmost I used to take 2 team members per day. I find a nice spacious room with good lighting for the dialogue. And before getting into the room I say to myself allow the team member to speak more and allow him to express his point of view. The following are some of the challenges that I faced in the past

Team member comes unprepared for the dialogue

This is the funniest one when I go prepared the team member comes without any preparation and just tries to think over during the dialogue. Or some times the team member will post questions to me regarding what he did all the time? In most of such scenarios my prepared task list helped me a lot. But I have always felt such dialogues are not that constructive. Mostly the team member attends the dialogue with “nothing is going to change” attitude.

Team member comes with lot of paint points

The team member makes a huge list of all the paint points and wants to discuss only those issue. Here the problem is the team member never wants to listen anything that is good that happened to the team member during that time period. The dialogue then becomes each one defending themselves.

Team member do not know what he/she wants

The team member comes to the meeting and says that one is not satisfied with everything. But if asked “what one wants?” then I get a blank face. One of the team member even told me that in a performance review if someone agrees that “one is satisfied with the current state” then such team member will not be compensated well.

Team member assumes lot of things that is not known to him/her

Most of the time when a decision is made regarding a particular person that person is not part of that meeting. Because of this most of the team members will assume and create lot of story/rumors that are baseless. Talking to such team members in a performance review is always hard because even if I knew the truth I cannot expose that in front of that person because I may leak some information that is not meant for him/her. And even if I expose the truth still the team member liked to believe the baseless assumptions because that gives a feeling that the team member is a victim and is suffering.

Team member compares with other team members

The dialogue becomes very complicated once the team member starts to compare himself/herself to another team member. I personally hate doing the comparison and try to avoid such discussions. But there are some team members who wants to compare with others and prove that he/she is better than that compared team member & being paid less. Most of the times in such situations I try to convince the team member that this comparison is not going to take us forward in any way and stop it.

Discussion related to pay packages

The discussion related to pay package and remuneration is the hardest one. The team member brings in lot of assumption but the hard fact may be different. As a manager I cannot reveal this information. But I do the discussion entirely using a imaginary pair of team members and just discuss the issue. By this I avoid comparing 2 real team members. For example if a team member says

“I get lesser salary than person X”

I do the discussion something like this

“Let us assume a person A joined during the year 2005 and person B joined the during 2009, Person A may be getting salary less than B but A gets a yearly retention bonus which is not given to person B”.

It is not possible to avoid this topic in performance review meeting. If I avoid, then the team member feels that I am not concerned regarding the team members growth. In performance review “Money is not the only factor but money is one among the important factor”.

Manager: On becoming a software architect

After spending past couple of years managing a small team of 8, this year I switched over to software architect’s role. I have completed my first 6 months as architect now. I am sharing my experience how the journey is as of now. The following are some of the key things that I noted


The first and foremost question that came to me was “what should I do now?” Should I continue to do the same thing what I am doing or do something different as an architect. The role of an architect was not clear to me and because of that I am not sure where do I stand as an architect.


The architects role is mostly given to a senior developer who has proven his design capability in a couple of the modules. I too come with a similar background (imaging and 3d being my area of specialization). But moment I was made an architect the entire team of 30 developers expect me to know the solution to all the development problems. Sometimes when I say I don’t know the direct solution and ask the developer to look into a particular area for solution they look puzzled and feel bad.

No Team

The next major area of discomfort is due to my managerial background. Suddenly I don’t have a direct set of team members to report under me. This has created some kind of void for me. But I have lot of time and feel lot lighter because of this. But I miss the task allocation, tracking and pressure to deliver on time.


As an architect I need to make lot of decisions within a short span of time. Developers come with a problem and a couple of solutions. Now it is up to me to choose one among them. I am slowly learning to make informed decisions faster. The thing I lack is to remember the decisions that I took sometime in the past. I need to find a way to document the decisions or else when I go back with a concern regarding particular implementation the developer responds back that ”you asked me to do so”.


There is a bunch of architecture trainings for which I have been nominated. Each of the training starts with the objective of defining what a software architect should do and details a list of established process and methodologies for that. After attending all those trainings I understood that now I need to communicate with more stakeholders and take ownership.


As an architect the communication does not stop at the architecture specification document. Because normally the entire development team do not adhere to those guidelines just like that. I need to make substantial effort in communicating each architectural aspect to the teams clearly and concisely. Sometimes white board and a closed room is far better than a power point presentation or a word document. Even after so much communication I need to accept that there will be deviations that I need to live with.


The one thing that brings lot of sense and satisfaction is majority of the team members show lot of respect.


Attributes of a good team

I wanted to know why some team always achieve their targets in style and still enjoy every day “what are the attributes of a good team?”. After leading & watching couple of different teams in the past 6 years in my opinion the following are attributes of a good team in my opinion.

Conflict within team

All team have internal conflict. Because all team members are not same. But a good team uses conflict to its advantage. No one just agrees to the decisions without a debate or question. If some thing is wrong it is communicated on the face. The same members who debate fiercely inside a meeting are the ones who sit together for a happy chat in the coffee table. The outcome of the conflict is always positive.

Mutual Respect

All the team members have mutual respect for one another in a good team. It makes the team more integrated. It makes the team member to listen to others point of view. It also provides courage to others to express their point of view. It makes the team to commit itself to a decision made. It brings in self discipline and a sense of satisfaction. It also makes the senior team members learn from their own juniors without any ego. It makes communication open within the team.


All the team members put themselves into the other person’s shoes before asking the other to do something. This way each team member knows what is the feeling from the other team member. A good team never brands a particular team member to do particular kind of job. Each team member yields and shares the good work with others. Also all the team members take up painful jobs too. It increases sharing within the team.

Share success & failure

All the team members shares and celebrates the success together. A single team member do not hijack the team’s success. Again when there is a failure the whole team takes the responsibility together. A single person is never made a scapegoat. This builds up trust within the team. The team members learn to take up success and failure the same way. People don’t take the success to their head and failure to their heart.

Share knowledge

All the team members irrespective of experience shares the knowledge with other team members. The collective knowledge of the team grows exponentially over a period of time. New team members are productive in a short span of time. All team members feel that knowledge is to be shared and doesn’t hold back essential knowledge with them. Since knowledge is power the team achieves more in less time when compared to other teams.


Each and every team member display leadership quality (I am planning a separate post for this). All the team members own and take responsibility for the team’s output and delivery. Individual team members put team’s priority ahead of their own individual priorities. They help the manager in making informed decisions. Problems are communicated well ahead.

Help one another

All the team members help and support one another. A team member falling sick, someone in the team needs an unforeseen leave, Someone injured etc., are taken care by the team. All the team members gives priority to the missing team member’s task. This way the loss of the team member is only visible to the team and outside the team nobody feels the loss. During these situations all the team members stretch whole heartedly. This builds trust and the missing member recovers faster due to lesser stress.

Responds stronger during crisis

Every team goes through a period of crisis and tough time some time in the life span. This is the best time to identify a good team. A good team remains cool whatever may be the situation. It collects the list of problems, time available & resource available. Then the team works out a solution and implements the solution with utmost focus. The team comes out of the crisis successfully. During this whole time no team member criticize the other team member. The team is always focused on the task to be done. From the outside no one can feel that the team is in crisis.

Learn from the failure

Success and failures are two sides of a coin. A good team responds to failure with a positive attitude. First the team searches for the root cause and not for an individual. Once the root cause is found, the team seeks how to avoid that in future. Then the team forgets the failure and remembers only the lesson taught by the failure. In future the team doesn’t commit the same mistake again.

Finds solutions

For a team it is very easy to find problems, escalate, crib and wait for someone to solve. A good team does the other way. It searches for solutions. It never waits from some one else to come and fix their problems. All the team members actively participate in the implementation of a solution. All these small solutions act as a lubricant that reduces the friction in the day to day work. Mostly the team members are happy because no one is worrying about problems but all are actively searching for a solution.

To conclude the following saying perfectly applies to teams also. Its people who make a team.

“Great people talk about ideas.
Average people talk about things.
Small people talk about other people.”

— Ferose

Motivating frustrated team member

This time I will present the strategy that I have followed in the past to motivate the frustrated team member. It is not an easy task to accomplish. But nothing is impossible.


First and foremost thing is to communicate the news (that the team member looks frustrated) to the team member. Lot of time it is hard to communicate this bad news. But hiding the problem from the team member will not solve the problem but in reality it will worsen the problem. Clearly tell the current situation on the face. Sometimes the team member doesn’t even know his current status.

 One on One meeting

It is easy to talk and give lot of advice but it is hard to sit and listen. Again if you want to get the team member out of frustration, listen to his side of the story. A few important things to follow while doing this


¨     Allocate half an hour in each work week and talk to the team member

¨     Try to listen to the team member with out interrupting his thought flow

¨     Don’t justify anything

¨     Be open to the team member’s suggestion

¨     The meeting should be time bound

¨     There should be clear cut action path decided for both the manager and the team member.


In my personal opinion the major factor for frustration is low respect from fellow team members. Try to help the team member in finding out why the other team members are feeling that way. Don’t give general feedback like “You are not punctual” “You are not dedicated” etc., instead give specific scenarios like “You delayed the delivery of this package which in turn delayed person X delivery” “You were not showing enough interest in getting this Y job done on time”. And also detail regarding what was expected out of the team member in those scenarios.


This is the most important one. Every team member wants to prove that he/she is of value to the project and will show some visible changes on doing the about steps. It is the responsibly of the leader to identify the changes and appreciate if the team member is heading in the right direction. Appreciating a team member at the right time can work wonders. 


Once you feel that the team member is out of the frustration don’t give up and act like nothing happened. Try to continue the one on one meeting but with a longer time intervals. Also make the team member feel confident. Allocate more responsibilities and empower the team member.

Indentifying frustrated team member…

After long time I thought of posting something again. This time regarding how to find out, that a team member is totally frustrated.

Every team member starts with lot of enthusiasm in the beginning when one joins a team. One takes up different kinds of job and tries to accomplish them at record speed. Each developer wants to get the recognition from his fellow developer and his lead. As time passes by things change. Some team members are regarded as high due to their technical excellence. Some are regarded high due to the way they present themselves. Slowly this level of differences builds up some kind of frustration with in a team member. If as a lead one cannot identify such a situation and encourage the team member at the end of the day the whole team  needs to face the consequences.

Now the important question is,

“How do a team lead find out that a team member has reached such a frustrated state?”

Over the years in my own personal experience the following list of things can be helpful


Intuition is one among the best thing here. If a team lead has understood all his team members well, then a team lead feels that a particular team member is having some problem. But this is like Zen. It takes really long time and good amount of experience for a team lead to attain such a level.

Remaining Alone

As far as I know when somebody is frustrated one prefers to be alone. So if a developer  starts to prefer to be alone rather than being part of the team. Then it is a clear indication. This can be easily identified in team meetings. A frustrated developer never concentrates on what others are saying and doesn’t contribute any of his own comments on the subject. The team member attends the meetings just for the sake of attending the meeting and always ready to get out of the meeting room.

Don’t know

Again this requires some amount of experience to find this out. At a critical time when information is need of the hour a team member who knows the exact information will always come forward irrespective of what. But if a team member is frustrated then he says a clear no and says that some one needs to find the solution for that. Most of the time for an experienced team lead it is easy guess who will know the answer for a particular problem. But it is hard to find out whether a no coming from a team member is a real no.

Follow Orders

The other important aspect of frustration is a team member blindly follows the orders like military commando. In the normal circumstances a team member argues with the lead, if he thinks something is ridiculous. But once a team member is frustrated he will do anything given to him without any thought process. And when there is a problem he comes back with the argument that it was you who suggested such a solution.

Stick to Timelines

Every team member wants to impress others by completing task ahead of schedule. But once a team member is frustrated he will bargain huge amount of time for the smallest of the task. And he sticks to the time frame. If he finishes early he doesn’t come back with pride saying that he has finished early but waits till the allocated time is spent.


The easiest to identify is this aspect. When a team member gets really frustrated he tends be pessimistic regarding everything. Any team lead should be able to identify this very easily.

Next time I will write some solutions for the above list of issues.

-Ferose Khan J