We have 5422 guests and 12 members online
Home > Articles > Columns > Articles > Agile Personality Types

Agile Personality Types

E-mail
Written by Mario Moreira   
Wednesday, 09 March 2011 12:17

Stepping StoneWhen viewing the Agile world, it is beneficial to recognize the different types of folks within each organization or product team. Each type has different motivations and knowledge, and it is important to assess this and either take advantage of the type or mitigate the risks of the type in leading to a successful adoption of Agile.  What I believe I may have recognized are seven personality types (or personas) of people who are in the Agile space: the Innovator, Champion, Workhorse, Bandwagon, Cowboy, Deceiver, and Denier.

Knowing these personality types can be very helpful if you are an Agile professional looking to deploy Agile into an organization or product team.  It is important to distinguish between them so you understand the people you are dealing with.  This is another way to approach stakeholder mapping so you know the personality types you are dealing with and their attitude toward Agile.  Below is a matrix that places the seven Agile personality types into quadrants with positioning being determined by their level of Agile experience and their attitude (e.g., positive or negative) toward Agile.  It is not meant to be a specific instrument but an approximate gauge to help you in your quest in adopting Agile.

 

Figure 1: Agile Personality Type Matrix

What follows are the seven Agile personality types discussed in more detail, highlighting their experience levels in Agile, their positive or negative attitude toward Agile, the common roles that fit into a type, their common attributes, and their goals and motivations.  While some folks fit squarely into one personality type, others may have attributes of two (or more) personality type.

Innovator
Agile Innovators make up a small population of folks in the Agile arena who are very experienced in this field and very positive about Agile.  These folks are typically designated as the Agile industry leaders and are motivated to improve and extend Agile methods, practices, and techniques. 

The signatories of the Agile Manifesto would certainly fall in this camp.  Another group is those who have Agile experience and write on various Agile topics to extend knowledge in the field.   These are writers, presenters, and authors who write on general Agile topics like Scrum and Extreme Programming (XP), and those that write on extended Agile topics like, Agile and QA, Agile and Configuration Management (CM), Agile Coaching, Agile and the Product Owner, newer Agile practices like Agile Release Planning, and Agile methods like Kanban.  They are the folks who have conceptualized Agile into pragmatic methods and practices and have been evolving Agile over time.

There are advantages of having Agile Innovators in an organization.  They can provide Agile leadership in an organization’s Agile adoption efforts.  Many Agile Innovators have extensive Agile Coaching experience and have the ability to adapt Agile practices and methods to fit the context within an organization. They are motivated to educate others on Agile and understand how to get cultures (e.g., a cultural change agent) to accept Agile. Companies have very embedded cultures that are typically slow to change and grasp new ideas so an Agile leader must have the ability to make culture change occur in an adoptable manner.  Many Agile Innovators are consultants who move from company to company helping them adopt Agile.  Those companies lucky enough to have hired an Agile Innovator as a full-time employee will have the benefit of having this expert to guide the organization through all aspects of an Agile adoption effort.

Champion
Agile Champions tend to know Agile well and are willing to advocate it in a very positive way across an organization.  Some common roles in this space are Agile coaches, consultants, product managers, heads of engineering, development, and QA, and project managers. They make up a small, yet core, leadership in the Agile community and communicate the real meaning of what Agile is and what it means to have it applied.   Most Agile Champions have actively practiced with Agile and have innovated and extended the capabilities of Agile into all areas of software development and adapted Agile into their work environments.   Some common roles in this space are very experienced engineers who can construct methods and practices based on their working experience that extend the capabilities of Agile for their own organization.  There are some champions that may not be well versed in the practices of Agile, but have seen the benefits of implementing and using Agile methods.

Folks in this role, play an important part of getting Agile adopted within an organization’s culture.  They can help make it very clear in what conditions Agile will work.  They can help communicate where there are challenges and help share new ideas in the Agile space.  Agile Champions help generate Agile buy-in with Senior Management, many of which are part of bandwagon crowd (to be discussed momentarily), to initiate a new Agile culture (in pockets or throughout the company).  This requires analysis of the company culture, an ability to understand ‘change’ patterns, and the ability to negotiate and facilitate change.  This also includes the continuous interaction with management to ensure they are engaged with the Agile direction.

