Why So Many Developers are Fed Up with Agile (Pt. 3)

Top-Down Driven Agile

Table of Contents

No one likes being told how to do their job, especially by people less knowledgeable about the work than themselves. One of the defining characteristics of knowledge workers is that they know more about the work they do than their supervisors.

Knowledge workers amass a wealth of education, training, and experience in their specialties. Their success depends on how well they apply those intellectual resources to their work. Knowledge workers do not merely produce tangible or quantifiable products and services. They help employers or clients achieve business or mission outcomes. Thus, they usually enjoy much greater latitude in determining how they work than workers in traditional service or manufacturing sectors. Software development teams are made up of knowledge workers.

Unfortunately, traditional project management culture is still highly influenced by Taylorist notions regarding work organization and worker management. Too many organizations reflexively assume that management should determine how employees work. This predisposition runs directly counter to the Agile principle of:

Build[ing] projects around motivated individuals, [giving] them the environment and support they need, and trust[ing] them to get the job done.
http://agilemanifesto.org/principles.html

Organizations possessing traditional project management cultures often adopt Agile in ways that largely ignore the perspectives and input of those most affected by the change: software development teams.

This article is the third of a four-part series about why so many developers are fed up with Agile and why so many organizations fail to achieve Agile’s much-touted benefits. The common thread across the series is that what often passes for Agile is anything but Agile.

The other topics covered in the series are:

The Never-Ending Agile Grind – Developers often feel overwhelmed by the constant pressure to produce under tight deadlines.
Greater Visibility & Oversight with Less Control – The “radical transparency” of Agile approaches, such as Scrum and Kanban, is often exploited by management as an opportunity to micromanage development teams.
Changing Expectations for Developers – Developers are moving away from functioning as “order takers”, focused almost exclusively on coding, to collaborating with product owners/managers, sponsors and stakeholders, and customers and end users to define, verify, and validate what they develop. Many technical contributors find this level of direct collaboration difficult to manage alongside their growing list of technical responsibilities.

A Reaction Against Traditional Project Management

Agile software development started as a reaction against the decades-old, heavyweight, project management approach to software development commonly referred to as Waterfall. It began as a collection of “lightweight” software development approaches implemented by a few like-minded, software industry thought leaders.

Realizing their approaches shared a common philosophy, they gathered at a ski resort in Utah in February 2001. There they drafted “The Agile Manifesto for Software Development”. Adoption of the Manifesto and its supporting 12 Principles spread quickly across the software industry. That formulation of what constitutes software development agility helped popularize Agile and shape the ongoing evolution and refinement of Agile approaches.

Agile was a bottom-up movement started by software developers. As stated in the first sentence of the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it.
http://agilemanifesto.org/

Viewed through the lens of management practice at the time, what these early Agilists advocated was disruptive; almost subversive. They carved out space within which they could work without the distractions or frustrations of managerial micromanagement and organizational politics. They broke down organizational silos and included customers and end users in defining, verifying, and validating software solutions. While Agile helped shift software and IT management culture towards becoming more cooperative and participatory, progress has been spotty.

Few organizations fundamentally changed their traditional management cultures to align with Agile. While many digital native companies established during the first two decades of the 21^st century internalized Agile and Lean principles from the start, many (if not most) organizations did not. Traditional project management biases still color how most organizations view Agile. They perceive Agile as a new way of developing software rather than a new way of delivering value through software. For those organizations, Agile is something developers do while the rest of the organization functions as before.

This fundamental mismatch between Agile’s bottom-up culture and top-down traditional project management culture is the primary reason so many Agile implementations go wrong. It is also why those with the most at stake in adopting Agile often have the least say in its implementation.

Aligning Organizations to Agile Delivery

Many organizational leaders are unaware of the need to align their organizations with Agile’s iterative and incremental mode of value delivery. In Agile, value is whatever solution sponsors, stakeholders, customers, and end users (i.e., the Stakeholder Community) care about or makes them happy. This definition equates value with real business or mission value rather than the cost incurred in developing functionality. Agile teams help organizations achieve predefined and measurable outcomes by delivering valuable software capabilities.

