Introduction To Xp And Scrum Practices

Pragati Software Pvt. Ltd., 312, Lok Center, Marol-Maroshi Road, Marol, Andheri (East), Mumbai 400 059. www.pragatisoftware.com

Introduction to XP and Scrum

Pradyumn [email protected]

Pragati Software Pvt. Ltd.www.pragatisoftware.com

http://www.pragatisoftware.com/



Agile Software Development Methodologies

• Useful compromise between no process and too much process.

• Suitable for responding to changing customer requirements. Adaptive rather than being predictive.

• Work well even for predictable requirements.• People-oriented as against being process-oriented.


Introduction to Extreme Programming (XP)

• Pioneered by Kent Beck, along with Ward Cunningham and Ron Jeffries.

• A set of useful guidelines or best practices for handling software development projects.

• Strong emphasis on small iterations, simple design, and test-driven development.


Five Core Values of XP

• Communication• Simplicity• Feedback• Courage• Respect


Overview of XP: Practices

Primary practices (13)• User stories• Weekly cycle (iteration planning)• Test-first programming• Incremental design• Continuous integration• Ten minute build• Pair programming• Energized work• Quarterly cycle• Sit together• Whole team• Informative workplace• Slack

Secondary practices (11)•Customer involvement•Shared code•Root-cause analysis•Code and tests•Single code base•Incremental deployment•Team continuity•Shrinking teams•Daily deployment•Negotiated scope contract•Pay-per-use




Stories

• Story = customer-visible functionality provided by a system.• Build a list of stories based on discussions with customers.

Just note down the names initially.• Role of stories:

Estimation Scope definition for a release cycle Units of planning and monitoring a system Prioritization by customers. Risk assessment and estimation by developers.


Pair Programming

• Two programmers working together for some programming task.

• Benefits: Knowledge sharing Better quality Coding standards On-going code reviews Ease of inducting new team members (mentoring) Mutual learning Improved productivity


Planning: Release Cycles and Weekly Iterations

• Small releases: providing quick value to customers and feedback to developers.

• Release planning involves both customers and developers.• Customers prioritize the stories based on their value to them,

developers estimate the time required.• Divide a release cycle further into weekly iterations for all

work planning and monitoring.


Slack

• Important to establish and maintain the credibility of the release plans.

• It is better to undercommit and deliver what is committed, rather than overcommit and underdeliver.

• Introduce slack in your release plan, but not slyly.• Slack = including low value, non-critical stories in the release

plan that can be dropped if the schedule starts slipping


Test-First Programming

• Write tests for all code before you code.• Automate the tests. Open-source testing tools, such as JUnit,

There are tools such as JUnit, NUnit, HttpTest, Fit, etc. available for this purpose.

• A code is completed only when it passes all tests.• Maintain the tests along with your code. • Write code at various levels: unit tests, acceptance tests, etc.


Incremental Design

• Avoid “complete design before implementation”.• According to a Standish Group report:

7% of features and functions are always used, 12% are often used, 16% are sometimes used, 19% are rarely used, 45% are never used.

• Design what is needed now. Keep investing in the design every day.

• Create spike solutions to tackle tough technical or design problems.

• Design done close to when it is needed is more efficient.• Refactor your design as you go ahead.


Ten-Minute Build

• Automate the build and run cycle, to be completed within ten minutes.


Continuous Integration

• Integrate and test code every few hours.• Dedicate one machine for integration.• If any tests fail, we know we broke it, and must therefore fix

it, or throw away what we did.• Cost of packaging a release is minimal.• Open-source tool: CruiseControl


Shared Code

• Nobody owns any code and everybody owns all the code.• Anybody can change any line of code anywhere, to add

functionality, fix bugs, or refactor.• Works well because of refactoring and unit tests.• Eliminates the need for separate code reviews.


Real Customer Involvement

• Customer writes user stories, acceptance tests, and answers queries of developers.

• Negotiates a set of stories to be included in each scheduled release.