Agile Champions are constantly ready to support product teams in utilizing Agile and to help remove obstacles, bottlenecks, and those Agile personality types (e.g., specifically cowboys and deceivers) that may get in the way of effectively deploying and utilizing Agile.  Agile Champions also are involved with providing educational opportunities such as training, community websites, webinars, and seminars.

Work Horse
The Work Horse has learned about Agile by trying to implement it on their own or as part of an Agile team with some help from others.  The work horse is mostly positive about Agile but will be fairly honest on what works and what does not.  The common role in this space is the members of an Agile team that have implemented Agile methods and practices.  They bring a pragmatic approach to Agile, understanding the structure that Agile needs to thrive, by either being bitten once already or by understanding the environment needed for Agile.

The work horse has worked in the trenches and really understands the challenges of implementing Agile because of their experience and they know that project success is tied to implementing Agile in an effective and pragmatic way. This group cannot afford to be idealists, but are realists that learn the hard way when a new Agile culture collides with current company culture. They learn the importance of facilitating change and adapting.  A lot can be learned from this group.  Their frequently asked questions and the resulting answers from Agile Champions, Innovators, or from the Work Horses themselves are a boon to the further development of Agile and ability to fit Agile effectively into the organization’s or product team’s culture.

Bandwagon
The Bandwagon crowd sees benefits in jumping on the Agile bandwagon. Fads and trends rule the day in many organizations so if Agile is perceived to be "hot", then there will be folks who will jump on that bandwagon.   Those in the bandwagon crowd tends to be inexperienced with Agile but are generally positive especially when they think it can help their own image or further their career.   Some bandwagon folks are engineers who think they should align with the latest enterprise trend so they are perceived as team-players so appear positive since it places them in the right crowd.  Some bandwagon folks are middle and senior management who are good at reading the winds of change within an organization and who believe they can get ahead by aligning with the hot new trend even though they may not have much interest in actually learning about that trend (in this case, Agile).  They are very willing to "throw around" Agile terminology to give the appearance of knowing more about the field than they actually do.

The danger with the bandwagon crowd is three-fold.  First, they may act like they know Agile well while, but because they do not, they will inadvertently communicate inaccurate information on Agile without any bad intend (but it is incorrect information all the same and can cause problems).  Second, they may not really understand the cultural change within management that is needed in order for Agile to thrive.  Agile truly requires a mindset change so without their intent to learn Agile and act in an Agile manner, reduces the chance of successfully deploying Agile within an organization or product team.  And third, the danger with the management on the bandwagon is they can just as easily abandon Agile if they perceive a dislike from their up-line management and will readily blame Agile if something goes awry.  In other words, they may not be reliable supporters of Agile. On the other hand, some bandwagon folks will see the value of Agile and will become Agile Work Horses or Champions. 

Cowboy
The Cowboy sees Agile as an opportunity to abandon processes and documentation so that they can enjoy the wild west life.  Cowboys are the type of folks who are not necessarily negative about  Agile because, in many cases, they know that they get away with pretending to be Agile since many folks, particularly the bandwagon crowd who are their up-line management, really have no idea what Agile is.  It is the cowboy that has propagated the myth that Agile is an undisciplined approach for wild-west coders.  Ultimately, these pretenders can give Agile a black eye in the organization since others will believe from the cowboy’s actions that Agile means no process. Agile methods instill much more rigor and discipline than most cowboys can tolerate and much more than many folks realize.

