agile workshop 2016

AGILE SOFTWARE DEVELOPMENT - INTRO

WATERFALL – Problems of traditional software development

Typical product developed by traditional approach

2011 2012 2013 2014 20150

10

20

30

40

50

60

Outcomes of the traditional projects

Successful Challenged Failed https://www.infoq.com/articles/standish-chaos-2015

Any delays in project lead to extra amount of money and time. Major factors that lead to project delays are change in requirements, miscommunication, lack of documentation and clarity within the teams, lack of collaboration within teams, sponsors, clients and stakeholders.

Typical phases of traditional development:

REQUIREMENTS

DESIGN

IMPLEMENTATION

TESTING

DEPLOYMENT

MAINTENANCE



2011 2012 2013 2014 20150

10

20

30

40

50

60





REQUIREMENTS

DESIGN

IMPLEMENTATION

TESTING

DEPLOYMENT

MAINTENANCE

CHANGES



2011 2012 2013 2014 20150

10

20

30

40

50

60





REQUIREMENTS

DESIGN

IMPLEMENTATION

TESTING

DEPLOYMENT

MAINTENANCE

CHANGES

TAKES TOO LONG



2011 2012 2013 2014 20150

10

20

30

40

50

60





REQUIREMENTS

DESIGN

IMPLEMENTATION

TESTING

DEPLOYMENT

MAINTENANCE

CHANGES

TAKES TOO LONG

SKIPPED



2011 2012 2013 2014 20150

10

20

30

40

50

60





REQUIREMENTS

DESIGN

IMPLEMENTATION

TESTING

DEPLOYMENT

MAINTENANCE

CHANGES

TAKES TOO LONG

SKIPPED

TERRIBLE

TERRIBLE

WATERFALL – Problems of traditional software development List of typical problems:• Requirements are not clear• Requirements are changing• Project takes too long• No time for testing • Time wasted on junk • Poor progress visibility

AGILE METHODOLOGY

Agile

Traditional

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation• Responding to change over following a plan

Manifesto for Agile Software Development

Main Agile principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.• Build projects around motivated individuals. Give them the environment and support

they need, and trust them to get the job done.• The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation.• Working software is the primary measure of progress.• Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely.• Continuous attention to technical excellence and good design enhances agility.• Simplicity--the art of maximizing the amount of work not done--is essential.• The best architectures, requirements, and designs emerge from self-organizing

teams.• At regular intervals, the team reflects on how to become more effective, then tunes

and adjusts its behavior accordingly.

http://agilemanifesto.org/

AGILE METHODOLOGIES

AGILE METHODOLOGY – SCRUM The Goal of Scrum

• Manage Complexity • Manage Unpredictability • Change through Visibility, Inspection and Adaptation• Add Transparency to the Process

AGILE METHODOLOGY – SCRUM ROLES

AGILE METHODOLOGY – SCRUM ROLES Main roles in Scrum

The Product Owner• Clearly expressing Product Backlog items;• Ordering the items in the Product Backlog to best achieve goals

and missions;• Optimizing the value of the work the Development Team

performs;• Ensuring that the Product Backlog is visible, transparent, and clear

to all, and shows what the Scrum Team will work on next; and,• Ensuring the Development Team understands items in the Product

Backlog to the level needed.

The Development Team• They are self-organizing. No one (not even the Scrum Master) tells

the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

The Scrum Master / Agile Project Manager

Scrum Master to the Business• Finding techniques for effective Product Backlog management;• Helping the Scrum Team understand the need for clear and concise

Product Backlog items;• Understanding product planning in an empirical environment;• Ensuring the Product Owner knows how to arrange the Product Backlog

to maximize value;• Understanding and practicing agility;• Facilitating Scrum events as requested or needed.

Scrum Master to the Development Team• Coaching the Development Team in self-organization and cross-

functionality;• Helping the Development Team to create high-value products;• Removing impediments to the Development Team’s progress;• Facilitating Scrum events as requested or needed; and,• Coaching the Development Team in organizational environments in which

Scrum is not yet fully adopted and understood.

Scrum Master to the Organization• Leading and coaching the organization in its Scrum adoption;• Planning Scrum implementations within the organization;• Helping employees and stakeholders understand and enact Scrum and

empirical product development;• Causing change that increases the productivity of the Scrum Team; and,• Working with other Scrum Masters to increase the effectiveness of the

application of Scrum in the organization.

AGILE METHODOLOGY – SCRUM ARTIFACTS

Product Feature 1Product Feature 2Product Feature 3Product Feature 4Product Feature 5Product Feature 6Product Feature 7Product Feature 8

Prod

uct B

ackl

og Sprint Backlog

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

IncrementThe Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

Definition of "Done"When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The SprintThe heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint.Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.During the Sprint:• No changes are made that would endanger the

Sprint Goal;• Quality goals do not decrease; and,• Scope may be clarified and re-negotiated between

the Product Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

AGILE METHODOLOGY – SCRUM PROCESS

AGILE METHODOLOGY – SCRUM ESTIMATION

?

Main Questions are…

• Why we need Story Points? • Estimation on hours is also needed?

AGILE METHODOLOGY – ESTIMATION EXERCISE 1

?


Add empty button to the current form.

1 SP

User Story 1



Add empty button to the current form. On click lead to Refresh page.

