Will allow to separate two types of waste and analyse/address them in more efficient way

In case of questions – they are first contact point and can make final decision about respective debt

Secondary debt owners are BA (business) and Tech Lead (technical). In case first contact point is not available – secondary contact point can answer questions and make final decision about respective debt

Limiting amount of waste per cycle allowed is good idea and would allow restart cycle with “clean sheet”

If possible/current waste was identified by Vision team - they make mutual decision about adding it to the Debt log

Example: if BA wasn't able to finish with business requirements and requested for this milestone to be included in current cycle – waste is on business side and should be added to business debt.

Example: if Tech Lead wasn't able to finish with technical requirements and requested for this milestone to be included in current cycle – waste is on technical side and should be added to technical debt.

If possible/current waste was identified by Direction team - they make mutual decision about adding it to the Debt log

Example: if PM requested to perform additional and/or undefined report (additionally to existing ones / above standard requirement) – waste is on business side and should be added to business debt.

Example: if TL haven't submitted check-list for code review and requested to perform it without one – waste is on technical side and should be added to technical debt.

If possible/current waste was identified by Construction team - they make mutual decision about adding it to the Debt log

Example: if Technical Lead offers solution with which SME's / Team does not agree, but are requested to implement it – debt is recorded.

Example: if SME offers implementation with which Team does not agree, but are requested to implement it – debt is recorded.

Debt analysis is not just one of the most important aspects of final phase, but the whole cycle as well

If the same items appear in debt log more that two cycles in a row - process should be analysed and improved

Goal of debt is not to track somebody's mistakes, but is to track waste so we won't have to go through the same issues the next time

Recommended duration is 1h. Pair BA+Tech Lead (with PM+TL) analyse progress so far and discuss/update risks, issues and debt log.

Recommended duration is 2h. PM+TL with BA+Tech Lead analyse progress so far and discuss/update risks, issues and debt log.

Recommended duration is 2h. Team+SME's with PM+TL reflect upon progress so far and discuss/update risks, issues and debt log.

Recommended duration is 4-8h. Everybody reflects upon progress so far and discusses/updates risks, issues and debt log. Next step - would be final vote of debt value (details in logs section). Afterwards - all logs should be analysed and recycle plan should be compiled. It is important to look at dynamics in all logs (between phases) and trace risks which became issues; issues which left unattended and generated debt; and debt which was valued as low but turned out to be very high.

Milestones log owner is Vision pair. Amount of milestone details is defined on per project basis: for short cycles and cases where developers have good understanding of business and technical requirements – amount of details can be kept to minimum, but as amount of milestones and/or size of time rises – it is very important to provide sufficient amount of details (might need consultation with a Team). It is better to overdo rather than provide too little information.

Risks log owner is Vision and Direction pairs. Risks log can be filled according to any preferred Project Management standard template.

Issues log owner is Construction pair with possible support from Direction pair. Issues log is filled according to any preferred Project Management standard template.

Debt log owner is Direction pair. Every debt log should keep description of the debt (enough to identify it to outside party) with 3 values: perceived debt value (provided by requester), perceived debt value (provided by Direction pair) and final value - actual debt value - would be defined and entered during last checkpoint. During said checkpoint meeting – every item in debt log is voted (by everyone) and actual debt value is entered. By doing so - we could visualize the difference between perceived debt (during development) and actual debt of the project which, in turn, would allow us to identify "icebergs" and "overblown" debt and compile Recycle plan accordingly.

Recycle plan owner is Direction pair. It is the one of the most important part of delivery (birth) phase and it is strongly advisable to include everyone in discussion and brainstorming sessions. Risks and issues logs (from all checkpoints) are analysed, as it is important to understand which risks turned into issues and, consequently, which issues created debt. After debt log goes through voting and perceived debt was compared (by everyone) with actual debt - improvement plan is compiled. Debt log serves as main source of information and ordering for recycle plan.

When people share same interests and goals, they become connected to their co-workers - which usually leads to more positive work atmosphere and experience

Big amount of documentation with no proper search system increases learning curve and amount of time spent with no guarantee that needed information would actually be found

Failure to find relevant information would require to contact somebody in order to get it, which, consequently, creates additional unplanned workload on that person and creates dependency for the project

Incorrect/outdated document might lead to incorrect solutions and implementations

Sometimes it is better to use little older technology instead of spending huge amount of time recruiting people with right knowledge

Some newest technologies might not be ready for that specific usage

The cheapest way is to ask another(more experienced) department/entity to look at your current processes and procedures.

Try to get feedback from your partners as they might be able to evaluate your entity from different perspective

During first few month every small detail/change is very visible for newcomer and you might want to reuse that fact to improve your process/standards/procedures/tools etc.

Every newcomer comes with their experience from previous workplace and might offer solution to the your problem which was already successfully tackled there

