Agile-Lean-Scrum

04 Jan 2009 @ 16:00

Agenda
Agile Lean Scrum

Agile - Definitions
Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organising teams with "just enough" ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders [ Scott W, Ambler ] Early delivery of business value. That involves early and regular delivery of working software, a focus on team communications, and close interaction with the users [ Alistair Cockburn ]

Agile Manifesto
4 Values :
Individuals and interactions over processes and tools

[ Self Organizing Team over Control & Command Team. ]

Working software over comprehensive documentation

[ The primary goal of software development is to create software, not documents. Produce no document unless its need is immediate and significant. ]
Customer collaboration over contract negotiation

[ Customer involvement allows us to tune the system to the latest known business value. ] [ Short iterations. Lots of small milestones. ]

Responding to change over following a plan

Agile Manifesto
12 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 time-scale

Business people and developers must work together daily throughout the project.

Agile Manifesto
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.

Agile Manifesto
Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from selforganising teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Agile
Key characteristics : Adaptive responsive to change in needs & requirements via continuous feedback and reflective retrospection. Goal-driven focus on producing executable-results (working functionality) in order of highest business value.

Iterative / feedback-driven short development cycles, frequent releases, regular feedback.

Lean simple design, streamlined processes, elimination of redundant information, minimal intermediate artifacts. Emergent behaviour highly collaborative self-organising teams in close interaction with stakeholders.

Quality - TDD, CI, and continuous re-factoring.

Agile
Agile software development is an umbrella term for several software development methods : Lean Software Development ( LSD ) Scrum XP

Lean
"Lean" fundamentally refers an approach in the manufacturing world that was originally developed by Toyota in the 1950's. Variations : Lean Manufacturing from Toyota (from Taiichi Ohno of Toyota) TPS (Toyota Production System)

Lean Thinking (from Womack and Jones work)

Lean Software Development (from Mary and Tom Poppendieck) Lean Product Development System (from Toyota, as described by Michael Kennedy)

Lean
7 LSD Principles : Eliminate Waste

Build Quality In
Create Knowledge Defer Commitment Deliver Fast Respect People Optimize the Whole

Lean
Principle #1 : Eliminate Waste anything that does not add customer value

any delay that keeps customers from getting value when they want it
untested code, undocumented code, undeployed code unused features, lost knowledge ( relearning ) making the wrong thing or making the thing wrong

Lean
Principle #2 : Build Quality In The point of lean is not to eliminate defects, it is to not have them appear in the first place ( avoiding creating defects in the first place ) Test-and-fix cycles are an indicator of a poor process.

Testing is to prevent defects, not to find them !

[ When a defect is found, you stop-the-line, find its cause, and fix it immediately. ]

Lean
5S ( for Java ) : Sort (Seiri): Reduce the size of the code base. Throw away all unneeded items immediately : remove dead code, unused imports, variables, methods, classes refactor redundant code Systematise (Seiton): Organise the projects and packages. Have a place for everything and everything in its place :

resolve package dependency cycles

minimize dependencies

Lean
Shine (Seiso): Clean up. Problems are more visible when everything is neat and clean :

resolve unit test failures and errors ( passed == 100%)

improve unit test coverage ( > 80%) and unit test performance check AllTests performance resolve checkstyle, PMD, and javadoc warnings Standardize (Seiketsu): Once you get to a clean state, keep it that way. Reduce complexity over time to improve ease of maintenance. Sustain (Shitsuke): Use and follow standard procedures.

Lean
Principle #3 : Create Knowledge It's all about continuous learning and sharing information.

The knowledge about the process, obstacles and product are gathered and shared by the whole team.
Few key recommendations : release a small subset of key features early for review and evaluation perform daily builds and provide rapid feedback from on-going testing

use a modular architecture that enables features to be added more easily

Lean
Principle #4 : Defer Commitment Focus on what customers need to accomplish at that moment in order to allow easier rework and reduce wasted effort. Don't make any decision if you don't have all the information, keep your options open.

Support the business effectively through flexible architectures that are change tolerant.
Design for change ( i.e. Design Patterns ) Provide an approach to design that : handle variations

can change when get more knowledge or new requirement

Lean
Principle #5 : Deliver Fast how to deliver software that our customers don't have time to change their minds.

