Few Issues in Scrum implementation

1. Scrum Masters are expected to manage deliveries in a very complex distributed environment (Offshore developers and testers, Onsite dev and test leads, Onsite Project Managers, Offshore development manager, Offshore Scrum Master). Hard to do away with the non-scrum roles as client cannot lay off people.

<Raghav>: We should not use the word "Manage" any more if you want to give higher business value by using true agile methodology. You should make teams self-organized and self-managed. Try overlapped roles. Have Scrum master and Business Analyst roles at offshore and onsite. They can scale up to 3 scrum teams in onsite - offshore model. We should have team members (of all skills) in all these 3 scrum teams at both the locations.  Offshore scrum master will continue to support the team at offshore and sync with onsite scrum master to seek help from onsite Vice-Versa. Same need to be built in business analyst role too. Involve onsite tech leads during sprint 0, sprint planning phase -1 (during what part) and give maximum value to inputs provided by them during sprint review. Ask them to bring the other team members up to their speed so that we can make use of their technical expertise and also can make offshore teams more productive.

Be careful during collaboration. Do not let the tech leads get into waterfall style...

2. Twice a week, Scrum of Scrums that happens during US overlap hours, is used as a forum to escalate issues to Project Managers where Scrum Masters bring impediments to the notice of the Project managers.

<Raghav> First of all we need to bring more overlap hours between onsite offshore teams. Like India can operate form 11:00 am to 8:00 pm while US  (EST) team can work from 7:30 am to 4:30 pm. This will bring healthy overlap without much pressure on team members. Have daily standup, technical call, business call and also scrum of scrums during overlap hours. Remember, we will get much business value if offshore is not participating ina nay of these calls.

 
3. Daily Scrum calls happening during US overlap hours is the forum for team developers and testers to highlight issues/ impediments to Scrum master.

4. Once in a month, Scrum of Scrums is used to do the Sprint allocation of work to Scrum teams. Product Owners say which features need prioritized, development managers say it's feasible or not, Project managers document the allocation of features to each scrum team and Scrum masters are expected to relay the expectations to their Scrum team.
<Raghav>  I think you are using scrum of scrums for wrong purpose. No one should allocate the work. Teams should pick up. Development manager cannot decide on behalf of the team. Development manager is chicken. This is one of anti-pattern. It appears like, more chickens speaking than pigs. Watch out.

5. Requirements gathering happens at the start of the sprint, teams get to know user stories for that sprint and give story point estimation and commit to the user stories.

6. The first week is the Planning and Scope commitment week, the second week is the design week, third week is actual construction and testing week and fourth week is defect fixing week.

<Raghav> Looks like you are trying to build mini waterfall here. We need to spend some time on every sprint to collect the requirement and spend rest of the time on Design-Develop-Test happening in parallel. What you are trying is neither Scrum nor water fall it is Scrum-Fall.

I will keep adding more to this Post as and when I get more information.. 
Please post your comments and inputs so that this list will evelove and can become all inclusive over the time.

Defects During Sprint

Observations

During the sprint, since the developer “owns” the entire duration of the sprint, it’s impossible to say that there’s a defect because the developer may retort that they just aren’t finished with that task yet. 

• If the tester observes functionality that is inconsistent with the acceptance criteria for the story, the tester needs to log that “observation” (in their personal spreadsheet or other tool) and point it out to the developer immediately, hopefully giving the developer time to complete the functionality in the manner that the Product Owner expects before the end of the sprint. 
• If the observation is not “satisfied” by the last day of the sprint, then the observation is “converted” to a defect, which means that the tester opens a true defect in the defect tracking system, and removes the item from their observation log (The observation to defect conversation rate is a metric that will be tracked). 

Defects are created in one of two ways

• Observations are converted to Defects on the last day of the sprint. 
• Defects are discovered post-sprint. 
• Once logged, defects may be treated one of two ways: 
• Bundle several small defects into one user story. 
• Map one-for-one: one major defect to one user story. 
• For teams that are not as strict about only working on user stories, the team may try these approaches: 
• Allocate a “fix defects” story & task with a specific number of hours during sprint planning. Developers fix as many defects as possible within the hours associated with the story. 
• Allocate one day per sprint for the entire team to work only on fixing defects. 

However, remember that postponing the defect fixing to future sprints is not a right approach. We need to log the defects if the code is not meeting the acceptance criteria and/or not meeting the definition of done. This clearly shows that we are trying the deliver the potentially shippable code instead of shippable code by end of the sprint. We always need to try to deliver the shippable code all the time than potentially shippable code. Don’t you think that the feedback cycle ( inspect <-> Adapt in agile world) increased to 2 sprints instead of one sprint? Larger the feedback cycle, lessor the improvement is …

