Saturday, May 26, 2012

PDCA & SCRUM (or Agile); Why is it important?

The PDCA (Plan DO Check Act) cycle was made popular by Dr. W. Edwards Deming. This is a scientific cyclic process which can be used to improve the process (or product). This is cyclic in nature and usually time boxed.

This is the first stage of the process. During this step the team discusses the objectives, the process and the clear conditions of exit (conditions of acceptance). This stage sets the measurable and achievable goals for the team.

Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process.

Once the implantation is done team regroups and verifies the output and compares it to the agreed conditions of acceptance decided during the planning phase. The deviation, if any, is noted down.

If any deviation in planned tasks is observed during the Check stage, a root cause analysis is conducted. Team brainstorms and identifies the changes required to prevent such deviations in future. Team also brainstorms ideas/process changes (including the scope changes and measurement metrics) which can result in a better process/product in next cycle or iteration.

Anyone with a basic understanding of scrum can correlate the scrum terminologies to this scientific approach.

  • Plan – Sprint planning
  • Do – Actual engineering sprint
  • Check – Sprint review
  • Act – Retrospective 

The process starts with a clear set of aim and acceptance criteria. There is no vague or misunderstanding. This helps to minimize the waste. The group knows what to do and have proper guideline to achieve it. The verification of the planned tasks also happens against the known acceptance criteria. The process helps the team to make small changes get feedback and move ahead. The inspection and adaption helps the team to grow.  The end customer is happy because he can see the output quickly and can make the changes based on the market conditions.


Thursday, May 10, 2012

Team ratings in Scrum environment – How to measure individual performances

Measuring the individual performance in a scrum world is a very difficult proposition; in fact it is a paradox. Last day I had an interesting discussion on this with few scrum masters. One of the scrum master had a rating sheet which was updated after every sprint. There were points for scrum master, product owner & team. It was something like the following table

Another scrum master questioned the need of such ratings. A rating of 2.5, 4.5 or 4 doesn’t have any significance. It looks like the GPA score. If I get 9+ I will be considered brilliant; if I get less than 5 then I am a dumb, second class person. A Scrum Master with a very high score & team with low score don’t make any sense. It creates un-necessary competition.

Scrum is all about team work. It is a well-oiled machine. There is no individual superstar. Everyone has a part to play. If everyone performs their part to perfection, the full team including the SM & PO will get full marks. But I am not against ratings. These ratings should help the team and individuals to improve.

The ABCD of performance ratings

Personally I prefer a grading system like the one below.


  • A = Extraordinary effort. Did more than what was expected with lot of innovations 
  • B= Good effort, Met all the objectives of sprint & individual role.
  • C=Satisfactory, all the objectives of the sprint were not met. There is lot of scope for improvement.
  • D=Total disaster. (Can we replace this person?)
Giving ABCD grades is better than the numeric ratings. All the A’s are the examples of best practices; definitely you should share this with other teams. Team should try to convert all B’s to A’s. Here we need some innovation or out of box thinking. A new team will have lot of C’s . Initially this is a good thing to have. Scrum masters (& all others who can) should facilitate the removal of the impediments so that C is transformed to B. D is a special case. Special attention should be given to such cases. If the D’s are repeated for couple of sprints then, we should take the help of managers or HR. If you need some sort of individual performance metrics, just add all the A’s, B’s & C’s. (All the D’s will be out of the team or even company)

The UP –DOWN rating

Even this ABCD rating seems complex to me.


Just like scrum this method doesn’t have many rules (only common sense). Up arrow indicates that an improvement was made with respect to the role or task taken. The improvement should be noted & process which led to this should be identified and shared across.

A horizontal arrow indicates that the person has achieved what was expected from him/her. This doesn’t means that there is no scope of improvement. If we see this arrow consistently across multiple columns in multiple sprints then it is a pointer that the team & environment has stabilized. This is the right time to brainstorm to find better ideas which can improve the team productivity.