Lean
Principle #6 : Respect People The team decides what the work is and appreciate their work.

In a lean culture, management supports workers in whatever way is necessary. Support != Dictate

Lean
Principle #7 : Optimize the Whole maximizing the value delivered to the customer not merely maximizing any one (or even all) of the steps in the process. For ex : QA needs to work with the development team to improve the development process ( move up to the front of the development cycle ). The result of not doing this is often a lack of clarity of what is to be built as well as uncertainty as to the quality of what was built.

Scrum
Scrum framework

Roles
Product owner ScrumMaster Team

Ceremonies
Sprint planning Daily stand-up meeting Sprint review Artifacts Sprint retrospective Product backlog Sprint backlog Burndown chart

Scrum - Roles
Product Owner : someone who has the final authority representing the customer's interest in backlog prioritisation and requirements someone from a Marketing role or a key user in internal development, to prioritise the Product Backlog

gathering requirements
prioritise PBI decide the release date & content accept or reject work results

Scrum - Roles
ScrumMaster : a facilitator for the Team and PO

responsible for performing Scrum values & practices

remove all obstacles to success ensure that the team is fully functional & productive enable close cooperation across all roles & functions shepherding the team, shield the team from external interferences

Scrum - Roles
Team : self-organising, but not self-directing

has the right to do everything within the boundaries of the project guidelines to reach the iteration goal
demo work result to the PO

have the responsibility to deliver what they committed to

Scrum - Ceremonies
Daily stand-up meeting : is a status meeting not a report meeting

the team is reporting to each other, not to the Product Owner, Managers or ScrumMaster.
to provide a coordination mechanism for everyone on the project ( where everyone is ) for each team member to make commitments in front of his/her peers track progress identify impediments

Scrum - Estimating
Include all engineering tasks : design

coding ( Java code, GUI, model, etc. )

testing ( unit, functional, regression, etc. ) refactoring peer review technical documentation (?)

Scrum - Retrospective
This is the time to inspect & adapt the process, methods, and teamwork : What went right ? What went wrong ?

What could be improved ?

What happened during this Sprint ? What did we learn ? What did you value most about your contribution for this Sprint ?

Scrum Retrospective using Appreciative Inquiry

Developed by David Cooperrider and colleagues at Case Western Reserve University in the 1980s.
The cooperative search for the best in people, their organisations, and the world around them Appreciations Complaints with recommendations Hopes & wishes iro process

QA & Testing
In Agile Testing : involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing. work with the customer to define acceptance test

coding and testing are part of one process.

write detailed tests for a story as soon as coding begins. Agile testers are proactive. They dont sit and wait for work to come to us. code fairly free of bugs by the time its checked in.

QA & Testing
The job of tests, and the people that develop and runs tests, is to prevent defects, not to find them. A quality assurance organization should champion processes that build quality into the code from the start rather than test quality in later. This is not to say that verification is unnecessary. Final verification is a good idea. It's just that finding defects should be the exception, not the rule, during verification. If verification routinely triggers test-and-fix cycles, then the development process is defective. [ Mary and Tom Poppendieck ] Finding defects / bugs violates :

Eliminate Waste
Build Quality In

Optimise the Whole

Defect Prevention Techniques

Prior to coding : design consideration

Coding :
use meaningful assertion ( sanity check ) write readable code check & verify the integrity of all incoming parameters consider all possible error cases

peer reviews
Testing

Simple Design
We are not fortune-teller and cannot foresee all the market changes. Don't try to solve big problems in one go ( BDUF ) It is not a design that takes the least time or cut & paste. This is a bad code. Think about tomorrow, but design, test and code for todays need.

The design should :

meet the current requirements, easily maintain, code clarity, and extensible

doesnt have a huge impact when changing it later

requires continuous improvement through refactoring & incremental design & architecture. use the Design Pattern [GoF] and OO Design & Patterns

Collective Code Ownership

Allows not expects everyone to fix the problems (duplication, unclear names, poorly designed code, etc) they find, it doesn't matter who wrote it. It's your code. With self-organising team, refactoring, and continuous integration, this will lead to a high quality code.

Guidelines
Code Complete : Defensive Programming [8]

Software Quality [20]

Refactoring [24] Self-Documenting Code [32] Clean Code : Smells & Heuristics [17]

End