paint-brush
On Bloom's Taxonomy and Why Agile Training is Not Enoughby@frank-velazquez
161 reads

On Bloom's Taxonomy and Why Agile Training is Not Enough

by Efrain (Frank) VelazquezJanuary 19th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

A transition from project management to Agile is arguably among the toughest for organizations. Many organizations see employee training and employee development as synonymous. Training and education is a vital component of an ongoing employee development strategy, authors say. It is easy, and dismayingly common, for organizations to slide back into old ways of working when the going gets tough, they say. Organizations may choose to train internal employees, outsource the work to experts, or blend the two approaches by providing some level of training and education.

Company Mentioned

Mention Thumbnail
featured image - On Bloom's Taxonomy and Why Agile Training is Not Enough
Efrain (Frank) Velazquez HackerNoon profile picture

Disappointed with the results of Agile training? There is a better way.

Your organization spent a lot of money on “Agile training”. You, your co-workers, and/or subordinates are newly-minted certified practitioners of some flavor of Agile, most likely Scrum. If your organizational culture is rooted in traditional project management, this may be your first encounter with Agile. It may also be the case that your training is part of an organizational Agile implementation initiative. So, how is that initiative going?

If your organizational transition to Agile is like most others, painfully. Changing organizational culture is incredibly hard, no matter which direction that change takes, and a transition from traditional project management to Agile is arguably among the toughest. It is easy, and dismayingly common, for organizations to slide back into old ways of working when the going gets tough.

One of the biggest reasons Agile adoption efforts fail is the way many organizations view, not just Agile training, but employee development in general. They treat employee training and employee development or education as synonymous. They see training only as standalone discrete activities or events to attend rather than as a vital component of an ongoing employee development strategy.

Thus, many organizations deem receiving an Agile certification after a two-day training class enough for recipients to implement and sustain an Agile approach on their own. Employee proficiency in Agile, or any other discipline or domain, requires training, education, practical experience, and coaching to prepare employees for the challenges they will encounter implementing the Agile approach at their organizations.

Training vs. Education

Let’s clear up the difference between training and education:

A common misconception is that education only happens in an academic setting and everything we learn outside of that setting is training. Education is mainly about learning how to think critically about a subject and developing the ability to leverage knowledge in new ways and in new situations. Where the learning happens and in what context is irrelevant.

Training and Education

Obviously, we want both practical skills and an understanding of their underlying principles. The question is, to what degree? Should employees learn just enough theory to support their use of practices and techniques? If so, will they have enough mastery of the subject matter to lead its implementation and overcome all the unforeseen challenges they will encounter? On the other hand, how much theory is enough and how will it translate into measurable business or mission impact?

As most often happens in the real world, the answer is frustratingly vague; it depends.

It depends on what the organization wants to achieve and how. What knowledge, skills, and experience does the organization need to achieve its goals and objectives? Organizational strategy must include plans for attracting, developing, and retaining talent. The organization may choose to train internal employees, outsource the work to experts, or blend the two approaches by providing some level of training while fostering knowledge transfer between expert consultants and employees. Each alternative requires different types of training and ongoing education.

At an individual employee level, learning plans must align with the work employees do in support of business or mission goals and objectives by bridging the gap between the skills they currently possess and the skills they need. One employee may only need a narrowly defined skill. For example, a Scrum Master takes a JIRA class to become more proficient at using the tool. Another employee may need to develop analysis, evaluation, and creative skills commensurate to the ambiguous and complex nature of their role. That employee needs training and educational opportunities that enhance his/her current education, skills, and experience. For example, another Scrum Master expressed an interest in becoming an Agile coach. That position requires mastery of Agile frameworks/approaches, experience implementing them, and skills in problem solving, leadership, and customer engagement. That mix of intellectual resources and abilities comes from a combination of training and education.

Bloom’s Taxonomy

A good way to frame discussions about balancing employee development training and education in general, and with respect to Agile adoption specifically, is by couching them in terms of Bloom’s Taxonomy:

In 1956, Benjamin Bloom with collaborators Max Englehart, Edward Furst, Walter Hill, and David Krathwohl published a framework for categorizing educational goals: Taxonomy of Educational Objectives. Familiarly known as Bloom’s Taxonomy, this framework has been applied by generations of K-12 teachers and college instructors in their teaching.
The framework elaborated by Bloom and his collaborators consisted of six major categories: Knowledge, Comprehension, Application, Analysis, Synthesis, and Evaluation. The categories after Knowledge were presented as “skills and abilities,” with the understanding that knowledge was the necessary precondition for putting these skills and abilities into practice.