Agile teams determine what to build through negotiation and collaboration. The Stakeholder Community is actively engaged with development teams in defining requirements and verifying and validating solution increments throughout development. This way of working affords plenty of opportunities to inspect and adapt emerging solutions as they grow and evolve. Frequent releases provide the most important validation of all: customer and end user acceptance of solutions and achievement of desired outcomes. What teams learn along the way informs future development.

Organizations with strong traditional project management cultures are not organized to participate in this form of value delivery and empiricism. They are organized to outsource the definition and development of software solutions to development teams after a period of requirements definition. They then wait until the solution is finished to validate its value.

Outsourcing Agile Adoption

When organizational leadership sees Agile as a process for developers to follow, instead of a culture change for the entire organization, they are more likely to “outsource” Agile adoption to Agile trainers, coaches, and consultants.

Many organizations spend large sums training developers on the mechanics of an Agile approach but fail to internalize the values and principles behind the approach. The result are development teams that perform the practices of the chosen Agile approach without understanding how those practices foster agility. Meanwhile, management continues to operate under Waterfall assumptions and expectations. Organizations end up with crops of newly Agile-certified employees but no plans to apply what they learned towards achieving greater agility.

Many developers feel they do not get enough value from Agile trainers and coaches. Some trainers and coaches lack enough understanding of the day-to-day work of software developers or the organizational environment to be effective. Others are Ill-equipped to help organizations move beyond executing team-level Agile practices and establish Agile-based organizational cultures.

Another manifestation of organizational leadership outsourcing Agile adoption is hiring consultants to develop “Agile strategies.” Rather than leveraging consultants to help them develop Agile strategy, organizational leadership pays consultants to develop their Agile strategy with little organizational input or understanding of the organizational culture. When this happens, the resulting strategies tend to be long on theory and short on actionable objectives for the organization to pursue.

“Hybrid Agile” (Scrumfall, Agilefall)

Many organizations struggling to transform from traditional project management to Agile decide to go for a “Hybrid Agile” approach. “Hybrid Agile” is not a recognized Agile software development approach. It is an attempt to gain the benefits of Agile while avoiding internalizing and applying Agile values and principles. Rather than reevaluating existing processes to achieve greater agility, these organizations contort Agile approaches to fit within existing organizational culture. This leads to a tailoring of Agile misinformed by traditional project management biases.

Development teams working in “Hybrid Agile” projects experience the worst of both Waterfall and Agile. Teams are expected to:

“Plan” their work while being denied control over the amount of work they commit to
“Self-organize” while having no say over team structure, tools, and processes
Provide “estimates” that are treated as deadlines
Document what they work in “Agile” productivity tools to keep management informed
Develop what they are told to according to an “approved” design while expected to accommodate customer and end-user change requests

Proposed Solution

Developing valuable software solutions and products takes more than writing code. Regardless of the software development approach followed, all projects are accountable to their target Stakeholder Communities and must provide business or mission value, cost effectively, and in time to be valuable. Management and development teams have to support each other to be successful.

Bottom-up Agile adoption typically fails to foster organizational agility beyond development teams. Top-down Agile adoption tends to lack in-depth understanding of the realities of software development and buy-in from development teams. A “meet-in-the-middle” approach accounts for the strengths and weaknesses of the other two approaches. The meet-in-the-middle approach entails:

Prepare Everyone to Work Agilely

While Agile is inherently bottom-up, organizational transformations required to achieve agility are not. Organizational leadership and management must play an active role in leading the transformation. However, to do so in ways that do not crush agility, they must adopt a “Servant Leadership” model. This starts with a recognition that the primary role of management is to empower those who deliver value to the customer and to create work environments and customer relationships in which value providers can succeed and flourish.

A big piece of leading the change involves training, coaching, and mentoring employees, at all levels and roles, to understand Agile values and principles and how to apply them to their work. This may require different types of training/mentoring or individual study for different roles throughout the organization. For example, coaching and mentoring for organizational leadership and management could be geared towards:

