Agile and lean methods for managing application development process

(1)

(2)

Application development lifecycle model

 To support the planning and management of

activities required in the production of e.g. goods, software, or information systems, various lifecycle models have been developed

 A lifecycle model establish the order in which a

project designs, prototypes, implements, tests, etc., i.e. performs its activities.

 Waterfall

 Code-and-Fix

 Prototyping

23/1/13 Helsinki Metropolia University of Applied Sciences 2

(3)

Waterfall model

Strenghts

The waterfall model performs well for

projects in which you have a stable product definition

 Do such projects exist?

Weaknesses

The waterfall model is inflexible.

 Is it possible to specify the requirements at the beginning of the project?

 Is it possible to design and implement all parts of the application at the same pace?

(4)

Code-and-Fix

Strenghts

No planning and design overhead, time is spend on pure coding

Requires no process management experience.

Weaknesses

Useful only for tiny applications.

In case of real life projects, dangerous!

(5)

Prototyping

Strenghts

Flexibility (with changing requirements) Reduced time and cost

Weaknesses

Can distract developers from properly analyzing the complete project

Can easily result in the code-and-fix development.

• Good for applications with lots of user interaction

• Most Agile Methods rely heavily upon prototyping techniques.

Develop a

prototype, show it to your customer, and refine it based on the feedback

(6)

Overview of lean and agile software development

(7)

Lean software development

 Lean software development is an adaptation of Lean manufacturing principles and practices

 Based on the Toyota Production System

 The core lean principles:

 Eliminate waste

 Extra features (unnecessary functionality)

 Partially done work

 Task switching

 Delays (waiting for work)

 Bureaucracy

 Defects

 Focus on learning and improvement

 Build quality in the process

 Decide as late as possible

 Deliver as fast as possible (customer value)

 Empower the team

(8)

Two Axioms of Lean Software Engineering (David Joyce)

1. It is possible to divide the work into small (value adding)

increments, that can be independently scheduled 2. It is possible to develop any

increment in a continuous flow, from requirement to deployment

(9)

Dividing the work to small increments

(10)

Dividing the work to small increments

Time on the job

Client

Time of getting the first batch Time of whole production

(11)

Agile software development

 A group of software development methodologies based on iterative and incremental development

 Requirements and solutions evolve through collaboration between self-organized cross-functional teams

 Agile Manifesto - values:

1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation

4. Responding to change over following a detailed plan

 Popular Agile methods

 Scrum

 Extreme Programming (XP)

(12)

Scrum overview

Short, time-boxed iterations

(13)

Agile practices

 User stories

 Regular meetings

 Planning meeting

 Daily Stand-up meeting

 Retrospective meeting

 Continuous integration

 Refactoring of code^(*)

(*) Restructuring existing code without changing its external behavior in order to improve its maintainability and extensibility (more readable, less complex, better architecture)

(14)

Kanban

(15)

Background of Kanban

 Kanban is a Japanese word that literally means “signal card”

 In a manufacturing environment, this card is used as a signal to tell an upstream stage in a process to produce more

 Kanban is a pull system

 New work is pulled into a stage in the system when there is capacity to handle it, rather than being pushed based on demand

 The workers at each stage in the process are not allowed to do work unless they are signaled from a downstream stage

 A pull system cannot be overloaded if the capacity of each step has been set appropriately

 The first kanban system for software engineering was implemented at Microsoft beginning in 2004

(16)

Kanban as an Adaptive System to achieve Lean

 The Kanban Method is an adaptive system for catalyzing Lean behaviour (complex, adaptive, emergent behavior)

 Kanban core concepts

 Visualize workflow

 Limit Work-in-Process

 Help work to flow

 Kanban is not a software development methodology

 Does not provide methods for any particular development task, like design or testing

 Kanban teams adopt practices e.g. from agile methods (such as daily stand-up meetings)

(17)

(18)

Kanban workflow

 There is a queue of work, which goes through a number of stages until its done

 When work is completed in a stage, it is pulled downstream for the next stage

(19)

Kanban board

 Work-In-Process (WIP) limits

 The max number of work items that can be in a stage at any moment

 Typically, the work-in-process limits are drawn on the board at the top of each column (or across a span of columns)

 Pull is signaled if the number of cards in a column is less than the indicated limit

 Why WIP is important?

 To deliver new value (e.g. feature) quickly, limit the amount of work done at one time

 Vertical columns for stages (phases) in the workflow, i.e.

activities through which the work progresses

 Input queue (“Backlog”)

 Done stage (”RTS”)

 Work items on cards that are moved from column to column

WIP limit

(20)

Typical Work Item Types (for Kanban cards)

 Incoming work

 E.g. User Story, Use Case, functional requirement, feature, …

 The incoming work type might be hierarchical, such as Epic, a collection of user stories.

 Bug (issue)

 Change Request

 Maintenance

 Refactoring

 Improvement Suggestion

 Blocking Issue

 Support task

(21)

Setting the WIP limits

 WIP limits for work tasks should be set as an average number of items per person, developer pair, or small, collaborative team

 Typically, the limit should be in the range of one to three items per person, pair, or team

 Do not waste time in trying to determine the perfect WIP limit; simply pick a number based on best guess, and make progress

 Adjust the WIP limit empirically if necessary

 There is no magic formula for your choice. You can select a number and then observe whether it is working well. If not, adjust it up or down

(22)

Kanban card conventions

 Use text or color to

communicate the type of work

 Write other necessary

information on the card, e.g.

 work description

 tasks

 assigned team member

 due date

 tracking number

 …

 with digital Kanban board attachments possible

(23)

Web based Kanban boards

 Product offer has grown rapidly in last years

 In your project, use the free Trello tool:

http://trello.com

(24)

Writing user stories

(25)

Writing a user story

 Template: As a <some role>, I want <something>, [so that <some value>]

 Describe who wants, what wants [and what for] in one sentence.

 Do not define any details of the implementation in the user story.

 Examples:

 “As an end user I want to be able to upload my picture to my profile page, so that people can easily identify me”

 “As a knight I want to be able to ride a horse, so that I can move faster” (game character)

(26)

Writing a user story

 Example of breaking down a story into smaller stories:

Henrik Kniberg: Scrum and XP from the Trenches

 Example of breaking down a story into tasks: