• The Agile Project Manager clan: Mike Cottmeyer, Pat Reed, Michelle Sliger, Brian Bozzuto, including ICAgile visionary Alistair Cockburn
• The Kanban clan: Karl Scotland, Chris Shinkle, Eric Willeke, Mike Cottmeyer, and Brandon Carlson
• The Enterprise Agile clan: Alan Shalloway, Dean Leffingwell, Jim Highsmith, Portia Tung and Mike Cottmeyer
• The Agile Business Analysis clan: Pascal van Cauwenberghe, Shane Hastie, Kevin Brennan, Steve Adoph, Ellen Gottesdiener, and Mary Gorman
• The Agile Testing / Quality Assurance clan: Liz Hendrickson and Lisa Crispin

While some of these people, like myself, may have come from coding backgrounds, none of these people are primarily heads down technical resources. All of these people have spent years – some of us decades – improving our craft. All of these people bring deep experience, passion and knowledge to an area that is deeply necessary to deliver Agile projects to organizations.

It isn’t just about code

I was rankled by comments that came out at the end of the conference from people that I deeply respect that there wasn’t enough technical content at the conference. It wasn’t so much the comments as the context that they were delivered in. The troubling perspective was encapsulated in a post that said, “too much of the content was not technical. It was simple content that could be easily understood and digested.” I have tremendous respect for developers. I used be one – and I was pretty good. But about 15 years ago or so I realized that I could create more value in organization’s by removing the organizational constraints that create difficult environments for developers.

When you get beyond pretty small organizations, just writing code is not enough. In fact, without the capabilities practiced by my Agile Project Management, Kanban, Enterprise Agile, Agile Business Analysis, and Agile Testing clans, you can’t deliver value to customers. And the craft of being great at these in organizations is just as challenging, evolving, and important as any line of code anyone ever wrote.

Excuse me, but are you kidding me

Does anyone really think that the work of these clans is easily understood and digested? Getting organization’s to focus on strategy, then translate the strategy into work that can be developed, then coordinate that development across functions, then ensuring that what is needed is what is delivered, and then implementing the changes necessary to ensure the business receives value is not easily understood and digested. As a matter of fact, I think it is at least as interesting and difficult a problem as writing good code. And I think in the context of leveraging Agile software development in organization’s it is just as valuable and not as well understood.

My Job is Hard, Yours is Easy

A common bias in organization’s is the fundamental attribution error. This is also known as the self-serving bias. This manifests itself when people attribute different circumstances to their experience than they do to the experience of others. I see this all the time when coaching organization’s.  People devalue the contribution of others and overvalue their contribution. This attitude leads to bunkering down in silo’s, organizational conflict, and obstacles to improvement and flow of value.

I have written code in an organization. It is hard. But I have also been responsible for business analysis, project and program management, quality assurance, process improvements, training, organizational design, and change management aspects of projects. All of these are important, all of them are hard. Delivering value for the business requires cadence and flow among these disciplines. As you are making assessments of how simple and easily digestible non-technical content is remember this tendency. Just saying, “My job is hard, and yours is easy”, doesn’t make this assertion true. And it results in value destroying behavior.

What Does Certification Imply

From my experience, a PMP is like a recent college graduate, a medical resident, or a 16-year old who just got their license. They have shown interest in being project managers, have some situational awareness from having participated in projects, have been educated in the fundamentals and share a common language. But they are not prepared to be CEO of a business, an emergency room surgeon, or a cross country truck driver. I am not sure how big a problem this really is.

The Dreyfus Skill Acquisition Model identifies five stages of competence:

• Novice: Basic understanding of concepts. Adherence to rules. No discretionary judgment.
• Advanced Beginning: Situational perception. All aspects of work treated with equal importance.
• Competent: Coping with crowdedness. Formulating routines. Able to recognize patterns.
• Proficient: Holistic view. Senses deviations from the pattern.
• Expert: No longer relies on rules. Based on deep tacit knowledge. Vision of what is possible.