Understanding the differences between traditional project management and Agile
Learning and internalizing the tenets of Agile Servant Leadership
Aligning organizations to Agile value delivery in ways that align with Agile values and principles

I stress the need for coaching and mentoring. Setting people loose after a two-day Agile certification class and telling them to “be Agile” guarantees failure. Most people outside of software development have not worked in Agile environments. Thus, they do not understand how an organization rooted in Agile values and principles would impact how they work. Organizational agility is not about everyone organizing themselves as a Scrum team. Like any new skill, Agile thinking and practice must be honed to gain the most benefit.

Hire Knowledgeable and Experienced Trainers & Coaches

This point is obvious but warrants explanation: hire knowledgeable and experienced trainers and coaches. They need experience in more than just teaching classes and holding Agile certifications. The more experience trainers and coaches possess in developing software solutions or leading their development, the better.

I temper this with the caveat that the best trainers and coaches possess subject matter expertise and instruction, facilitation, and communication skills specific to their role. The most technical people are often not the best fit for teaching and coaching Agile. What are needed are generalists who possess a mix of theoretical knowledge, relevant industry or mission experience, exposure to the work of software development, and strong interpersonal and communication skills.

Hire, Educate, Train, & Mentor Developers for Leadership Roles

Employers in technical fields tend to select out “soft skills” while overemphasizing technical skills. They do this at their peril. Agile depends on the development of self-organizing “high-performance” teams.

Agile teams develop leaders. Hiring well-rounded people, who work well in teams, and developing their technical and leadership skills ensures development teams have the skills they need to self-organize and to build productive relationships with their Stakeholder Communities.

Conclusion

Reconciling Agile’s inherent bottom-up perspective to organizational change with the need for transformative leadership from above is difficult. There are no one-size-fits-all approaches for doing so. Successful implementation of any Agile approach requires deep understanding of Agile, the chosen Agile approach, the organizational environment, the Stakeholder Community, and the day-to-day realities of development teams. It requires discernment and a willingness to make tough decisions.

Software developers are on the front lines of Agile transformations because they create solutions that enable business or mission success. They have a huge stake in the direction Agile adoptions take because they are directly affected by the outcome. Thus, they need and deserve a significant voice in their implementation.

In the next and final article of this series, I’ll discuss difficulties software developers face managing Agile and DevOps-driven changes to their role.

Let us know what you think!!!

Will an Agile Certification help me get a Job?

It could, but choose wisely

Table of Contents

Getting a certification can be a time consuming and expensive proposition. Most people do not commit to paying for and following a certification program unless they feel reasonably certain they will benefit from doing so. For many people, getting a job, advancing their career, or making more money are the primary motivations for becoming certified.

However, rarely does getting a certification, on its own, lead directly to getting a job or promotion. Most people understand this, at least intuitively. However, Agile-related internet forums are filled with posts asking: Will an Agile certification help me get a job?

This article describes how to decide which Agile certification program is most likely to bring you professional success. While my focus here is on Agile certifications, this same decision-making approach applies to any kind of certification you may be considering.

Deciding on a Certification

When deciding which Agile certification to pursue, evaluate your options based on how each certification aligns to your professional goals, industry and job considerations, and life circumstances.

Your Professional Goals

We can group professional goals into three categories: Professional development, marketability, and changing careers. Professional development is about keeping up relevant skills, or learning new ones, to improve your current job performance or get promoted. Your marketability depends on how attractive a job candidate you are, across a profession or industry, based on your skills, knowledge, and experience. Changing careers may require gaining education, skills, and certifications.

Industry and Position Considerations

The Agile approach(es) you choose to become certified in must align with the needs of your target profession or industry and with individual position requirements. For example, a software product development company may need certified Scrum Masters to help development teams become more effective by applying Scrum. In that case, a Scrum Master certification would be valid differentiator. Another company might be a systems integration company that develops large-scale systems that include both software and hardware components. In that case, a certification in an Agile scaling approach such as the Scaled Agile Framework (SAFe) would be appropriate.

