Kaizen modelLEAN, ITERATIVE AND INCREMENTAL DEVELOPMENT

History◦ SDLC

◦ One of the first software development process. It is associated mostly with Waterfall model and a lot of big/small projects were delivered using it. It is chosen for it’s control, visibility, planning and predictability from management point of view. It was preferred choice for big project in Enterprise environment. In current fast pacing and constantly changing market – its strength results in need to plan upfront, increased development cost/time and inability to adapt to changing requirements.

◦ IID◦ Next “iteration” of software development methodology. It can have the same “steps” as SDLC, but it is more flexible in terms of

planning, need to design upfront and is more adaptable to requirement change. As it’s father – it is proven to work for big projects while providing significant amount of control, visibility, planning and predictability attributed to it’s parent.

◦ Agile◦ Current “iteration” of software development methodology. It is based on Iterative and Incremental Development model and was

meant to be light, flexible, provide visibility and deliver product as fast as possible. It promotes multi functional teams, trust, motivation and collaboration. Currently it is the most widely used methodology in Software Development.

◦ Future◦ As with everything – there are always two sides to coin - there are always constraints and there is always possibility to improve. I

believe that software development can be improved and we should try to do it.

Model

• Sequential development• Predictable• Easy to understand• Performs comprehensive

planning• Widely adopted by

Enterprises• Suitable for big projects

• Iterative development• Reasonably adaptive and

predictable• Suitable for big projects

• Iterative development• Adaptive• Simplified process• Multifunctional teams• Self organizing teams• Shared accountability

Waterfall IID Scrum

Formal Informal

• Very formal• Sometimes planning ahead is impossible• Cannot cope with requirement change• Delay at one stage would result in delay of whole

development• Unavailability of person – means stop to whole

process• Tends to miss deadlines and go over budget

Constraints

Waterfall

• No single decision point• Requirement change is permitted but due to

undefined procedure, sometimes, results in chaos• Multifunctional teams (jack of all trades)• Has issues with big and „long” projects• Sometimes suffers from delivery of implementation

not according to expectations• Tendency to slide into endless development• Less formal development presents issues for

Enterprises.

Scrum

• Two extremes of software development• No process established to track waste• No process established to promote talent /

innovation

Shared

Kaizen model◦ Iterative development

◦ Is based on Iterative and Incremental development model and inherits it’s strength◦ Allows to perform Continuous Integration◦ Proven to be working for big projects◦ Formal enough for Enterprises, but informal enough to be feasible for middle/small sized projects.

◦ Agile development◦ Permits requirement changes◦ Promotes rapid delivery◦ Believes in individuals and interactions over process and tools

◦ Waste tracking◦ Tracking of waste on every stage◦ Removal of activities (or keeping it to minimum) which doesn’t bring value to customer

◦ Talent and Innovation◦ Single vision/direction◦ Promotion of best people for the job◦ Decision are made by experts in the field◦ Improvement of cooperation by removing constraints/waste

◦ Shared effort◦ Daily meetings◦ Decisions are made by pairs

◦ Commitment◦ No more pigs and chickens – everybody is involved

Benefits

Waterfall

• Is based on Iterative and Incremental development model and inherits it’s strength• Provides visibility of waste and continuous improvement of process• Promotes talent and innovation while providing single direction/vision• Promotion of responsibility, involvement and pride in workmanship• Defines involvement and communication between IT and business• Provides significant amount of guidelines to help guide process

• Informal enough to be feasible for small/middle sized projects• Permits requirement changes and defines process for it• Inherits it’s phases within cycle

Scrum• Formal enough for Enterprises and big projects• Single vision/direction• Inherits it’s simplicity and adaptability

vs

vs

Structure

Cycle

Requirements (egg)

• Business requirements• Architecture / high level

design• Technical requirements

Planning (pupa)

• Revision of recycle plan• Definition of milestones• Definition of risks• Creation of POC’s,