Certification takes you no higher than Advanced Beginner and probably doesn’t guarantee any more than Novice. But a Novice is way ahead of the competence curve from someone who has no idea what to do.  To be a great project manager who can run projects in complex organization unsupervised you probably need to rise to the level of Proficient or Expert. Additionally, Getting beyond Advanced Beginning requires more than just some knowledge. We talk about Knowledge, Skills, and Aptitudes. Beyond project management knowledge, there are soft skills and organizational aptitudes necessary to be successful leading complex projects.

I don’t think that the concern that hiring managers and HR departments place too much weight on the PMP is a real problem. In my conversations with HR managers and hiring managers, they aren’t assuming more than this. The fact that hiring managers are asking for PMP’s as an entry point means that they are looking for a common starting place and basic level of intent and awareness.  If they want to greater level of Skills and Aptitudes then they should interview for these. PMI supports this model through their Project Manager Competency Development Framework.

People Who Can’t or Won’t Earn Certification

I earned my PMP in 1998. I have been active with PMI since then including working as the Deputy Project Manager for OPM3 and my current work as a member of the OPM3 Services Advisory Group and on the board of the PMI Agile Virtual Community. My PMP lapsed in 2001. I have not renewed it. Why? At the time it was partially due to the neglect of not attaining and recording PDU’s and partially due to tilting at this certification windmill. I felt that the real value of PMI was in the community and in advocating for responsible project management. I put my money where my mouth is – I support the community and advocate for responsible project management. I don’t really need my PMP at this point to get a job. If I did, I would have it. In fact, I wish I had kept it as I gained nothing by tilting at the PMP windmill.

If you can’t get a job because you don’t have a PMP or can’t pass the PMP test, then you should get your PMP. Unless you want to be unreasonably stubborn – like I was – or want to continue to not be evaluated for a job. This argument just doesn’t hold water for me. While I have known plenty of super capable, super talented project managers that were PMP-less – they had the language, they had the hard and the soft skills, and they had the organizational aptitudes to be successful. It is a logic fallacy to say that because there are good project managers without PMP’s that you shouldn’t look for PMP’s to be your project managers.

Tilting at Windmills

The shame of this is that there are real issues with project management today. We don’t have a clear enough path for determining Agile Project Managers (ICAgile is looking to address this shortly). HR organization’s fail to interview effectively for situation appropriate Skills and Aptitudes. Many companies don’t invest in the developing project managers further up the Dreyfus model. Organization’s are still poorly designed for adapting to change and supporting project execution.

However, none of this has anything to with the value of the PMP or other types of certification. Certification is the beginning of the journey. It is the first driver’s license, the college degree, acceptance into the residency program. Certification is critically important. It sets the baseline. It establishes the basic body of knowledge that is expected. It creates awareness in HR departments and with hiring managers of what kinds of knowledge they should be looking for.

So, rather than tearing down certification and slandering organization’s that have promoted our profession and created great communities for us – let’s put our energy into:

• creating awareness of the need for further growth
• promoting to individuals and hiring managers the Knowledge, Skills, and Aptitudes needed to climb the Skills Acquisition Model.
• communicating the value that organization’s receive when they are organized to be adaptable and execute strategy well

There is power and benefit in these activities. The continual bashing of certification and the organization’s that support them is just useless tilting at windmills.

Imagine if someone approached you up front and said “I have an idea. Let’s design our product development system like this. First, development is going to take in less then precise requirements. Then development is going to build something from the requirements. Then we are going to deliver this to a separate group that will then figure out how to test it for accuracy. Then that team will test it. When the product doesn’t pass the test we just defined we will return it to development for them to fix it.”   Is this the way that your test organization operates with your development organization? Does the relationship between QA and development seem reasonable? Why are challenges between QA and development so prevalent in our organizations?

We Don’t Understand Quality Assurance

Quality Assurance and Quality Control are different things. We have Quality Assurance organizations – but most often they are involved in Quality Control control activities.

Quality Control: Find defects. These activities are focused on validating the deliverable. They are performed after the product (or some aspect of the product) has been developed. It also enforces fit to specification. This protects production and our customers from getting defective deliverables that do not meet the specification. But when done on a completed product it isn’t doesn’t enable flow and defects found downstream of the deliverable result in rework in development.