As a scrum master we need to arrest this anti-pattern so that the end customer will get higher business value at the end of every sprint.

Questions Asked by Participants during 22nd Agile Training Session on 8th April 2013

I found following questions unanswered on questions backlog:

1.       What if the difference between agile and distributed agile methodology?

We can build the distributed agile teams using Daikibo (means, large in Japanese Language) and 2 in a box model (copy right to Cognizant). Scrum master has to protect the team from external disturbances at onsite as well as offshore. Product   Owner or Business analyst should always stay at arm distance to help the teams whenever they have questions, hence, we can duplicate the roles of Scrum master and Business analyst at onsite and offshore. We will make sure that these two people are interacting at least twice a day so that they can help the developing team seamlessly !!

Developing team of onsite and offshore should make sprint commitment together so that they will be self-organized. Both the teams should participate actively, in all ceremonies (Sprint 0 activities, sprint plan, daily standup, review, retrospective and backlog grooming etc. ) so that all the members as a whole team can improve the productivity that can give high business value to end customer.

Refer to “Scrum Team Training Session  3” slide 17 in the course material.

2.       Will there be any SIT, UAT, IR Testing environments?

Agile always asks you to do what is Enough.  We still need to maintain the developing and testing environments as it is if these are giving higher benefit to end customer. However, they way we operate is littile tricky like, we will ask both developers and testes as part of in-scrum testing to work on Dev Environment together, so that the defects can be prevented. Validation testes can use  QA and other environments so that the defects can be identified.

Refer to “Scrum Team Training Session  4” slide 15 thru 18  in the course material.

3.       What if product owner realizes an user story in execution has  to undergo a change during sprint?

We need to see the root cause for this problem and address it at that level. Problem may recur if we are giving situational solutions instead of addressing root cause. Analyze …

·         At what stage this is   occurring?

·         Did PO analyzed the requirements during Sprint 0?

·         What is he doing during Backlog grooming sessions?

·         Look at what is meant by “enough elaboration” in PO view?

·         Bring this in retrospective meeting !!

Breaking the sprint should be a last option just before performing bypass surgery to scrum heartbeat. We should not make this is first or only option, as multiple by-pass surgeries can become more risky to agile framework and to the team !!

4.        Ideal scrum team – jack of all and master of none?

Agile team should consists of 7 or more/less Cross Functional team members. This doesn’t mean, 7+/- 2 Jacks .. it meas 7 +/- 2 human technically skilled human beings !! It is the responsibility of the team and scrum master to make all these human beings all masters over the time !!

Refer to “Scrum Team Training Session  1” slide 39 in the course material.

5.       Can we have intermediate releases?

Ideally, in agile world, We should target to build shippable (than potentially shippable !!!) product at end of every sprint so that the review is healthy and gives higher business value. IMHO, each sprint review is a release. No need to tag an intermediate release.

Will this be possible all the time?

Refer to “Scrum Team Training Session  1” slide 59 in the course material.

6.       Can we have intermediate Deliverables?

Same as the above !!

Risk Management

Let us record the project risks in the following category:

Agile process is all about the change in the scope during the development process. We can make any number of changes to the scope before we commit the release date (of course, change is not allowed during the sprint J ). The change in the scope could be due to lowering business value, competition, internal business needs. Some time product owners may alter the scope due to avoid risks. Keeping this in view the if the risk is exposed to sprint, may not impact the release. Let us identify and analyze the risks in isolation for better project management.

I feel it is best way to look at the projects health in Sprint level and release level. Some of the risks for the sprint may impact the release especially when we are close to release dates.1.

Sprint:
–Issues and risks that are exposed to sprint however, these may not impact the release. (Eg: 3rd party software not available in sprint 4, can impact the completion of user stories for this sprint. However, this may not impact the release as the release may be after 5 – 6 sprints.) Scrum allows us to integrate the 3rd party software later time. Or whore user story can be dropped if the business value gets low during the course.

Release:

–Issues and risks are exposed to release level. Any risks exposed to release level will definitely impact sprint. We need to use expert judgment as sometimes certain risk is red for sprint can be yellow or green for release.

Every risk reported should have following
Risk Id: An unique identifies (we can use the convention used by PMF for user stories)

Description : self explanatory