Let’s delve further into industry and position considerations in choosing Agile certifications.

Click to Expand — Table 1: Industry and Position Considerations Relevant to Choosing an Agile Certification

Industry Considerations

Taking into account the following industry-related considerations will help you choose which certifications are most aligned with your professional goals.

1. Does the industry recognize the certification and certifying body?

A quick look through job postings and descriptions for your target industry should quickly bring to light that industry’s required or most desired certifications. Some certifications require more time and money to get than others. Many Agile certifying organizations or bodies require attending expensive classes and taking expensive tests to become certified. Other bodies, like Scrum.org, offer classes but allow people to take their certification exams without class attendance. Ensure that the certification is recognized and accepted within the industry before spending time and money acquiring it.

Be on the lookout for references to specific certifying bodies. For example, ScrumAlliance and Scrum.org are two well-known and widely-accepted Scrum certifying bodies for Scrum.

Also look at industry forums and ask people in the industry about which Agile certifying bodies they recognize and why. Getting an Agile certification through a recognized body increases its value.

2. Is the certification in demand?

Just because a certification is recognized within an industry does not mean it is necessary to gain entry into that industry. Your prior experience is often more valuable than a certification.

However, a certification may be a minimum requirement to gain employment in a particular industry. You need to determine your relative value compared to other job candidates. If most candidates possess certifications and you don’t, you’ll be at a disadvantage.

3. Will the certification set you apart from other candidates?

On the flip side, having a certification may actually set you apart from other job candidates in your industry. This is truer for more specialized Agile certifications like the different SAFe role certifications.

Understand, however, that a certification is not a substitute for real experience. It is a credential that attests to your knowledge about, and understanding of, a particular Agile approach.

Position Considerations

After narrowing down the choices based on your professional goals and target industry, consider which certification options most closely align with the positions you seek.

1. Is the position an Agile role?

Are you interested in positions where you’ll play a formal role within an Agile approach or framework such as Scrum or SAFe? For example, are you going for a Scrum Master or Product Owner position for a Scrum Team? Do you want to be a Release Train Engineer (RTE) for a SAFe Agile Release Train (ART)? If so, then becoming certified for such roles will likely benefit you both in terms of meeting position requirements and preparing you for the roles.

2. Does the certification lower the number of years of experience required?

Some organizations lower the number of years of experience required for a position if the candidate possesses a specific certification.

3. Is your position changing because of Agile?

Perhaps your current position or industry is moving towards Agile and you need to understand how to best deal with the change. For example, you are a traditional project manager who is now working Agile projects.

Learn about the organization’s chosen Agile approach and understand its roles. Then ask yourself, “Which of these roles most aligns with the work I do today?” Determine whether it makes sense for you to transition to that role or learn how best to support that role from your current position. Either way, a certification in that Agile role will arm you with the knowledge necessary to participate and contribute in an Agile environment.

Gaining Multiple Certifications

Obviously, if you intend to become an Agile coach, mastery of multiple Agile approaches (e.g., Scrum, Kanban, XP, SAFe, LESS) is expected. However, even if becoming an Agile coach is not your goal, you may find it beneficial to possess more than one Agile certification. Many Agilists do. You may want to start with becoming certified in the different roles of your organization’s chosen Agile approach and later expand into other Agile approaches and Lean process management practices. How you expand your Agile knowledge is entirely up to you.

Your Professional Experience and Life Circumstances

The next set of factors to consider when deciding whether to pursue an Agile certification are your professional experience and life circumstances.

Professional Experience

If you do not have a background in developing, testing, and supporting software systems, or managing those who do, you will have a steeper learning curve. Agile philosophy is applicable to team-centered product or solution development in practically any industry or domain. However, Agile approaches, such as Scrum, were originally conceived as better ways of developing software. As such, translating Agile practices to work outside the realm of software development requires knowledge, skills, and experience.

Everyone’s familiarity and background in Agile is different. If you are new to Agile, introductory courses and beginner-level certifications make sense. If you are an experienced Agilist, then progressing through intermediate and advanced certification levels may be right for you. Make sure that you meet course and certification prerequisites.