Quality Assurance: Prevent defects. These activities are focused on the process used to create the deliverable. They are performed as the product is being developed. So, Quality Assurance should be helping us improve our processes so we don’t create defects in the first place. A key point to this is that creating a common understanding of the specification and how we will validate it up front is really important to eliminating defects.

If your Quality Assurance activities are primarily focused on finding defects and ensuring fit to requirements after the fact then your QA group is primarily doing Quality Control. Getting QA involved in improving the specification communication process through is a good place to start. A specific technique might be exploring communicating acceptance criteria to development with the same examples QA will use to perform acceptance tests.

We Don’t Understand the Cost of Rework

Finding defects after the product has been delivered ensures that you will generate rework. Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.

After the fact testing is also typically done in batches when a release or iteration is delivered to QA from development. Defects uncovered in these batches create bottlenecks at development.  Just like when traffic backs up on the highway, bottlenecks in product development result in a long term cost to the overall system.

We can dramatically reduce the cost and adaptability of the system by reducing this rework. One way to address this defect bottleneck is to perform quality control frequently – not in batches. Another way is to prevent defects through effective quality assurance in specification understanding and in development. This will reduce the number of defects produced that escape to Quality Control.

We Have Designed the Product Development System Wrong

We used to teach that there needed to be a separation of testing and development. Having them both report to the same person was like having the person that wrote the checks in accounting also reconcile the check book. It was too easy to cheat.  We created QA teams that were completely separate from development – and that reported up through different management structures. I was talking to the director of development at a company where the QA and development chains of command meet at the CEO. When you design the organization to QA and development in different silo’s you will make it very difficult to have effective Quality Assurance involvement. You will ensure Quality Control behavior.

This separation made sense at one point (I think). It doesn’t make as much sense today – especially as the resulting silos result in slower delivery times and increased costs. What has changed in the last 10 years is:

• the cost of setting up testing environments is much lower
• our ability to rapidly and frequently produce testable deliverables for these environments is much greater, and
• our ability to perform acceptance, integration, regression, performance, load, and stress testing frequently is enhanced.

Quality Assurance needs to be part of the development team and process. We need to change our thinking around this.

So we need to integrate Quality Assurance very early in the process. We need to ensure early arrival of acceptance test examples to development. But, we still need independent test teams when we are doing large or complex projects that require integration of many team’s outputs. Independent test teams can be running parallel testing or test-immediately-after delivery. When they are getting high quality components, they focus on user experience, performance, load, and stress testing.  Move everything you can into the development teams (enhanced with quality assurance) so you can produce low defect escape rates. Then eliminate the defect bottleneck and increases in cycle time by treating most of the defects at the independent test team as new specifications to development.

We have the Wrong Expectations

We Expect Perfection – Not Improved Value

Our QA organizations tend to be focused on defect identification and perfection in delivery. The focus of QA, and everyone in the organization, needs to be on producing value-add and delighting the customer – not on defect-free code. This doesn’t mean that defects are okay – but every application has some defect or limitation. Unless you are building aircraft navigation systems or other critical systems you are going to deliver some defects. Make sure the defects don’t block business value – but there is a point where it is more important to the customers and business to deliver value.

We Expect Local Optimization – Not Flow

Rather than perfecting Quality Control, QA can add a lot of value helping the organization enhance the flow of value through the entire product development system. Delivering a unit of value requires analysis, development and testing. There is no value delivered internally. The local optimization problem of improving one area at the expense of another is not useful. Crossing the boundaries between analysis, development, and testing is needed to optimize flow of value. The various teams need to figure out how to do it together – not just improve their area.

Expect our Current Constraints to be Permanent

Organizations labor under the belief that their constraints are fixed. Find a way to break down the barriers that lead to your constraints. Don’t accept the current constraints as permanent. Increase thinking at the system level to find ways to improve the product development process.

We Don’t Use the Tools Available to Us

There is an impressive amount of automation and related techniques available at very low cost to help build the QA environment that allows for fast feedback, building on progressively tested levels, and improving opportunities for frequent testing. Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests. This provides a basis for validation and refactoring. Test driven development or test  just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation. This helps everyone work on a stable build and ensures that no one gets way off track. There are automated tools for acceptance testing and some levels of UI testing. When the tools are combined you can build a very powerful regression testing environment that can also rapidly perform performance, load, and stress testing.

