Are there Dangers with ChatGPT for Agile?

How will ChatGPT impact Agile? This article discusses ChatGPT and its implications to Agile in the industry today. ChatGPT is taking the internet by storm and hard to ignore. Because of this, it cannot be ignored by those in the Agile field. What are the implications of ChatGPT on Agile? Here is a brief summary of what is ChatGPT and a review of what is Agile and its current journey.

What is ChatGPT?

ChatGPT is an artificial intelligence (AI) chatbot-type tool developed by OpenAI. It is adept at producing human text-based output on the input it is given. This model incorporates a large body of text data and can create responses to questions, write articles, and more. The challenges with ChatGPT are that it is only as good as the “large body of text data”, can be used maliciously and with bias, can spread misinformation, and is ethically complex in its application and future application. This applies to any field that people may use it for including Agile.   

What is Agile?

Once upon a time (in 2001) Agile was unveiled based on the Manifesto of Agile Software Development which is comprised of Agile Values and Principles. The objective of articulating the values and principles is to apply them in the form of an Agile transformation to derive better business results. However, the manifesto does not provide guidance on how to apply Agile. 

Soon, a number of processes and methods (e.g., XP, Scrum, Kanban, SAFe, etc.) were established to construct and apply agile ways of working. Agile has also spawn a number of certification programs in an attempt to educate people in Agile ways of working, in some cases aligned with a process or method. During this same time, Agile coaches were educated to help their own companies and Agile consultancies to help other companies apply Agile ways of working. The Agile movement has grown and expanded in a number of fields beyond software development.  After over 20 years, what are the results? The challenges are three-fold.  

• First, the current state of Agile is underwhelming. The most recent State of Agile Report (16th Annual – 2023), tells us the following. Only 18 percent of organizations implemented Agile for all the teams. Around 50 percent of respondents report that less than half of their teams are using agile, and 84 percent acknowledge that their organizations are below a high level of competencies. There is clearly plenty of opportunity for growth.
• Second, some of the Agile savvy (e.g., coaches, consultants, leaders, managers) seemed to lack an understanding of what is agile. In an Agile study where 109 agile professionals answered a survey on Scrum events and Agile principles, 59% could name 3 or more of the five Scrum events, while only 11% knew 3 or more of the twelve Agile principles. This is quite astounding. And they didn’t need the full statement of the principle but got credit for even the key words of the principle. The concluding hypothesis is that the reason there is such a lack of awareness of Agile principles is that there is much less focused on the mindset and culture and maybe too much focus on the mechanics.
• Third, the implementation of an Agile transformation is complex per the definition provided by the Cynefin framework. Agile transformations are neither linear nor predictive. It depends on the readiness of the culture and willingness of its leaders in their ability to move forward. Complexity means that it is not clear on what the best next step is until you act, ergo you need to probe, sense, response your way forward. This is why experimentation helps reveal what is possible each step of the way. You must both meet the company and teams where they are and help them determine what is the next step to further the transformation.  

What this tells us is that there are great opportunities for improvement and that there is no easy way to apply Agile, no one-size fits all, and no clear roadmap. Why? Because every organization is different due to their current culture, size, fields, practices, and more. 

Implication of ChatGPT and Agile

Now that we have an overview of both topics, the question is what are the implications of ChatGPT to Agile (and vica-versa)?  I’ll start by saying “What you put in is what you get out”. ChatGPT is only as good as the “large body of text data” available to pull from. The good news is that today there are reams of text data on Agile. The bad news is that there is no rating system on the quality of most of the Agile related information. With the advent of blog’s, there is a large body of unverified knowledge that enters into the “large body” of available data. What are the implications of this? 

• Arguable Quality of response - The quality of ChatGPT generated articles and answers should be read with a grain of salt. This isn’t a “knock” on ChatGPT, and instead it is due to the quality of the body of text data that ChatGPT draws from. And the reality is there is no one right way of applying Agile.  
• Propensity for Misinformation - There is a danger of misinformation and abuse of those who use ChatGPT to bias their responses. Some may be accidental as the body of text being pulled in isn’t broadly approved or agreed upon. While I don’t expect that most will be intentionally abusive, do keep in mind, there is money to be made in selling agile so bias may be seen.  
• Not doing your own Research - While you may want to occasionally use ChatGPT, it is better to learn from the body of Agile knowledge out there (e.g., books, articles, presentations, seminars, etc.) according to the areas that will benefit your current needs in your Agile transformation or need. In other words, do your own research so you can critically judge the quality of information that gets generated.
• Taking Agile Jobs - Can ChatGPT take jobs away from Agile Coaches and Consultants? This is unlikely as a significant part of an Agile transformation include coaches and consultants who have been on a transformation journey that can help companies navigate the complexity of both the current needs and the anticipation of near-term needs. ChatGPT cannot “read the room” like an Agile Coach. Should a company think that ChatGPT will be “enough”, it highlights that they don’t understand the complexities of a transformation and what it takes to change culture.

Summation