1 SP 2 SP

User Story 1 User Story 2




Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. 1 SP 2 SP 3 SP

User Story 1 User Story 2 User Story 3




Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color.

Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified. 1 SP 2 SP 3 SP 5 SP

User Story 1 User Story 2 User Story 3 User Story 4





Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified.

Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified. Data should be stored in Database.

1 SP 2 SP 3 SP 5 SP 8 SP

User Story 1 User Story 2 User Story 3 User Story 4 User Story 5


Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. ? SP

User Story 3



Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified. ? SP 5 SP




Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified. ? SP 5 SP


More complicated




Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified. 2 SP ? SP 5 SP


More complicated






More complicatedLess complicated




Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified. 2 SP 3 SP 5 SP









Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh Page” and green color.

User Story 81

3 SP




Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh” and red color. Also input user’s data should be verified. 2 SP 3 SP 5 SP



Add empty button to the current form. On click lead to Refresh page. Button should have title “Refresh Page” and green color.

User Story 81

3 SP

AGILE METHODOLOGY – STORY POINTS ESTIMATION








AGILE METHODOLOGY – STORY POINTS ESTIMATION








13 SP

AGILE METHODOLOGY – HOURS ESTIMATION








AGILE METHODOLOGY – HOURS ESTIMATION








• Add button – 1h• Test that button exists –

0.5 h• Deploy to test pre prod -

0.5 h

• Add button – 1h• Add on click event and

refresh action – 1h • Test that button exists –


0.5 h


refresh action – 1h• Set red color – 0.5 h • Test that button exists –


0.5 h


refresh action – 1h• Set red color – 0.5 h • Add data validation – 2h • Test that button exists –


0.5 h


refresh action – 1h• Set red color – 0.5 h • Add data validation – 2h• Add saving to DB – 4h • Test that button exists –


0.5 h

AGILE METHODOLOGY – EPICS








• Add button – 1h• Test that button exists –


0.5 h


refresh action – 1h • Test that button exists –


0.5 h


refresh action – 1h• Set red color – 0.5 h • Test that button exists –


0.5 h


refresh action – 1h• Set red color – 0.5 h • Add data validation – 2h • Test that button exists –


0.5 h


refresh action – 1h• Set red color – 0.5 h • Add data validation – 2h• Add saving to DB – 4h • Test that button exists –


0.5 h

Epic 1. SAVE USER DATA INTO DB

AGILE METHODOLOGY – SPRINT PLAN Activity / Days 1 2 3 4 5 6 7 8 9 10

Sprint planning

Execution

Grooming

Code freeze

Bug fixing / Support

Refactoring

Regression testing

Delivery

Demo

Retrospective

AGILE METHODOLOGY – SPRINT PLAN Activity / Days 1 2 3 4 5 6 7 8 9 10

Sprint planning

Execution

Grooming

Code freeze

Bug fixing / Support

Refactoring

Regression testing

Delivery

Demo

Retrospective

Retrospective questions• What was good?• What was wrong? • Actions

• Retrospective Actions should be registered in Jira like a working item

AGILE METHODOLOGY – KANBAN The Goal of Kanban

• a way to organize the chaos that surrounds so many delivery teams by making the need for prioritization and focus clear.

• a way to uncover workflow and process problems so you may solve them in order to deliver more consistently to your client/customer/etc.

AGILE METHODOLOGY – KANBAN Kanban Core Properties

• Visualize the workflow. You have to understand what it takes to get an item from request to completion. The goal of Kanban is to make positive change to optimize the flow of work through the system. Only after understanding how the workflow currently functions can you aspire to improve it by making the correct adjustments. Making changes before you understand your workflow is putting the proverbial cart before the horse and can cause you to make choices that are, at best, unhelpful and, at worst, harmful.

• Limit WIP. Limiting work-in-progress implies that a pull system is implemented on parts or all of the workflow. The critical elements are that work-in-progress at each state in the workflow is limited and that new work is “pulled” into the next step when there is available capacity within the local WIP limit. These constraints will quickly illuminate problem areas in your flow so you can identify and resolve them. Limiting WIP is the cornerstone of Kanban.

• Manage flow• Make Process Policies Explicit. An example of a policy

that you can make explicit is a definition of done. In fact, you can have a definition of done for each step in your workflow, meaning that before an item can be ready to pull forward, it has to meet certain criteria.

• Improve Collaboratively. If you are not continually improving, but you are doing all of the other parts of the Kanban method, you are missing the point. Its a little like the concept of “doing” Agile but not being agile.


• Visualize the workflow. • Limit WIP. • Manage flow• Make Process Policies Explicit. • Improve Collaboratively



Open In Progress Testing Deploy



Open In Progress Testing Deploy 7 3 2 1




Acceptance 1




Acceptance 1

Definition of Done Rule 1Rule 2Rule 3Rule 4Rule 5Rule 6

Crazy policy Stupid Rule 1Bureaucratic Rule 2Crazy Rule 3Bla-Bla Rule 4

Policies




Acceptance 1

Definition of Done Rule 1Rule 2Rule 3Rule 4Rule 5Rule 6

Crazy policy Stupid Rule 1Bureaucratic Rule 2Crazy Rule 3Bla-Bla Rule 4

Policies

Continues improvements

AGILE METHODOLOGY

Thank you for your attention!