Agile in non-software development

This blog collects a number of sources on the subject of applying Agile methods to areas other than software development.

The Agile Manifesto

"The Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more."

PODSI and PDCA

Plan, Orientate, Design, Select, & Iterate (PODSI)
Plan by identifying the potential target, vision, and feasibility of the project that will ensure the active participation of all stakeholders. Determine if the managers are indeed going to collaborate or are willing to learn to collaborate. If they simply want you to be an order-taker then, “run my friend run, run as fast as you can!” Find a project with people who desire to collaborate.
Orientate in order to recognize the level of the complexity of the environment (Cynefin) so that the initial learning architecture can be started to solve the problem. Use Exemplary Performers and/or Subject Matter Experts to help identify the complexity of the environment.
Design by using a collaborative approach or model so that only the minimum required knowledge and skills are taught that will resolve the problem. Build other useful benefits into the learning process during the final iterations.
Select the correct learning objects, processes, and tools that will provide the needed knowledge and skills that support both formal and informal learning — the use of small learning objects will increase the speed of iterations and allow you to more easily transform parts of the instruction into informal and nonformal learning.
Iterate by prototyping the initial design and to determine what other performance support technologies are required that will fully support the learners' quest to better performance. Use After Action Reviews to transform deficiencies into actionable items. Transform the formal learning objects to informal or nonformal learning as possible.
Don Clark - Agile Design


Plan-Do-Check-Adjust
Plan-Do-Check-Adjust (PDCA) is known as the model for continuous improvement. The four-phase approach provides a simplified sequence to carrying out change. And, it is so much more: it is a cycle that doesn't necessarily end. Instead, the cycle charts a course for follow-through and allows for true continuous improvement as work and processes evolve to meet the constantly changing needs and expectations of customers.

PDCA encourages us to constantly strive for a "perfect" process, with the understanding that as our customers change, so, too do their needs change. And so by constantly Checking and Adjusting, we can keep pace with our customers' needs and provide products and services that are of value to them.

PDCA Definitions
Plan: Recognize an opportunity and plan a change. Obtain baseline metrics and gather information.

Do: Observe and analyze the current process, design an improved process, test the change.

Check: Review the change, monitor and evaluate the results. (What is working? What have you learned?)

Adjust: Modify and make improvements as needed. If the change didn't work out, begin the cycle again.

CONTINUOUS IMPROVEMENT

No comments:

Post a Comment