One course or certification does not make anyone proficient in Agile. Attaining a certification is really the beginning of an ongoing journey of learning, application, and improvement. The journey involves hands-on application, Agile community participation, and individual study augmented by structured training opportunities.

Life Circumstances

Do you have the time and money necessary to get certified and stay certified? As stated earlier, many Agile certification programs require attending certification courses that they sponsor. Many certifying bodies also require periodic (often annual) re-certification payments as wells as documentation of ongoing professional development activities related to the certification. Understand all of the time and money requirements associated with any Agile certification you pursue.

Conclusion

Committing to attaining an Agile certification is a big step. You want to be certain that your chosen certification program aligns with your professional goals, your target industry/positions, and your life circumstances. Rather than thinking about Agile certification in terms of landing a particular job, think of it as an opportunity for professional and personal growth that will open up opportunities.

Let us know what you think!!!

Three Reasons Business Analysts Need Product Owner Skills

Product ownership skills are key to increasing your marketability and versatility

Note: This article follows the capitalization of Scrum terms followed in Scrum.org’s Scrum Guide.

Table of Contents

In a world that prizes specialization, business analysts (BAs) are expanding the profession. As organizational complexity grows and the pace of change quickens, businesses, non-profits, and government organizations are transforming themselves to better meet those challenges. The quest for business agility is compelling organizations to abandon traditional project management approaches to information systems development in favor of Agile. To remain effective and marketable, BAs are adding Agile practices and techniques to their skillsets.

For many BAs, their understanding of Agile is limited to the mechanics of a particular Agile approach, such as Scrum. Often, their first formal introduction to Agile is some form of Scrum Master training.

Scrum Master training is taught primarily from the perspective of supporting the work done by software development teams through application of Agile principles and Scrum practices. Scrum Master training alone does not do enough to address the knowledge and skills most important to BAs supporting Agile projects: how to bridge the work of Agile teams with sponsor, stakeholder, customer, and end-user needs. Those skills are at the core of Scrum product ownership.

Beyond the fact that Agile has become the preferred way of structuring software development projects across a growing number of organizations, this article discusses three reasons why Scrum product ownership is an essential skillset for any BA.

Reason #1: Business Analysis Aligns with Product Ownership

Of the three roles identified by the Scrum framework (Scrum Master, Product Owner, and the Development Team) the Product Owner (PO) is responsible for ensuring that the work performed by the Development Team delivers valuable business or mission capability, cost effectively, and in time to be valuable. As such, the PO and BA roles share many responsibilities.

The International Institute of Business Analysts (IIBA) considers the PO job title to be one of many that fall under the BA umbrella:

Business Analyst Job Titles — Business Analyst overlaps with many job titles, including Product Owner

A comparison of job responsibilities for both roles further highlights how closely related they are:

Business Analyst vs. Product Owner Roles — Business Analyst vs. Product Owner Responsibilities

Reason #2: Scrum’s Product Management Orientation

A major difference between Scrum and traditional IT project management is Scrum’s product management/development orientation. Scrum’s terminology is indicative of this product management bias with terms like Product Owner and Product Backlog. From the perspective of Scrum, software solutions are products. While the focus of traditional project management is on managing people, schedules, and activities, Agile in general and Scrum in particular focus on managing the product.

A good way to illustrate the differences between product management vs. project management mindsets is to compare the core functions performed by product managers and project managers. While their work often overlaps, their primary responsibilities compare as follows:

A product management approach to developing software solutions changes how we define software solutions. For example, in traditional software projects, functional requirements are decomposed and written in ways that decouple planned functionality from expected business or mission outcomes. They are written from the perspective of the system (e.g., “The system shall…”). In Scrum, requirements, typically written as user stories, are written from the perspective of the user and clearly link desired outcomes with planned capabilities:

As <a user or role> I want <some capability> so that <desired outcome>