The lack of general adoption of these tools probably has multiple roots. Sometimes it can be difficult to leverage all of them with legacy systems. They require new skill sets and generate new artifacts that have to be maintained. On the surface, they automate tests that are currently performed by QA groups and so their is fear and organizational threat. But some subset of these tools should be broadly adopted by each team. QA teams can focus their efforts on valued added items like Exploratory Usability Testing and Release Validation.

Summary

Most organizations are doing QA all wrong. It is time to start doing it right, the cost of low quality in dollars, time, customer satisfaction, and the engagement of employees depends on it.

• Switch their primary focus to Quality Assurance
• Help the organization reduce re-work
• Integrate QA and QC with analysis and the development organization and work to eliminate defects – not just identify themF
• Enable value, flow, and ongoing improvement
• Leverage proven tools and techniques across the Product Development Organization to increase the value delivered

The status quo is not sufficient to meet the needs of most organizations. While not all of these approaches will be right for every situation, the rate of adoption is too low to be justified. There is far too much latent value being tied up in organizations because we are doing QA all wrong.. What obstacles do you see in your organizations?

Sprints

PMBOK 2.1.3 talks about project organization. Figure 2.4 shows a sequential relationship of phases. Each phase has an initiating process, a circular interaction of planning and executing, and a closing process. Figure 2.5 shows an overlapping relationship between phases, where the closing process of a prior phase may overlap with the initiating phase of the next iteration.

The final Lifecycle in section 2.1.3 talks about an iterative relationship. "An iterative relationship, where only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, bu it can reduce the ability to provide long term planning. The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value. It also can entail having all the project team members (e.g. designers, developers, etc.) available throughout the project, or at a minimum for two consecutive phases." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 22.

This model is precisely aligned with the way we run agile project including sprint planning, the sprint, and spring acceptance.

Progressive Elaboration

From Section 1.3 of the PMBOK, What is Project Management? "Because of the potential for change, the project management plan is iterative and goes through progressive elaboration through the project’s life cycle. Progressive elaboration involves continuously improving and detailing a plan as more-detailed and specific information and more accurate estimates become available. Progressive elaboration allows a project management team to manage to a greater level of detail as the project evolves." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 7.

Progressive Elaboration is shown in Figure 1.1 of the relationship between Portfolios, Programs, and Projects

From 5.1.2.8 Collect Requirements->Prototypes. "Prototypes support the concept of progressive elaboration because they are used
in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 109

Self Organization

From 1.1 Purpose of the PMBOK(r) Guide "Good practice does not mean the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 4.

Responding to Change

Chapter 11 – Project Risk Management describes the following processes.

• 11.1 Plan for Risk Management
• 11.2 Identify Risks
• 11.3 Perform Qualitative Analysis
• 11.4 Perform Quantitative Risk Analysis
• 11.5 Plan Risk Responses
• 11.6 Monitor and Control Risks

"Known risks are those that have been identified and analyzed, making it possible to plan responses to those risks. " "To be successful, the organization should be committed to address risk management proactively and consistently throughout the project."

Scope is an input to Risk Management. As the Scope is being progressively elaborated, it follows that Risk Management must also be progressively elaborated. Risk includes Requirements Risk, Technology Risks, Quality Risks, Market Risks, Customer Risks, Prioritization Risks, etc. We plan to manage these risks in Agile through iterations, close customer collaboration, and responding to change. We inspect (learn about requirements, technology, quality, market, customer, and prioritization risk manifestation)
and the team adapts (this is our risk response from our plan).

Summary

These are not squinting at the PMBOK(r) and looking at it sideways. I was working on OPM3(r) Second Edition as the PMBOK Fourth Edition team was working. Making Agile fit, as it was considered a good practice (something that works for
most organizations most of the time in specific circumstance).

You can order a copy of the PMBOK Fourth Edition from Amazon for less than $35 US.

Connectivism in the Enterprise

“When information develops rapidly, the content is no longer the object of learning activities. Instead, the development of the learner’s capacity for ongoing growth (adaptation) becomes the key focus.”

