Kaizen software development model. Lean, iterative and incremental software development model. Based on ideas and principles of Lean, Agile and IID while incorporating some of principles presented by W.E. Deming. Web site: http://kaizenmodel.org

1. Kaizen model
LEAN, ITERATIVE AND INCREMENTAL DEVELOPMENT

2. 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.

3. 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

4. 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

5. 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

6. 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

7. Structure

8. 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

9. 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

10. 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.

11. 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

12. Milestone lifecycle
Egg Pupa Meta Birth
BA
Tech Lead SME SME
Team Team
Stakeholders
QA Deploy

13. 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.

14. 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

15. 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

16. 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.

17. IMPROVE
HTTP: / /PRYZACH.GITHUB. IO/KAIZEN-SWD-MODEL/
THANK YOU