This section from “Bloom’s Taxonomy” was copied from the original. Used under CC BY Vanderbilt University, licensed under CC BY Agile Cheetah

The intent behind the taxonomy was to move education beyond rote memorization to higher levels of learning.  The taxonomy provided educators a construct for developing learning objectives targeted to achieve criteria associated with each category or levels of learning. 

The taxonomy is hierarchical, thus higher levels of learning subsume lower levels.  In other words, before we can comprehend the material, we must first know and be able to recall the ideas, facts, principles, and theories that make up the material.  To apply the material, we must know it and comprehend it, and so on.

In 2001, Lorin Anderson, a former student of Bloom, and David Krathwohl published a revised version of the taxonomy.  Figure 2 below depicts the revised version.

This work, “Revised Bloom’s Taxonomy”, is a derivative of “Bloom’s Taxonomy“, used under CC BY Vanderbilt University. “Revised Bloom’s Taxonomy” is licensed under CC BY by Agile Cheetah

Agile Training is not Enough

The four tenets of the Agile Manifesto and the 12 Principles of Agile that support those tenets are all that define Agile.  That’s it.  That is the extent of Agile. 

The Agile Manifesto and 12 Principles combined characterize a vision for a way of working.  They do not prescribe how to achieve that vision.  Agile leaves the details of implementation for practitioners and organizations to figure out.  Thus, the proliferation of Agile-based frameworks and approaches.  Some, like Scrum, existed prior to the Manifesto and contributed to its inspiration. 

There are no cookbooks for Agile or for Agile-based frameworks/approaches and it would be foolish to write them.  For Agile implementations to succeed, people must learn beyond the ability to apply the rules of their chosen Agile approach as written.  They must be able to align their ways of working to the Agile approach and understand the consequences of deviating from its rules.  When real-world circumstances conflict with implementing the standard approach, practitioners must be able to:

1) advocate for changes that allow its implementation as per the standard; or

2) when circumstances cannot be changed, seek ways to modify the approach without corrupting it or advocate for a different approach (Agile or non-Agile) that better aligns with project context and/or organizational culture. 

In turn, organizational leadership must share that level of knowledge and understanding of the Agile approach to participate in its adoption (as opposed to merely lending support) in ways that move the implementation forward.

A two-day introductory Scrum (or any other Agile-based approach) certification class is not enough to get people to that level of mastery over the framework.  That training event is only a starting point.  At best, students walk away with a certification that only attests to their ability to remember the training material with a cursory understanding of how to apply it.

The Alternative

As depicted in the figure below, mastery over the Agile-based approach increases as learning progresses up the taxonomy.  A combination of ongoing skills training, practical application/experience, education, and coaching get practitioners up the mastery slope.

The goal is not to make everyone an Agile coach.  Instead, it is to prepare employees and organizational leadership for the roles they will assume as participants in the Agile implementation.  Everyone involved must:

  1. Know the Agile Manifesto, the 12 Principles, and the rules of the chosen Agile framework/approach well enough to recall them in detail (Remember)
  2. Understand the foundational material well enough to explain it and recognize its proper implementation (Understand)
  3. Be able to apply the rules of the approach in accordance with the Agile Manifesto and the 12 Principles (Apply)

The bottom three learning levels represent the learning levels required to effectively participate in an Agile implementation.  They also serve as the foundation for the higher order learning required to successfully establish and maintain an Agile implementation. 

Proficiency at the first three levels equates to the ability to “do” Agile.  It demonstrates an understanding of the rules and mechanics of the approach.  Further practice, coaching, and independent study set the stage for further progression up the taxonomy.  Participants gain valuable insights along the way which further clarify and reinforce their understanding of the framework/approach.

In short time, participants begin acquiring skills from the top three learning levels of the taxonomy.  This is an opportunity to build on the hard-won knowledge, skills, and insights they gained at the lower levels.  Coaching and self-study are particularly effective ways to foster further Agile approach mastery. An effective employee development plan includes additional training that addresses higher-order skillset gaps.  These training gaps could be related to the Agile approach, technical knowledge, or “soft skills” such as leadership and communication. 

As participants mature as Agilists, their own curiosity motivates them to seek ways to further their mastery and to try innovative approaches that best align to their work and organizational context.  At this level, the emphasis shifts from “doing” Agile to “being” Agile.

Conclusion

Agile is a simple construct. That does not make its implementation easy. The biggest hurdle to successful Agile adoption is not learning the mechanics of an Agile approach. It is, instead, overcoming the cultural baggage of over 150 years of Taylorist-based project management culture. That culture has been the dominant managerial culture for most of that time and Agile is a radical departure from that mindset. That is precisely why ongoing training and education are so vital to the successful implementation of Agile.