15 Awesome Quotes on Creative Collaboration

"It is the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed." – Charles Darwin

Taming the Agile Enterprise: Value Stream Mapping for Knowledge Work

Value Stream Mapping is a proven and effective way to address challenges within the manufacturing environment, an environment with static processes. This article expands on that, showing ways to
modify it to be compatible with the world of knowledge work, where the challenges are more dynamic, complex and fast paced.

Favorite Tweet of the Week

@rkelly976: My 3yr old got upset, my 5yr old "Dad, explain it to her, don't just tell her". A communication lesson there #pmot #leadership

Kanban, Mental Models, and Double Loop Learning

That means we need to create an environment where:

• valid information is apparent
• it is safe to explore underlying assumptions
• participants are actively involved in controlling their tasks and collaborative problem solving
• the participants are focused on a bigger goal
• we can compare the result of our change actions with the actual outcomes

Capability Development

“The one statistic that for me sums up where China is going is the 60 million qualified university graduates that enter the workforce each year.”

Strategy Is For Amateurs, Logistics Are For Professionals

“…implementation, not strategy, is what usually separates winners from losers in most industries, and generally explains the difference between success and failure in most organizational change efforts, sales campaigns and so on.

Cross Functional Teams Don’t Come Free

“Good communication is both hard and crucial for any organization. It is therefore imperative that we let communication be one of our guiding principles when choosing between the two variants.”

Convincing People

“Trust is a fluctuating resource. Everyone starts with a level of trust. Sometimes this can be negative (for example, criminals). Your interactions with others either increases or decreases the trust. The unfortunate thing about trust is that while it takes a huge effort to build complete trust, a single wrong move can totally deplete it. People have different trusting personalities, ranging from gullible to suspicious. And they may also (rightly) trust you differently on different subjects. For example, while they may accept everything you say on electronics, your advice on car maintenance falls on deaf ears.”

Does a Kanban System Eschew Estimation?

“So kanban teams do not eschew estimation simply because it is hard. Some teams choose not to estimate because they can realise the same benefits that estimation gives with a lower cost.”

Alistair Cockburn, in the Oath of Non-Allegiance, has issued a call to action for the software development community to stop bickering and calling out contending methodologies. He has called for “discussion about whether an idea (agile plan-driven impure whatever) works well in the conditions of the moment.” As someone who has earned his PMP, CSM , received certificates from the Lean Enterprise Institute, and who completed David Anderson’s Kanban Coaching workshop – I have had the opportunity to see this bickering up close. I have occasionally even as the target of it.  Here is Alistair’s call to action:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

This is becoming an increasing familiar theme. We see it in Laura Brandeburg’s Business Analyst Manifesto. It is expressed by by Liz Keogh, Jean Tabaka and Eric Willeke in “A Community of Thinkers”. I am involved in a PMI Agile team where we are trying to make sense out of the benefits associated with bringing together the PMI Body’s of Knowledge (Portfolio, Program, and Project) in the context of Agile. I am working with the IIBA’s Agile Business Analyst core team to express the Business Analysis Body of Knowledge in an Agile fashion. I also participate in various Yahoo and Google groups where we are working at having these kinds of conversations involving Kanban and Lean.

These teams and discussion groups bring together practioners and thought leaders from various communities working to understand and to share. Sometimes the discussions get heated. You have a lot of successful, intelligent people sharing their experiences and trying to make sense out of their successes while simultaneously trying to expand their world view. The awesome thing is that there is a lot of learning and connecting going on in these communities.

You may want to protect your turf -  but this is the future. The tools and resources that support software development have improved orders of magnitudes in the last two decades. It’s crazy to believe we don’t have a long way to go to figure out the best ways to deliver software – especially at the enterprise.  Tom Peters quotes General Eric Shinseki, Chief of Staff, U.S. Army – “If you don’t like change, you’re going to like irrelevance even less.” I choose to join the community who is looking for ways to honor the fundamental premise of the Agile Manifesto – We are uncovering better ways of developing software by doing it and helping others do it.

Theory in Use and Espoused Theory