Mitigation Plan – Identify the activities to eliminate the threat imposed by risk. More mitigations you suggest, the better Scrum Master you are. All that time we need to see that the project enters into mitigation route

Contingency Plan – Fall back Option in case of Risk Occurs. We can suggest multiple paths here.

Trigger: This is very important for us to identify the trigger. This will help us to act few days/weeks before occurrence if we know the trigger.

Risk Exposure can be calculated using following table

How to use Risk Table?




Impact - Scale – 1 to 3
Profanity- Scale – 0.1 to 1.0
Formula Impact X Probability = Criticality of Risk

How to Interpret?
IF the score is < 1 then the criticality is Low
If the score is > 1 and < 2 Criticality of Risk is Medium
If the Score is => 2 then criticality is “High”

Risk Exposure (E) = Probability * Impact

For simplicity let us categorize only High, Medium and Low.

· Owner: who can work on mitigation or own the responsibility for contingency. Most of the time, scrum master or product owner.
· Action Items:
Reporting risks without A.I. is like reading news paper. Make sure that all relevant AI to be recorded for Mitigation or Contingency.

Why Planning Poker

Why Planning Poker

Planning Poker is one of the (for some people this only !!!) agile estimating technique that is derived from Wideband Delphi which is widely used in waterfall model with an exception of advocacy. This technique has become more popular after Mike Cohn added in his book “Agile Estimating and Planning.”

How to play Planning Poker?
We can use following very basic steps to arrive good estimates

1. Each participant is given a deck of planning poker cards representing a sequence of numbers in Fibonacci sequence (?, 0, ½, 1, 2, 3, 5, 8, 13, 20 (why not 21?), 40, 100). I recommend to use Fibonacci when compared to sequence of numbers like 0, 1/2, 1, 2,4,6,8 etc as Fibonacci sequence will not allow you to multiply or divide number among the estimators. This can lead to anchoring.
   


2. The scrum master presents one user story at a time


3. The Product Owner (or equivalent role) explains the user story to the team and answers any questions the team might have about the story.


4. Each participant selects a card representing his or her estimate of the user story privately. Team advised to take effort, time, risk, complexity, dependency with other stories or systems and any other relevant factors in consideration.


5. All the participants are expected show their estimates at once. I always utter “SHOW !!” to let participants show their estimates at once.


6. Life is good if there is a consensus in first go. Appreciate the team and record the estimate.


7. It is very likely that the estimates differ. Allow the high and low estimators to voice their opinions. Let the team debates briefly and show their estimates.


8. Continue previous step until consensus has been reached to record the estimate.


9. Repeat for all stories.
   

Is your life as easy as stated above?

Scrum team consists of developers, testers, database engineers etc. It is quite common to have different viewpoints and different solutions based on their skills and tastes. After all we are human beings having unique psychology. It is obvious to have difference of opinion among us. Otherwise we all could have called as ROBOTS than HUMAN.

1. Developers thinks the complexity in terms of writing code. Tester thinks the complexity in terms of testing the application. E.g: Developers can use default exceptions in coding whereas , testers should test all possible scenarios using decision tables n this scenario testing job is complex and developer job is simple. Some times developers need to generate complex algorithm to solve the problem, that might result simple testing. So, their estimates differ.


2. Sometimes the user story looks simple for an experienced team member while it looks complex for a junior team member. Experienced member will start anchoring.
   We ask everyone in the team estimate irrespective of their role in the development of specific user story. This will lead to misunderstanding of user story and differ the estimates largely. E.g.: if a team consists of 2 java developers and 5 integration experts (like Pega or Sales Force etc). Java developers tend to write tons of lines of code and feels the user story is complex, where as Pega or Sales Force type developers look at reusable components to complete. For them this is simple.


3. No consensus even after 3 – 4 rounds of discussion.

I use to apply following techniques to get the quick consensus among the human beings ( :-) )

1. Make sure that those who actually work are the ones to vote. It is quite common in agile teams that everyone vote even if they have no idea about the work involved in the story. This reduces the aberration in estimates. If it is Java related development, let all Java team member vote not others.


2. Let the experienced team members sin in listening mode most of the time. This allows others to think on their own. Experienced team member can pitch in if the discussion is going in wrong direction. He/she can jump into the discussion for conclusion and show his/her estimate after every one shows their estimates.


3. If there is a conflict between QA and Development teams, conclude the discussion by taking highest number as benefit of doubt. But, this should not become practice.
   Scrum master can ask the teams to compare with other stories already estimated. If one of the team member says the size is 5 and other member says 13, ask them to compare with previous stories estimated with the same size. Ask following questions to the team “how bid when compared to that?” or “Why it is as small as this?” etc. This enables the team members to think relative estimates.