• Benefits: Priorities can be set / adjusted in real-time No need to have water-tight requirements Customer is available to help make course corrections as clarity

emerges gradually about the requirements, effort estimates and consequences

Customer participates in discussions and planning meetings; has greater understanding of technical issues and status of the progress.


Energized Work

• Projects requiring overtime to finish in time will finish late, no matter what.

• Overtime is a symptom of a serious problem with the project.


Quarterly Cycle

• At the macro level, plan work a quarter at a time. Identify bottlenecks Identify and initiate corrective steps Focus on the big picture, where the project fits within the

organization.• Take stock of the project, the team, and its progress.


Root-Cause Analysis

• Whenever a defect is found after development, eliminate the defect and its cause. Follow the steps given below: Write an automated system-level test to demonstrate the defect. Write a unit test to reproduce the defect. Fix the system so that the unit test works. The system test should also

pass. Run the entire test suite of the application. Analyze why the defect was created and was not caught. Initiate the

necessary changes to prevent such a defect in future. [Taiichi Ohno’s Five Whys is a good technique for this.]


Single Code Base

• Maintain a single code stream. • Having multiple versions of code results in maintenance

nightmares.• Temporary branches should be for very short durations only.


Code and Tests

• Maintain only code and tests as permanent artifacts.• Generate documents from the code and tests.


Other Practices

• Sit Together: Develop in an open space big enough for the whole team.

• Whole Team: Create a cross-functional team, with all the skills and perspectives

needed for the project to succeed.• Informative Workspace:

Display information about the project status all over in the workspace. Place user story cards or big charts for issues that require steady

progress.


Other Practices (contd…)

• Incremental Deployment: When taking over a legacy system, gradually take over its workload

beginning very early in the project. No “cut over” during a weekend.• Team Continuity:

Keep effective teams together. At the end of a project, don’t send the programmers to the “pool”.

• Shrinking Teams: As the team grows in capability, keep its workload constant but

gradually reduce its size. Free people to form more teams. If a team is too small, merge it with another very small team.

• Daily Deployment: Put new software into production every night.


Other Practices (contd…)

• Negotiated Scope Contract Write contracts for software development that fix time, cost, and

quality, but call for an ongoing negotiation of the precise scope of the system.

Reduce risk by signing a sequence of short contracts instead of one long one.

Split big, long contracts in smaller ones.• Pay-Per-Use


Introduction to Scrum

• Another prominent agile methodology.• Co-developed by Jeff Sutherland and Ken Schwaber in the

early 1990s.• While XP practices are more programmer-centric, Scrum

practices are geared towards the project managers.• XP and Scrum complement each other very well.


Overview of Scrum

The core of Scrum is an interative, incremental process skeleton.

At the start of each iteration, the team selects what it can implement by the end of the iteration, by looking at the requirements, technology available, its skills and capabilities.

The team is then left alone to implement the chosen functionality.




Overview of Scrum

• Three roles: Product Owner Team ScrumMaster

• Three artifacts: Product Backlog Sprint Backlog Increment of potentially shippable product functionality

• Scrum Flow Project Vision Product Backlog Sprint

• Sprint planning meeting• Daily Scrum meeting• Sprint review meeting• Sprint restrospective meeting


Scrum Process




Product Owner

• Represents the interests of all the stakeholders• Achieves initial and ongoing funding for the project by

creating the project's initial overall requirements ROI objectives release plans

• Frequently prioritizes the Product Backlog to ensure that the most valuable functionality is produced first and built upon


Team

• Responsible for developing functionality.• Teams are self-managing, self-organizing, cross-functional.• Responsible for

figuring out how to turn Product Backlog into an increment of functionality

managing their own work to do so success of each iteration and of the project as a whole


ScrumMaster

• Responsible for the Scrum process teaching Scrum to everyone involved in the project implementing Scrum so that it fits within an organization's culture

and still delivers the expected benefits ensuring that everyone follows Scrum rules and practices


Scrum Flow