Recently, I have seen several references to Chris Argyris in the Agile community. Argyris is an American business theorist who developed a way of explaining organizational behavior called Action Science. In Action Science he describes two simultaneous mental models that make it difficult to create change in an organization. The first is our Espoused Theory. Our Espoused Theory describes the model we say we use to describe how we act (or how we would like others to think we act). Our Theory in Use is one we actually use to make decisions. From a personal standpoint, the Theory in Use is complicated for a number of reasons. It is shaped by how we are participating in the situation. I might respond differently to my brother (who I work with on clients) then I would respond to a client. It is shaped by the threat we feel in the situation. I might respond differently when the situation is under control then I do when I feel threatened. This becomes even more interesting when we are dealing with organization’s and changing the mental models that shape organizational behavior.  Making changes in the stories we tell about why we behave the way we do won’t change our decision. A key to making change is to intervene at the Theory in Use.

Model I-Inhibiting Double Loop Learning

Argyris tells us that when human beings deal with issues that are embarrassing or threatening, their reasoning and actions conform to a model called Model I. Trying to make change in a Model I organization is difficult because you are dealing with their Espoused Theory. It is neither rewarding nor safe for them to explore or actually change their mental models and decision rules – so there is a wide gap between their Espoused Theory and their Theory in Use. The defensive behavior in Model I organization’s create a vicious make this divide even greater. Model I organizations have the following values and supporting behaviors.

1. Define goals and try to achieve them. Participants rarely develop mutual definition of purposes – nor are they open to altering their perception of the task. Participants plan actions secretly and  and manipulate others to  agree with a their definition of the situation.
2. Maximize winning and minimize losing. Participants feel that once they have decided on their individual goals it is sign of weakness to change them.
3. Minimize generating or expressing negative feelings. Expressing or permitting others to express feelings is a bad strategy. Participants unilaterally protect themselves.
4. Be rational. Interactions are objective discussions of the issues.Participants withhold the truth, suppress feelings, and offer false sympathy to others.

Model I behavior results in organizational defensive behaviors that block exploring underlying mental models and the resulting maturity that arises. Most organizations exhibit Model I values and behavior most of the time.

Model II-Encouraging Double Loop Learning

Argyris describes a much more productive type of organization that he calls Model II. In a Model II organization, it is safe and rewarding to the participants to explore underlying mental models and decision rules. Model II organizations have the following values and supporting behaviors.

1. Valid information. Participants design environments where accurate information is shared and underlying assumptions can be openly explored.
2. Free and informed choice. The participants jointly control tasks and focus on collaborative problem solving.
3. Internal commitment. The participants jointly protect each other in learning and risk taking. Mental models and decision rules are jointly explored.

Model II behavior results in organizational behavior that enhances underlying learning. High maturity organizations exhibit Model II values and behavior.

Kanban and Action Science

So, if we want double loop learning (and we do), we want to promote Model II values and behavior. That means we need to create an environment where:

• valid information is apparent
• it is safe to explore underlying assumptions
• participants are actively involved in controlling their tasks and collaborative problem solving
• the participants are focused on a bigger goal
• we can compare the result of our change actions with the actual outcomes

Kanban explicitly creates this environment. The board, the tasks on the board, and the metrics make valid information readily available. The visualization of the work helps make it safe to explore underlying assumptions. You are no longer looking to cast blame, you are looking for an understanding of the system – it is depersonalized. The participants are involved in defining the board, the policies, and participate in problem solving on the board. The board and the focus on reducing lead time, reducing defects, and the policies changes the focus of the team to the bigger goal. Finally, the data available to us helps us make sure the improvements we attempt are achieved and sustained.

Kanban and Maturity

Chris Argyris’s intervention method for developing Model II behavior is simple. Map the system, internalize the map, test the model, invent solutions, intervene and study the impact. Kanban puts a simple, actionable model of this in place. Even better than the single cycle intervention model, the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.

Further Reading

Argyris, C. and Schön, D. (1996) Organizational learning II: Theory, method and practice, Reading, Mass: Addison Wesley.

Argyris, C. (1993) Knowledge for Action: A guide for overcoming barriers to organizational change, San Francisco, CA: John Wiley & Sons, Inc.

Powered by Twitter Tools

Powered by Twitter Tools