4. Use timers to make sure that we not spending more than stipulated time. Move on to next user story if we are not getting consensus even after 3 – 5 rounds. Visit this story towards end of planning session


5. Arrange meeting with the person creating the user stories. QA and Development teams prior to playing planning poker. This helps the tam to save time during estimation.
   Do not allow implementation discussions in deep. Even though we get granular estimates after longer discussion, we may end up spending more time than expected and may leave some user stories without estimates.


6. Allow the team to go for task breakup offline if some user stories of high priority could not yield any consensus. Such stories can be taken up after break or after checking e-mails, updates in facebook, and twitter etc. This allows team members to work independently with fresh mind. Reconvene to complete estimates.
   

How to deal with distributed teams?

1. Now a days, it is quite common scenario to have distributed team working as a single scrum teams. For example, we often find it difficult to manage if Product Owner in New Jersey and developers in Bangalore. We still can get effective estimates with some adjustments in our process


2. We can use any one of the following online collaboration tools
   http://www.planningpoker.com/ developerd by Mountain Goat Software.
   http://www.expertware.no/estimationweb/ developed by PGS Software
   http://kevinverhoef.nl/poker/ developed by Kevin Verhoef
   Spead the planning meeting for 2 – 4 days with 1 hour a day. This helps offshore and onsite teams to meet at convinient time. Also teams can do some home work incrementally to get ready for estimation.


3. Perform pre-planning estimation at offshore or insite seperately. Have detailed discusion on user stories larked for planning. Go for poke planning estimation together. This saves lot of time.
   
   Go for planning poker estimate by giving these tips will help your team to provide near accurate estimates
   

Please feel free to provide your thoughts to improve this article

Scrum Retrospective

My experience proved that structured meetings always yield better results and reduces time waste. I normally follow 6 steps described below for retrospective meetings to achieve the desired results
· Set the tone – Inspect <-> Adapt cycles
· Recap - summarize impact of previous retrospectives
· Collate - the data from the scrum team – Just collect – No judgment
· Deep drive - identify why things went wrong, why successful, capture team energy
· Decide - what to do – based on the deep drive output, create action items and plan
· Conclude – summarize, conclude and thank the team

Set the tone …
Agile is methodology focuses on what is in store than wasting time on worrying about the past. At the same time, agile implementation benefits when we show the progress. This can be achieved by using small and measurable INSPECT and ADAPT cycles. We inspect the past to identify what t adapt for improvement in next cycle. This is the key success factor of Agile.

Scrum Master outlines the retrospective format, basic rules of the meeting, and goal to achieve as opening of the meeting. Goal should be something like “achieve increased quality by decreased time”. Scrum master should moderate entire meeting by keeping following basic principle in mind:
· Dialogue Vs debate
· Conversation Vs argument
· Inquiry Vs Advocacy
· Understanding Vs defending

Recap …
Scrum Master list the action items adapted in the previous cycles (Inspect – Adapt cycle). Let the team appreciate the adopted action items during discussion. Retrospective will be a futile exercise if we fail to adapt the action items of previous cycle. Entire meeting will become yet another time waste meeting. Team will tend to attend the meeting for the sake of supervisor not for the team.


Collate …
Collate or Gather Data from the team. Scrum master should ask the team to collect the required data independently and capture on a paper 1 to 2 days before the retrospective meeting. Suggest the team to recap the sprint cycle while driving (please watch the traffic signals and/or police to avoid tickets J ) or have small discussion at coffee table etc. Team can bring any point without shy. Scrum master will note down on scrum board.
Categorize the points into following traffic signals:
Green continue
Yellow improve
Red drop


Deep drive …
Look into all the points collected in the previous step amicably. Identify the points to adapt. Ask more generalized questions possibly in relation to actions from the previous sprint and whether they helped the process. Categorize them into Positive, Negative, Ideas, Appreciations. Use SWOT analysis model for better judgment. (http://en.wikipedia.org/wiki/SWOT_analysis ). Rank the items with in the quadrant.

Decide …
Pick up top ranked items that can be implementable (short term and long term) and let the team to identify the tasks and subtask. In this step the scrum master should get consensus from whole team for agreed action items. Let the team members own them.

Conclude …
Closing a meeting by summarizing the “Take away from this meeting”, Readout action items and thank the team for participation. Some people does survey after the meeting to know whether the meeting is useful or not.