Monday, 17 October 2016

Chat Discussion on Scrum for Fixed bid project



Below is a discussion and summary of views on execution of fixed bid project using Scrum and y-o-y gains. This discussion happened on 22/10/2014.

Shantanoo: Here is a question or something for brain work...
How in large outsourcing contract for application development where we use agile; the cost model would be on fixed price?
Shantanoo: And in addition, how would we measure and show y-o-y productivity gains? While projects are running on agile?

Satisha: There was a question. Is Scrum suitable when we are working on fixed bud project?
Satisha: Customers are willing to cooperate but internal sales folks have aggressively bid and won project
Satisha: These 2 folks from delivery team know that can't deliver it
Satisha: Also know waterfall is not useful
Satisha: So they are using Scrum
Satisha: But they see changes coming in at the end of every sprint
Satisha: So they were asking should we use scrum as they don't have provision for change control in their contract
Satisha: What would you suggest these guys do?
Sneh Shahani: First thing that they should do is to set clear expectations.
Atmaram: Also I think they are not able to identify hence freeze the requirements.
Sneh Shahani: And as anyways project execution is tradeoff between resources available and features to be delivered. So then then can only try and deliver whatever MVP or value add they can give.
Atmaram: Prioritization of us also should be focused
Atmaram: Absolutely so Scrum should be used to identify and deliver MVP and from any budget that is remaining can be used to complete remaining set of prioritized US
Satisha: Their worry is if we keep on taking changes they may not be able to meet scope per contract
Alok: I ditto with Sneh .... They need to trade off MVP along with CI ..
Shantanoo: May be this should be our next topic in meet up?
Shantanoo: If together we can create model for dealing this with customer then it would be great

Satisha: I did learn how a small startup handled this case which goes in line with what I do and preach
Satisha: He even showed what they delivered
Shantanoo: Here is a question or something for brain work...
How in large outsourcing contract for application development where we use agile; the cost model would be on fixed price?
Shantanoo: Here was last question i put up last time
Shantanoo: And in addition, how would we measure and show y-o-y productivity gains? While projects are running on agile?
Satisha: How do you show it now?
Satisha: Cross question: how do you calculate cost in case of fixed price? What parameters do you use?
Shantanoo: At present we show it based on productivity against euro value

Tuesday, 20 September 2016

Importance of Zero Talent Virtues in Agile Software Development


This article explains importance of virtues that depict the attitude of a person than the talent. This is based on a very popular meme on social media which lists down zero talent virtues like being on time, doing extra, being prepared, etc and applies that into agile environment.

This article is an example of collaborative discussion between many contributors from PlayScrum Vadodara community. A special thanks to all the contributors: Anand Vyas, Anil Sharma, Bhavin Acharya, Chintan Sisodia, Deepak Joshi, Harit Pandya, Jay Pandya, Misha Vaidya, Rajesh Panchal, Sachin Patel, Satisha Venkataramaiah, Sneh Shahani, Vaibhav Dhingani, Vishal Shah

Please have a look at the article by visiting https://www.scrumalliance.org/community/articles/2016/june/the-importance-of-zero-talent-virtues-in-agile-sof

Monday, 12 September 2016

Case Studies, Problems and Solutions from Practitioners from 11 June 2016 - Practitioner's Corner

Problem 1: How do I select a pilot team for adopting and implementing Scrum ?

Solution:
  • Select a project (pilot) which requires shorter delivery to market.
  • Choose a mature Cross functional team, small in size which already has good knowledge on the application.
  • Choose teams having better Engineering practices
  • Teams which have little or no escalations
  • Engage metrics team of the respective organization to do an Agile assessment for the chosen team.
  • Most important, teams for which there is Buy-in from Senior Management.

Problem 2: Scrum Master is a developer. He is associated with a team which is working on Niche technologies. Problem the Scrum Master faces are below,

  • Scrum Master and the team is overworked.
  • At regular frequency, Team members frequently drop their papers.
  • Though Management is able to provide an alternate (Backup \ Shadow) resource, it is pulling down team's velocity.
  • There is lot of emphasis from Senior Management on Daily reports which Scrum Master finds it as a waste of time.
Solution :

After a long discussion it was understood that overworked team members were not the reason for team members quitting at regular intervals of time. It was understood that the niche technology was the driver behind team members logging in extra time and at the same time quitting. If the Management could take care of their needs, this leakage could be arrested.

As far as the reports go, the 'PlayScrum' practitioner's have suggested the 'Scrum Master' to keep adding metrics to the report, make it complex so that one day 'Senior Management' could come back saying that this report is no longer required.

Case Study : XP on top of Scrum increases mature Scrum team's Velocity

Top Management decided that entire organization has to transition from Waterfall to Scrum way of project delivery

Many projects across the organization's distributed teams started to use Scrum (in 2 week sprints) and velocity data was recorded for 1 year. After 1 year, when the Top Management wanted ways to improve velocity, by doing XP, the teams were able to show significant improvement in velocity - primary reason being in XP, team could pick up items as and when completed).




Thanks,
Natarajan
Open Problem Statement from 30th July 2016 - Practitioner's Corner - Chennai.

Problem Statement

This problem was brought to the table by a practitioner 'Scrum Master' in the 'Practitioner's corner'. It could not be discussed due to the lack of time. Problem statement below,

The Scrum Master's team is functionally and geographically distributed scrum team. Scrum Master and QA team is co-located in Chennai. Development team 1 sits at Singapore and Development team 2 sits in another geography other than the two mentioned above. 

Scrum Team does not connect regularly with Product Owner unless when it is the 'Sprint Review'. Zeroth sprint always runs ahead of the Scrum Team's sprint. In the Zeroth sprint, group of architects discuss with Product Owner and come up with 'Architectural stories' and 'Feature stories' which 'Scrum team' has to work on.Team follows a 2 month sprint window whose breakup is below,
  • Build and QA happen in parallel in the the First month + Integration testing with Upstream and Downstream teams.
  • QA team provides UAT support to business in the second month.
  • Scrum Team does not have resources for working on Non functional requirements (ex. performance testing).
  • Release happens at the end of every 3 months

Issue faced by the Scrum Team:
  • We hear from the 'Scrum Master' of the impacted team (details below) that even though there is the above process followed, 
  • The application in production has performance issues (especially - Non functional ones)

Due to lack of time, we were not able to take up this problem statement and figure out the root cause. 
This is an open problem statement which can be picked up for discussion in upcoming Practitioner's corner.



Thanks,
Natarajan








Sunday, 4 September 2016

How to resolve team problems?



This scenario was discussed in Practitioners Corner held at Pune. Below are the notes of the discussion.


How SM can help PO if PO is unclear?



This scenario was discussed in Practitioners Corner held at Pune. Below are the notes of the discussion.

The scenario of the organizational structure for the project is described in below figure.

Situation is like Product A and Product B. Product B is a replica of Product A. PO accepts but super PO rejects.

Typical reasons for rejecting
PO’s boss is aware of internals and has different level of understanding.
PO, Super PO, SM are at client side.
No acceptance criteria, process of agreement

Solutions
Get a Legacy System Expert
Get aligned on acceptance criteria.
Gap analysis
Sprint sign off process
Definition of ready to be sent.