For those who are interested - teach engineers business side of the company

For those who are interested – provide some basic technical seminars

Understanding business goals and what brings value for customer might improve final product produced by engineers

Understanding basic technical limitations/constraints/challenges might make requirements, produced by business, more feasible and easier to implement

Selecting right people requires effort, time and proper procedures

Right people would require less management, would be more motivated and would deliver better product with good quality

On other side – incorrect people would require more managing, would be unsatisfied and unhappy and might not be able to deliver good quality

"Tie" process with positive emotions and unite everyone under single goal

Pride in workmanship increases involvement and productivity

Improves cooperation as everybody share the same goal

It is easier to change 20% of company by 80%, than change 80% by 20%

Due to size - experiments cannot be performed on huge scale. Start with small entities as proof of concept

Enterprises are slow to change due to size, and change should be started at most agile/lean/adaptive entities and slowly spread across the company

Entities are most eager to change - absorb change most efficiently, others - not so much

Due to their eagerness to change and adaptability - experience of successful entities might not be completely copied to less successful ones

During application of experience of most successful entities (that 20%) - adapt solution on the fly to meet demands of 80%. Not everyone has capacity/experience/skills to change as quickly and efficiently as the most successful ones

Guidelines would shorten learning curve and would allow to work more efficiently for newcomers

Guidelines would allow to avoid responsibility conflicts, as it would clearly state most important responsibilities and guide its implementation

Meetings are great way to share knowledge and communicate between group of people, but if it goes out of the control, in future, it might hurt cooperation

Meeting chair should be trained to control and mitigate possible issues during the meetings

IT is constantly changing and just in five years technology may become deprecated, that's why it is important to invest constantly into skills of your resources

Technical presentations/seminars to improve presentation skills for those who want

Showing/presentation alone isn't the most effective form of training

Showing/presentation should be used in conjunction with practical exercises during or right after the training

Creating proper atmosphere would drive people to constantly innovate and create better products

It is very tricky, but with right team and atmosphere - will promote creativity and innovation

This is place where most implementations miss opportunity to simplify system and should be part of strategy for every project

Shared services would provide guidelines, increase efficiency and decrease time/budget of the project

Keep API simple and avoid exposing internal implementation

Outside teams should be able to use it without additional explanation and won't be needing to gain knowledge of underlying system

Employees have first hand experience with those problems as they fight them on daily basis

Experience fighting those problems on daily basis provides them with needed expertise to offer effective solution

Try to focus not only on ideas, but also ask people about what value they can bring to customer (in short/mid/long term)

Ask for ideas together with it's implementation/direction, as one cannot be done without the other

Process starts with right idea, but it is completed only with right implementation

Involvement and investment into whole lifecycle of the product is important and would allow to make best decisions

Please be aware that outside consultant might not have complete understanding of the company's infrastructure, so additional training might be needed

If consultant is affiliated with some outside company – require proof of concept and integration with all existing services, as it is place where it fails most often

Adoption of new product/system/service is often connected to demise of previous one and should be measured

If new product/system/service won't be replacing but would served as addition – it would be needing additional support/resources and, again, should be measured

It is recommended that analysis to be performed not for task at hand - but for whole system

It is dangerous to create “local” solution which might increase complexity or even break existing system

For support tasks - please use Kaizen lite

Every additional element in the system/process requires additional maintenance/resources/support

Complicated system require more reporting / measuring / evaluation / planning and would require more support and maintenance

Chaotic knowledge transfer process might lead to incorrect implementation and consequent service failure

Everything is subjective - even learning process: we remember only our understanding of subject, but that might be a little different than author meant. With every subsequent retelling of the same story - additional elements are introduced to it. Please get knowledge from source if possible (from qualified trainer).

Everyone is selected based on skills/experience need and failure to utilize that leads to failure/waste

Business cannot define technical architecture/design as they are not committed nor are responsible for it. Also they might not be fully aware of current technical requirements and technical solutions

IT cannot define business process/procedures as they are not committed nor are responsible for it. Also they might not be fully aware of current requirements and market

Saving money at beginning might result in more extensive/expensive support needed

Try to simplify, optimize and this would result in doing more with less

IT should stop saying “no” to everything, as this would lead to loss of competitiveness. Keep it balanced

Management should stop saying “yes” to everything, as it would lead to impossible projects and loss of money and competitiveness. Keep it balanced

This is one of the biggest waste of enterprises. Keep it simple and short

Reports should be defined by Management before they are requested - as IT doesn't know what values are important to the business

Management should perform analysis of current/available systems and requests report which is possible with current infrastructure or request to create one (as separate project with separate budget)

Sometimes assignments are given without synchronizing with others - which creates invisible overload on resources and might lead to failure of projects

