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 !!