A down arrow points to the need of an action item to improve the process (or skill). Almost all the down arrows become a point for retrospective discussion. Like the ABCD ratings we can count the number & type of arrows to indicate the health & performance of an individual or overall team.


Tuesday, May 1, 2012

Scrum release planning: How to involve Juniors & Seniors & people from different background

Doing release estimation for a team is always tricky especially if the team is new or has a mix of people with different skills or experiences. Traditionally project managers did the estimates and in most of the cases it was under-estimated. Usually the PM takes the help from some subject matter experts before arriving at these estimates. Team will burn the midnight oil (or lamps :D, I hope they didn’t really burn it , there were many occasions when I wanted my PM to be burnt instead. ) But with scrum the estimation is the team’s responsibility. When I talk about this concept I get a lot of questions like the below

  • How can a bunch of people with different technical & domain skills estimate?
  • How can we trust the estimates from team, they will always over-estimate.
  • It is a waste of time, with so many people involved; it will be a never ending exercise.
  • The senior folks will do the estimation & juniors will go along with it without asking any questions. 

The questions are endless.

Estimates from a group of people are far better than an individual. It is better to have the estimates from the people who are going to develop the product. They will do an estimate by considering their strengths and weakness. If there is a domain/technical knowledge gap then they will be able to discuss and bridge this gap. This looks rosy, a silver bullet for all the estimation problems. Such silver bullet is not produced from vacuum; lot of work has to be done to make this bullet. Many teams find this group estimation very difficult & time consuming especially when they have a sizeable number of new people or junior resources. (I have seen experienced people also failing in this) These teams fail because they were not prepared for such an exercise.

Following are some good practices to prepare your team for release planning 

Training Plan for new/junior resources

You should have a training plan for any new resources in team. I suggest that every new team member should execute the regression test cases at least once even if they are developers or testers. This will ensure a common playground when the application features are discussed.   Everyone will understand and will contribute positively to the discussions.

For any new feature do the release planning in the following fashion 

  • Before you start ask the Product Owner to provide a high level overview of the features which are to be estimated. 
  • Divide your team into sub teams with a mix of Sr. developers, Jr. Developers & QA.
  • Assign each sub team one story from the backlog.
  • Ask the sub team to breakdown the story into vertical slices. 
  • This should be done in a time box 
  • After the time box expires, exchange the notes with other team. 
  • Review the notes received from other team and add any slices missing from the card
  • After the cards are reviewed by all, you can proceed with story pointing. 
  • It is the job of the scrum master to ensure that everyone speaks up. If the story is really difficult or complex then separate meetings should be set up. 
  • In one of my team, we used to schedule weekly meetings to discuss the upcoming features. In the first part of the meeting we discussed the story; the later part was reserved for all the technical discussions for the story. We used to discuss about the design patterns, the functions to be changed, the need of database script etc.  Usually we identify a lot of unknown, which were duly noted down. Based on our capacity we used to do the spikes on these unknowns and provide the answers in our next design meetings. 

You may solve the lack of domain knowledge in this manner.

Technical Knowledge 

The technical part is more difficult. It depends on the quality of resources you have. If you have good engineering practices like TDD, BDD then the transition will be fast.
When a techie joins our team we give a session on the business domain & technical aspects of the projects. We do a walkthrough of all the major classes and functions.
In my team we have a buddy system; a junior resource is assigned to experienced person. It is the duty of the Sr. guy to mentor the new resource and bring them up to the speed. The pair is given the complete freedom to choose the methods to achieve this goal. Sometime it could be pair programming sometimes it could be a detailed discussion sessions or anything that works.

The less experienced people might work in a module which they are not familiar but if you have god plan of initiation, do a good release plan & have a good technical practices then the transitions will be easy & new people should pick up the knowledge very easily. They might ask few extra questions & may take few hours more but it will benefit the team. I like this level of discussions and noise; I will be worried if people don’t make much noise or don’t ask any questions.