prototypes, and definition of services

• Estimation / cycle length

Construction (metamorphosis)

• Daily progress update• Definition of low level

design (SME’s)• Implementation• Brief showcase of

milestones

Delivery (birth)

• Presentation of milestones• Optimization• Automated testing• QA• Delivery• Reflection upon cycle

Cycles of the cycle

• Egg• Pupa

Sub-cycle

• Meta• Birth

Sub-cycle

QA & Delivery

• Egg• Pupa

Sub-cycle

• Meta• Birth

Sub-cycle

QA & Delivery

Cycle 1

Cycle 2

Product

Roles

Tech LeadBA

PM TL

TeamSME’s

• Requirements (business)• Business vision

• Requirements (technical)• Technical leadership /

vision

• Waste tracking (business)• Progress tracking• Communication (business)

• Waste tracking (technical)• Progress tracking• Communication (team)

• Technical guidance• POCs / prototypes / shared

services

• Development

Vision

Direction

Constr.

Roles within cycle

• Both Business and IT are committed to the project• Every role works in pairs which improves cooperation, commitment and enables peer review• Some roles (direction pair) have limited load and can work on few projects at the same time

Egg

BATe

ch Le

ad

Pupa

BATe

ch Le

ad

SME

PM TL

Met

aSM

E

Team

Birt

hTe

am PM TL

Milestone lifecycle

BirthMetaPupaEgg

BA

Tech Lead SME SME

TeamTeam

Stakeholders

QA Deploy

Guidelines◦ Milestones

◦ Every component delivery is a milestone for the project.◦ Every milestone goes through all stages – Requirements, Analysis, Design and Implementation.

◦ Sub-cycles◦ New cycle starts along with third phase (construction).

◦ Pairs◦ Decision are made in pairs - improves cooperation, commitment and enables peer review.◦ Business and IT lead project together.

◦ Cooperation◦ Business and IT work together on project while utilizing knowledge and expertise of each other.◦ Everybody is committed, therefore Business and IT make decision together.

◦ Logs◦ Every important aspect is recorded and reflected upon end of the cycle.

Recycle plan

Egg |

Pupa |

Meta |

Birth |

Vision

Risks

Risks

Constr.

Issues

Issues

Direction

Debt

Debt

Debt

Debt

Checkpoint

Checkpoint

Checkpoint

Checkpoint

Perceived Debt Actual Debtvs Recycle plan

Waste removalCooperation, commitment and shared decision making

Talent promotion and single direction / vision

Shared responsibility, involvement and pride in workmanship

Waste reduce

Egg Pupa Meta Birth Recycle log

Identify Measure Eliminate

Visibility of waste and continuous process improvement

Waste◦ Risks log

◦ Keeps track of Risks associated with the Project.◦ Risks log is updated at every checkpoint.

◦ Issues log◦ Keeps track of Issues associated with the Project.◦ Issues log is updated at every checkpoint.

◦ Debt log◦ Contains two categories – business and technical debt.◦ Every decision, with possible negative impact, ends up in relevant section.◦ Every debt entry have estimated impact (value) attached to it.◦ At end of cycle voting is taking place to visualise actual impact. Later is it possible to identify estimated vs actual impact.

◦ Checkpoints◦ Meetings which allow to add new entries to risks/issues/debt log.◦ Amount of checkpoints is flexible. Recommended amount is 4 (one per each phase), minimum is 1 (final checkpoint).◦ Final checkpoint is crucial in determining waste and defining recycle plan.

◦ Recycle plan◦ Defines actions to be taken to avoid/remove/build around of issue/waste/constraint.◦ Every recycle plan is set to be implemented during next cycle◦ Recycle plan from previous cycle is reviewed during planning (pupa) phase.

IMPROVE

HTTP://PRYZACH.GITHUB.IO/KAIZEN-SWD-MODEL/

THANK YOU