One small task might not have big impact, but as experience shows - amount of tasks only grows with time and might be source of overload and waste for current project

Usage of few reporting tools at the same time provides additional stress as it requires constant attention, synchronization and time - and should be avoided as much as possible

Use formal process for middle and big projects

Use less formal process for small project, as usage of formal methods might result in project going over deadline/budget while not bringing any benefits

Keep in mind that people promote people with skills similar to the ones they have

Every subsequent addition would be focused on learning rather than defining project

They are vital for every project, but keeping them to minimum is essential

Too frequent meetings, which doesn't bring value to the team, might be exhausting and might impact quality

Get feedback from participants about frequency of meetings and define it based on needs and wishes

Define, where applicable, guidelines as they might guide meeting direction

Practices used in Business might not work as well in IT

People working in Business and IT might not have the same interests, so try to adapt to each needs and provide comfortable atmosphere for everyone

Overload is almost guaranteed source of waste

Perform assignment tracking and load tracking to properly assess load on a person

If no tracking system is available – get frequent feedback from every member directly

Due to lack of understanding / limited cooperation - sometimes Business is not comfortable working with IT directly which, later, might result in waste

Try to manage atmosphere and cooperation between entities - so it would promote efficient cooperation

If business requirements were not transferred properly because of it – project/product and, consequently, business would suffer

Sometimes update (new version) doesn't bring new features, but in the end it just increases complexity and decreases visibility

Migrating to new product should be justified by creating extensive proof of concept, not only by numbers provided by manufacturer

Marketing material have goal - sell. Please advise with SME's before making decisions

Training, requirements clarifying, realigning of tasks, knowledge transfer and additional management require time and investment of current members

The reason behind late delivery - is lack of time/resources and increasing load on those people would only make delivery even later

People with not enough skills/experience might deliver/provide incorrect service and/or lead project into incorrect direction

People with not enough skills/experience would require more time to perform activities

Incorrect/inefficient knowledge might be transferred to other members and would increase waste generation within organization

First entity shouldn't demand knowledge of it's processes from second entity, as they have their own processes to follow and deadlines to keep

Instead of demanding – provide knowledge transfer/meetings for both sides to understand processes within each entity better

In manufacturing you are creating one product many times, where in software development you create new product every time

In manufacturing – before product is produced – single extensive R&D is performed, while in software development it is performed along with every implementation

Success is defined by numbers and sometimes the one who produces them tends to put it in it's favour

Taking full credit for success takes pride in workmanship from those who were involved in it

Because of above - decreases involvement, cooperation and quality of delivery

If person haven't told that something is wrong - that person is right to assume that everything is done correctly and should be continued

Knowing your weaknesses/issues allows you to spend time on minimising/improving them

It is very sensitive matter and should be handled carefully

The bigger the company - the most likely that occur

Might be significant source of business waste as some people won't know who to listen and what to do

Conflict of responsibility results in confusion, duplicated solutions, multiple decisions and not working solutions

Responsibilities should be clearly defined (on paper) and should be available for everyone to read (not only for that role)

During definition of responsibilities - other roles should be checked if there is no conflicts

Ending up with only bad choices means that (in any case) bad choice would be selected, and it is irrelevant that it was "lesser" evil

Process which lead to bad choices only - might be flawed and should be re-examined

Ability to constantly submit new requirements and get new features is tempting and might result in endless stream of requests and, consequently, endless development

Before project start - describe what functionality is essential and control new feature requests

Predictable amount of work would result in predictable development timeline and deadline

Knowledge of technology without practical usage might produce waste, as majority of them have limitations which are not communicated ahead

Practical experience would allow more efficient usage of technology

Ending up with only bad choices means that (in any case) bad choice would be selected, and it is irrelevant that it was "lesser" evil

Solution which lead to bad choices only - might be flawed and should be re-examined

It is important to have single understanding and vision to deliver quality product

Procedure for knowledge transfer should be established

Knowledge transfer require time to prepare, as well as willing and skilled member to perform it

Not every engineer born to be a trainer. Please nominate the ones with relevant skills, talents and will to perform it

Engineer shared/common services very carefully

If one (bad service) was identified - it should be assigned with high priority and, consequently, rewritten/improved

It is better to follow less demanding (baseline) requirements, than don't follow anything

Requirements which impossible to meet impacts morale and lowers commitment to quality

Due to lack of commitment to quality and lower morale - pride of workmanship might be affected

If code is checked by person without knowledge of requirements/system/design – waste might be introduced to the system

This model promotes pride in workmanship and claims that code is bad might have negative impact on cooperation between two members

High amount of junior members in the team would lead to lack of expertise and experience and, consequently, might lead to lower quality of delivery

High amount of senior members in the team would lead to lost opportunity to mentor and knowledge transfer to less experienced members