When reviewing the Agile Manifesto (see http://agilemanifesto.org/), the smarter cowboys purposefully interpret the word “over” as “in place of”. These individuals are smart enough to know that many do not understand Agile. They deliberately twist the true intent of the manifesto. For example a cowboy will reinterpret the Agile Manifesto value of “Working software over comprehensive documentation” into “Working software instead of documentation”, ergo where the myth of ‘Agile not requiring documentation’ comes from.  Agile does, in fact, value process, tools, documents, and planning.  However, these are viewed differently in the Agile context in that they should not be automatically done for the sake of the process, tools, documents, or planning, but as a need that arises from the individuals and interactions and the ability to establish effective working products.

A person with real Agile experience, whether it is the innovator, the champion, or the workhorse will immediately see that the cowboy is not an advocate of Agile because while the cowboy does not advocate process, tools, document, or plans, they do not advocate any of the discipline that Agile applies, nor any of the Agile practices.  You will find cowboys out there who know a bit about Agile, and just enough to know how to circumvent it.

Deceiver
The deceiver will provide surface agreement to using Agile but will silently attempt to ignore or even sabotage the project in order to put the blame on Agile.  A deceiver is certainly negative about Agile but is usually so because they have thrived using traditional method or no defined method at all and see this as an impact to their working culture.  Some deceivers may have been forced into a role on a team using Agile but do not want to lose any credibility by openly bad-mouthing the new direction.  A deceiver will usually have some Agile experience because it may be thrust upon them and they will have just enough information to be dangerous.

Clues of their behavior will be that when things go wrong on the project, they are quick to blame Agile.  Keep in mind, that when you move to Agile, it can threaten some folks who have been used to playing a singular role (and doing it well) in a traditional method for years.  Some deceivers may have enjoyed their singular role within traditional methods and find the team approach within Agile not to their liking and will begin to subtly rebel in a passive-aggressive manner.   Some will believe it will impact their career advancements or their compensation.  There are some similarities between cowboys and deceivers in that both attempt to prevent the adoption of Agile.  However, deceivers are the most dangerous because they may undermine and obstruct the potential success that Agile may bring to an organization and will attempt to hide any evidence of doing so, while a cowboy will try their best to simply avoid Agile.  Also, it may not be so obvious in identifying some of the deceivers until it is too late (e.g., they’ve already done their damage).

Denier
The Denier will outright deny any benefit to Agile or their interest in moving to it.  They are typically set against Agile from the beginning because they see that it will interfere with what they perceived to be their currently successful role within the company.  Some deniers have thrived on playing a very specific role on a project and have been rewarded accordingly.  They may believe that it will impact their compensation in a negative way.   Deniers typically do not have much Agile experience.   It is actually better to have deniers than deceivers because with Agile deniers you know where they stand.

Many times, it can be beneficial to listen to reasons why deniers dismiss Agile.   The input from the deniers can help you understand their specific reasons for objecting to Agile (e.g., rewards, roles, loss of control, etc.).  The input may help you look for a way to overcome the reasons, therefore strengthening the overall perception of Agile within the organization.  In some cases, by providing the deniers Agile knowledge, may lead them to be more positive impression about Agile, and in-turn some may become Agile work horses or champions.   Also, by knowing who the Agile deniers are, they can be moved to other projects that are not going to Agile and where they may can continue to provide value to the company.

Summary
If you are adopting Agile either at the product team or organization level, it is beneficial to understand the Agile personality types of the players.  A good exercise when you are embarking upon an Agile effort is to identify those that fit into the different types (e.g., Innovator, Champion, Workhorse, Bandwagon, Cowboys, Deceiver, and Deniers)?  Do they understand the value of Agile? How much knowledge and/or experience do they have with Agile?  How positive or negative are they with Agile?  While employing Agile implies a cultural shift, the Agile community must continue to communicate the strengths and weaknesses. Knowing the people you are working with and their Agile personality types can help you utilize their strengths and overcome the challenges ahead to a more successful Agile journey.

Reference

About the Author Mario Moreira is a writer for the Agile Journal, a Columnist for the CM Journal, an Author, an Agile and Configuration Management (CM) expert for CA Technologies and the industry, and has worked in the CM field since 1986 and in the Agile field since 1998.  He is a Certified ScrumMaster and has implemented Scrum and Extreme Programming (XP) practices.  He has an MA in Mass Communication with an emphasis on communication technologies.  Mario also brings years of Project Management, Architecture, Software Quality Assurance, Requirement Engineering, Release Management, IT Governance, functional management, facilitation, and team building skills and experience.

Trackback(0)

Comments (0)Add Comment


Write comment

security code
Write the displayed characters


busy
Last Updated on Thursday, 17 March 2011 09:46
 
Cialis

Agile Marketplace - Announcements and Special Offers

The Business Case for ALM Transformation
Are legacy systems holding your company back?  Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper