We do an experiment I tried to work with things you might have around Please see if you can find 5 pens and a piece of paper (A4 size) If you don ’ t have 5 pens, 2 or 3 will also work.
Introduction of me: Agile coach Worked in the industry over 15 years, have a development brand Etc.etc.
If you have to produce the same thing day in day out - an assembly line might work. Then a defined process might work for you. Based on separated activities with a defined input and output.
The outcome must be known and well defined, it already has been achieved more than once. Since the order of the activities has a clear order, delay of one step has a direct impact on the total chain of activities and throughput of production. This is why each activity is monitored and measured for efficiency. This type of process control works well with ordered systems in simple or complicated domains
The outcome must be known and well defined, it already has been achieved more than once. Since the order of the activities has a clear order, delay of one step has a direct impact on the total chain of activities and throughput of production. This is why each activity is monitored and measured for efficiency. This type of process control works well with ordered systems in simple or complicated domains Handover, with the responsibility now resting on the recipient
Off course you should only change 1 thing at a time.
Creating software is a creative exercise. It is about solving the problem ONCE. There is no production issue in IT. The Team is ONLY responsible for Software Quality (not hours worked, not customer satisfaction, etc. etc.)
Use the example how many cars drive on the A2.
Use the example how many cars drive on the A2. Feedback: Keywords and bullets - enthousiaster
Although the Cynefin Framework is too big a topic for this webinar (Dave Snowden offers a 4 day course), But I wanted to show you the need for an Empirical approach. In SW dev we are mostly in the complex domain in todays software development projects, Sense making, opposed to categorization models. Sensemaking iswhat we do when individuals are attempting to make sense of observed data.
This slide should probably be taken out.
This slide should probably be taken out.
This slide should probably be taken out.
This slide should probably be taken out.
Simple - Ordered system, we are experienced, we sense and decide what to do Complicated - Ordered system, we are not experienced, we analyze (with expert) and decide what to do Complex - Hard to predict, no causality,
Simple - Ordered system, we are experienced, we sense and decide what to do Complicated - Ordered system, we are not experienced, we analyze (with expert) and decide what to do Complex - Hard to predict, no causality,
Simple - Ordered system, we are experienced, we sense and decide what to do Complicated - Ordered system, we are not experienced, we analyze (with expert) and decide what to do Complex - Hard to predict, no causality,
Simple - Ordered system, we are experienced, we sense and decide what to do Complicated - Ordered system, we are not experienced, we analyze (with expert) and decide what to do Complex - Hard to predict, no causality,
Although the Cynefin Framework is too big a topic for this webinar (Dave Snowden offers a 4 day course), But I wanted to show you the need for an Empirical approach. In SW dev we are mostly in the complex domain in todays software development projects, Sense making, opposed to categorization models. Sensemaking iswhat we do when individuals are attempting to make sense of observed data.
If you have worked in on a waterfall project as a developer, you probably encountered that the technical design was often less than perfect in practice. Also on a functional level things sometimes didn’t add up, and required changes to the design. Changes were hard, documentation and technical design needed to be updated, and we needed to charge our clients extra (remember dealing with CRs?)
If you have worked in on a waterfall project as a developer, you probably encountered that the technical design was often less than perfect in practice. Also on a functional level things sometimes didn’t add up, and required changes to the design. Changes were hard, documentation and technical design needed to be updated, and we needed to charge our clients extra (remember dealing with CRs?)
A MVR is a trimmed down version of the end product, by focussing on what is really needed.
A MVR is a trimmed down version of the end product, by focusing on what is really needed. Feedback: Minder text in bullets
When a team gives you as a manager some suggestions with what they can work more efficiently, it would be stupid to ignore them, right? Even failed experiments have value, they are still learning's and they may provide an inspiration for new experiments.
When a team gives you as a manager some suggestions with what they can work more efficiently, it would be stupid to ignore them, right? Even failed experiments have value, they are still learning's and they may provide an inspiration for new experiments.
You probably know
Toyota had little defects and low call back. GM had lots of defects and high callback rate. Workforce in Fremont was also considered the worst of the GM plants
The workers were very happy no more strikes the quality rates were almost as good as the factories in Japan
They also thought it was strange they hired a lot of the unmotivated staff back.
Some of the GM staff had worked in NUMMI or were trained by Toyota Photograph every inch.