Showing posts with label QA. Show all posts
Showing posts with label QA. Show all posts

Thursday, February 14, 2013

You may be FrAgile if...

Moving to the Agile can be challenging.  It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto. However,  many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues). 

What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.    

When "Fragile" happens...
Some may ask, “why do I care if Agile is not quite right”.  When a form of Fragile is applied, you will not gain the business benefits of aligning better with customer value and the many other benefits Agile can bring. When you see that you are not gaining the business benefits of Agile, instead of blaming Agile, look to see how you have implemented Agile and whether you are really aligning with its values and principles. 

In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article.  I present several areas which can be problematic if they are not in place and you are serious about Agile.  So without further ado, "You may be FrAgile if": 
  • ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail.  The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.  
  • ...you continue to have the Project Manager or Functional Manager assign the work to the Team.  The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.  
  • ...you continue to collect your requirements upfront and lock them in for the remainder of the project.  The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it. 
  • ...you do not want to have a healthy balance of test/QA minded folks on the team.  The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.  
  • ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.  
Let me know what you think about the results of "You may be FrAgile if".  If you believe there are other Fragile, Scrumbut, Scrumfall, Kantban, and other related Agile challenges that could be non-starters or significantly impact the ability to "be Agile", please feel free to share.     

Sunday, April 17, 2011

Knowing your Agile Personalities

When viewing the Agile world, it is beneficial to recognize the different types of folks on your team and in your organization. This can help you understand their perspective on Agile, if they are positive or negative on the topic, and what level of experience they have. Knowing these personality types can be very helpful if you are a professional looking to deploy Agile into an organization or product team. It is important to distinguish between personality types so you understand the people you are dealing with.

What I believe I may have recognized are seven personality types 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.  Here are details, highlighting the various Agile personality types including their experience levels in Agile, their positive or negative attitude toward Agile, the common roles that fit into a type, and their common attributes. 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. Agile Innovator is typically designated as an Agile industry leader and is motivated to improve and extend Agile methods, practices, and techniques. 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. 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. 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.

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. They are mostly positive about Agile but will be fairly honest on what works and what does not. The common role in this space are 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. A lot can be learned from this group.

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.

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. 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 negative about Agile but is usually so because they have thrived using traditional or no method 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. 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. 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.

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. 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. The input from the deniers can help you understand their specific reasons for objecting to Agile (e.g., rewards, roles, loss of control, etc.). 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.


Consider reading more on this topic in full article: Agile Personality Types