This user-centric approach to requirements supports Agile’s iterative and incremental definition, development, and delivery of software solutions. Customer centricity is a key component of Scrum’s product management approach. That approach aligns well with the goal of business analysis: enabling organizational change by defining business needs and recommending solutions that deliver value to stakeholders.

Reason #3: No Formal Role for Traditional BAs on Scrum Teams

As I stated earlier, Scrum identifies three roles: Scrum Master, Product Owner, and the Development Team. While all three roles collaborate to form a cohesive “Scrum Team”, they each have specific responsibilities. The responsibilities that most closely align with those of a BA belong to the PO.

However, there is one very big difference between the PO role and that of a BA. The PO is ultimately responsible for the success or failure of the product. As such, the PO is empowered to make decisions about the direction of the product vision. In other words, the PO decides what the product will ultimately be, how it will function from a business or mission perspective, and what business or mission capabilities it will include.

To be clear, the PO does not make decisions about how to develop the product. That is the responsibility of the Development Team.

The PO does not make product decisions in a vacuum or by behaving like a traditional project manager. Instead, the PO works alongside the Development Team in defining the “product” based on input from an actively engaged stakeholder community (i.e., sponsors, stakeholders, customers, and end-users).

For their part, Development Team members collectively manage their own work, determine technical approaches, develop their own estimates, report their progress, and help define the functionality they build. This contrasts with traditional project management practice, in which management is responsible for defining what to build, breaking down and assigning work, developing plans and schedules, and reporting progress. Scrum Development Teams are self-organized.

This means that Scrum Team developers develop their own requirements, primarily through collaboration with the PO, but also as they collaborate directly with technical and business/mission-facing members of the product’s stakeholder community. The old saw about developers not caring about business requirements and being fixated on implementing technology does not apply to Scrum teams. Developers are expected to be user-centric too and to think in terms of improving the product, not just delivering software components.

So, if there is no formal role for BAs in Scrum, how should they participate and contribute? There are three BA participation options: 1) As a Scrum Team member; 2) As a proxy to the PO; 3) As the PO.

Business Analyst as Scrum Team Member

The first option would include the BA as a member of the Scrum Team. The BA would then work with the team to refine the Product Backlog. The issue here is that the entire Scrum Team participates in backlog refinement. Therefore, the BA would need to contribute through additional duties such as facilitating stakeholder requirements elicitation, creating technical documentation, or explaining business requirements to testers. Some BAs may consider this a less than desirable fit since their attention would be diverted, to some degree, towards activities outside their traditional role.

Business Analyst as Proxy to the Product Owner

This is the least desirable of the three options and should be avoided. In this option, the BA is a “go between” for the Scrum Development Team and the PO. Since the BA is not empowered to make decisions about the product, he/she must gain approval from the PO. This turns the BA into a time bottleneck and deprives the Development Team and the PO of the close interaction required to make the Scrum Team work as intended. Eventually the Development Team may learn to discount the input the BA provides since it may be overruled by the PO at any time.

Business Analyst as the Product Owner

This is the best option of the three. As I discussed earlier, the PO role carries more responsibility and a larger scope than the typical BA role, however, it also shares many responsibilities. While not every BA will necessarily be willing or able to make the transition, it is definitely a workable option.

Conclusion

BAs typically work in or consult for mid-to-large-sized organizations, where the size and complexity of software solutions warrants employment of BAs. While a growing number of these organizations are shifting or have shifted towards Agile, many have not or are slow to shift. As a result, many BAs possess experience and skillsets aligned with a traditional project management rather than with Scrum’s product management approach to IT solutions development.

As a BA, acquiring Scrum product ownership skills can only help your career by making you more marketable and versatile. Regardless of the type of projects you contribute to, the analytical and leadership skills you will gain will help you become a more effective BA.

Let us know what you think!!!

What’s wrong with “Agile Training”?

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

Table of Contents

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.

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 Figure 3 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:

Know the Agile Manifesto, the 12 Principles, and
the rules of the chosen Agile framework/approach well enough to recall them in
detail (Remember)
Understand the foundational material well enough
to explain it and recognize its proper implementation (Understand)
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.

Let us know what you think!!!