Now that you have some background, let us again turn to the question, “how will ChatGPT impact Agile?” There will be those that use ChatGPT to provide answers for Agile theory and questions. If you want to write an Agile article, it will help provide input and insight, although you have to be aware that the value of the information is only as good as what it pulls from. Think of ChatGPT as another resource to help you think through your ideas on agile topics and how it may help you in your Agile transformation. However, just remember, it is just a tool like other tools.     

It is unlikely that ChatGPT will take over Agile roles and the art of the transformation. A big part of Agile transformation is discovering, observing, and experimenting on what will work and what will make progress. Remember, when defining Agile, it really implies a transformation. This is a combination of doing agile and more importantly being agile. This means transforming mindset and culture. It is currently unlikely that ChatGPT will have this capability as transformations are complex with the real need to experiment (e.g., probe, sense, response) toward progress.  Coaches and consultants are still important to help transform organizations and more importantly to help leaders and teams make the mindset-shift to truly becoming Agile. 

-------

If you are interested in learning more about ChatGPT in relation Agile, Teamwork, or experimentation, consider reading these additional articles:

• A Discussion with ChatGPT about Agile 
• How to Experiment with ChatGPT 
• Are there Benefits for adding ChatGPT as a team member? 

Agile Problem Finder

I occasionally hear that Agile is the silver bullet and will solve all engineering problems. In some cases, someone in management heard about Agile and figured it could be a quick fix to solve the challenges within their organization. Unfortunately this is far from the truth. While Agile mindset and methods can help you adapt to customer needs and deliver more effective customer value, one key benefit that I find is that Agile shines a bright spotlight on existing problems within an organization or team.

This is where Agile methods such as Scrum, eXtreme Programming (XP), Kanban, Test Driven Development (TDD), and others can be very effective problem-finding tools. While this is not what most people think about when adopting Agile, it is a side benefit. It is important to understand that Agile methods won’t necessarily help you solve the problems that are being uncovered but they really need to be removed to achieve the value delivery and speed you are looking for. 

More often these challenges have been around for quite some time, well before Agile was introduced. In fact, management and team members have known about these issues, risks, and dependencies, but they conveniently get buried under the organizational carpet. In the Agile world, every impediment can impact the value and velocity of Agile.  Once Agile comes along, the spotlight focuses brightly on anything that gets in the way of efficient and effective delivery of customer value. What are some of areas where Agile shines the halogens onto existing problems? In my experience, I have encountered numerous challenges during the deployment Agile. Here are some examples:

• When moving to a 2 week cadence of delivery, the team bumped into organizational processes like approvals and alignment of priorities that slowed the team's ability to delivery on a faster cadence. We talked with these approval groups, shared what is agile and asked if they could work with us on a more regular basis (e.g., bring approval groups in earlier and add a Scrum of Scrums to gain alignment with dependent groups).  
• In setting up Scrum teams, it became clear that there is a lack of QA resources on the project (7 developers to 1 QA engineer). We assessed that our development to QA ratio really needs to be 5 to 3, then replaced some developers with QA engineers. Until we could hire the level of QA engineers needed, we had a few of the developers play the QA role.
• We learned that teams often don't stay together long enough to perform effectively.  Project-based company didn't allow bonding time. When the project ended, the employees are reconstituted to other project teams. We worked to have a long lived team allowing them to go through the stages of forming, storming, norming, and then performing and then stay together. 
• The team lacked trust and psychological safety. There is often a culture where trust is damaged by management actions as teams are not trusted enough to make decisions. Teams don't feel safe enough to bring up vulnerable points to more easily get over team hurdles. We implemented bounded authority so teams own their own decision-making.  
• In running incremental QA processes, it becomes clear that there is a lack of automation and, in fact, very few unit tests were ever written. We then spent some time building unit tests to provide at least 80% test coverage (we built this into our Definition of Done), then began automating the tests.
• In running continuous integration, there was a lack of understanding the branching and merging process. Developers were unaware of the importance of refreshing the private workspace with latest successfully built and approved code and also continued to retain local objects and executables in their private workspaces. An effective Checkout/Checkin process (with refresh and build and promote) was established and workspace education was conducted by the Configuration Management (CM) engineers for the team.
• In working with a legacy team, it became clear upon sizing and building functionality on existing code, that we were continually breaking other parts of the code since there was tremendous technical debt within the code base. It was learned that there was no coding standards since the beginning. We initiated a refactoring strategy with coding standards to help us reduce some of the more problematic code modules.
• In working with Product Owners (aka, Product Managers), it became clear that requirements were poorly written which led to a lot of churn between the Product Owner and the developers/QA engineers. The existing requirements list had requirements at multiple levels and it was hard to discern who the requirement was meant for. I educated the Product Owners and Scrum team members on how to write requirements in a canonical form (persona + action + business value) and the POs rewrote the requirements over time in a priority order.

For some teams that move to Agile, they can get overwhelmed by the problems that are identified by the Agile spotlight. In some cases, prior to deploying Agile, it is worth identifying the existing challenges so folks realize they are not caused by Agile. One way to do this is to understand your full end-to-end "idea to release" process. The key is to add the challenges to your issues list, prioritize them, then address them in priority order. Remember, the Agile spotlight can help you identify some of your problematic areas on the product or in the organization. Take advantage of this but be prepared to address the challenges.  What existing problematic areas have you identified when you were implementing Agile?