• Project Vision• Product Backlog• Sprint

Sprint planning meeting Daily Scrum meeting Sprint review meeting Sprint restrospective meeting


Project Vision

• A project starts with a vision of the system to be developed. May be vague initially, but will become clearer as the project moves

forward Product Owner is responsible (to those funding the project) for

delivering the vision in a manner that maximizes their ROI.


Product Backlog

• Product owner formulates a plan for delivering the vision that includes a Product Backlog.

• List of functional and nonfunctional requirements.• Prioritized so that the items most likely to generate value are

top priority and divided into proposed releases.• Prioritized Product Backlog is the starting point.• Contents, priorities, groupings into releases may change the

moment the project starts.• Changes in the Product Backlog reflect changing business

requirements and the speed with which the Team can transform the Product Backlog into functionality.


Sprint

• All work is done in Sprints.• An iteration of 30 consecutive calendar days.• The Team can seek outside help, information, support.• No one can provide advice, instructions, etc. to the Team

during the Sprint. The Team is self-managing.• The Team is committed to the Product Backlog selected

during the Spring Planning meeting. The Product Backlog is frozen, and no one is allowed to change this Product Backlog during the Sprint.

• If the Sprint proves to be unviable, the ScrumMaster can terminate the Sprint and initiate a new Sprint planning meeting.


Sprint Planning Meeting

• At the start of a Sprint, there is a Sprint planning meeting. In this meeting, Product Owner and Team get together to collaborate about what will be done for the next Sprint.

• Product Owner tells the team what is desired. The Team tells the Product Owner how much it believes it can turn into functionality over the next Sprint.

• Time-boxed to a maximum of eight hours. Divided into two parts. The first part is for selecting Product Backlog, the second part is for preparing a Sprint Backlog.


Daily Scrum Meeting

• 15-minute team meeting at the start of each day.• Each team members answers three questions:

what have you done on the project since the last Daily Scrum meeting what do you plan on doing on this project between now and the next

Daily Scrum meeting what are the obstacles

• Purpose of the meeting: synchronize the work of all Team members schedule any meetings that the Team needs to forward its progress


Sprint Review Meeting

• Held at the end of a Sprint.• Timeboxed to four hours.• Team presents what was developed during the Sprint to the

Product Owner and any other stakeholders who want to attend.

• Functionality that isn't "done" cannot be presented.• Majority of the Sprint review is spent in presenting

functionality, answering stakeholder questions, noting desired changes.

• At the end, the stakeholders are polled to get their impressions, any desired changes, the priority of these changes.

• Brings people together and helps them collaboratively determine what the Team should do next.


Sprint Retrospective Meeting

• Conducted by the ScrumMaster. Attended only by the Team, the ScrumMaster, and the Product Owner (optional).

• Timeboxed to three hours.• Team is encouraged to revise its development process to

make it more effective and enjoyable for the next Sprint.• ScrumMaster starts by asking all the Team members:

what went well during the last Sprint? what could be improved in the next Sprint?

• Role of ScrumMaster is not to provide answers, but to facilitate the Team's search for better ways for the Scrum process to work for it.

• Actionable items to be added to the next Sprint are devised as high-priority nonfunctional Product Backlog.


References

• Books on XP Extreme Programming Explained, Second Edition. by Kent Beck, Cynthia

Andres. Planning Extreme Programming. by Kent Beck, Martin Fowler. Refactoring. by Martin Fowler. Extreme Programming Installed. by Ron Jeffries, et al.

• Websites on XPwww.extremeprogramming.orgwww.xprogramming.comc2.com/cgi/wiki?ExtremeProgrammingRoadmapwww.egroups.com/group/extremeprogramming/www.agilealliance.org

• Books on Scrum Agile Project Management with Scrum. by Ken Schwaber.

• Websites on Scrumwww.controlchaos.comwww.scrumalliance.orgscrumdevelopment@eGroups.com


Thank You!

Pradyumn [email protected]



Technology

Introduction To Xp And Scrum Practices