Kaizen model 
LEAN, 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 
Waterfall IID Scrum 
• 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 
Formal Informal
Constraints 
Waterfall 
• 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 
Scrum 
• 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. 
• 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 
• 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 
Waterfall 
• 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 
Lead 
BA 
PM TL 
SME’s Team 
• 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
Milestone lifecycle 
Egg Pupa Meta Birth 
BA 
Tech Lead SME SME 
Team Team 
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 | 
Vision 
Risks 
Risks 
Meta | 
Birth | 
Constr. 
Issues 
Issues 
Direction 
Debt 
Debt 
Debt 
Debt 
Checkpoint 
Checkpoint 
Checkpoint 
Checkpoint 
Perceived Debt vs Actual Debt Recycle plan
Waste removal 
Cooperation, commitment and shared decision making 
Talent promotion and single direction / vision 
Shared responsibility, involvement and pride in workmanship 
Visibility of waste and continuous process improvement 
Waste reduce 
Egg Pupa Meta Birth Recycle log 
Identify Measure Eliminate
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