A Discussion with ChatGPT about Agile

I had a good discussion with ChatGPT about two weeks ago. I started by asking “What is Agile?” The response was that “Agile is a methodology” with a bit more details. While technically incorrect, given the amount of information and vectors it pulled from, it wasn't completely wrong. What I mean by this is that many people, including some “Agile experts”, refer to Agile as a methodology which is incorrect. Depending on where ChatGPT is pulling this information from, this isn’t a surprise.   

• My response: “Agile is a set of values and principles. Some Agile information is not aligned with Agile values and principles and instead rely heavily on Agile processes and methodologies or people's misinterpretation on what is agile”.  
• ChaptGPT's response: You are correct. Agile is indeed a set of values and principles outlined in the Agile Manifesto, and it emphasizes flexibility, collaboration, iterative development, and customer satisfaction. However, misinterpretation or a focus solely on Agile processes and methodologies can lead to a deviation from these values and principles.

I was happy to see that it was aware of the Agile Values and Principles as this is how Agile is defined by the Agile Manifesto which is the seminal information defining Agile. And as I mentioned in my previous article, The Dangers of ChatGPT to Agile, there is a lack of quality evaluators on the numerous Agile articles and presentations in cyberspace that indicate if the information provided is right or wrong, good or bad.

Two weeks later (today), I asked ChatGPT the same question, “What is Agile.” This time it included the Agile Values and Principles as part of its long-winded response that included:

"Agile is an iterative and incremental approach to project management and product development that emphasizes flexibility, collaboration, and continuous improvement. It was created as a response to traditional, plan-driven project management methodologies that often struggled to adapt to changing requirements and deliver value in a timely manner.

Here are some key aspects of Agile:

1. Values and Principles: Agile is guided by the Agile Manifesto, which outlines four core values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. These values prioritize human-centric approaches and adaptability.
2. Iterative Development, 3. Cross-functional Teams, 4. Continuous Improvement, 5. Customer Collaboration, 6. Flexibility and Adaptability" (Note: I removed the details of 2 thru 6 from ChatGPT as this wasn’t relevant to this article).  

While ChatGPT will continue to develop and response to my queries, I am happy to see that it is using my (and others’) input to fine-tune its language model and improve its responses.

-------------

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

• Are there Dangers with ChatGPT for Agile? 
• How to Experiment with ChatGPT 
• Are there Benefits for adding ChatGPT as a Team Member?

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? 

Right-sizing Documentation in an Agile World

Within an Agile context, there is a focus on right-sizing documentation.  This is a response to the bureaucracy that has led to large volumes of project and product documents which are often left unread, are out-of-date the moment they are complete, and seem to have little value to the team.   On the other hand, I have heard folks who are in an Agile context say that no documentation is needed.  The truth is somewhere in between.    

One of the values in Agile is “working software over comprehensive documentation”.  This does not mean that there is no value to the item on the right, but there is more value to the item on the left.  The key is right-sizing the documentation.  Right-sizing means that the level of effort applied to write and maintain the documentation plus the value of that written document should have a greater return on investment (ROI) then not having that information readily available (i.e., the effort it would take reconstruct the information and impact of not having that information for current decisions).   With that in mind, here is some high-level guidance on right-sizing documentation. 

• Documentation should be living and evolutionary and not “sitting on the shelf”.   Move away from the notion that document is “final”.
• Consider some documentation to live at the product level where it may naturally evolve from both sprint to sprint and from release to release. 
• Documentation should take on a collaborative nature.  It should not be written by one person to perfection, and then shared with others.  It should instead be shared often during draft to gain input   
• Update your documentation continuously as new things are learned.  If you learn something that can impact the team or help with decision-making, go to the document and update it. 
• Focus on just barely good enough documentation and avoid big upfront details which typically means a lot of guessing and wasted time.   Barely good enough means document what you currently know.  If you no longer need the document, it is reasonable to retire it. 
• Be concise and lean.  Write in succinct prose and add bullet points if reasonable.  Avoid long and flowing prose which may lose the reader’s attention.
• Documentation can take many forms.  It is not only a Word document, documentation can live on a wiki, in the Agile planning tool, as comments in code, and much more
• Document decisions.  Knowing the decisions helps those who must maintain the product and understand why things were decided or done in a certain way.   
• Realize that there is a difference between internal and external documentation.  External documents may be a User Guide or document that gets delivered to the customer.  These should be considered as “working software” and follow the rules of the done criteria.    

What might get documented in an Agile world?  The major documentation comes in the forms of user stories and epics.  This includes writing the user story in canonical form, with details, and acceptance criteria.  Technically, another significant form of documentation is the code itself. It should be written in team agreed coding standards with appropriate comments that specify what the code does (or simply and clearly enough that don't need explanation) and why it was written a certain why.  Remember that code needs to be maintained so if someone has to "figure out" what you wrote and why in order to support the code, then it is problematic.

You should consider lean versions of your architecture, coding, and test strategies that help inform the team of ways of working. Impediments that require effort to fix should be documented.  Items such as coding standards, an overview of your working processes and policies, done criteria such also be documented and shared. 

What do you think of this guidance?  Do they make sense?  Do you have any other tips?

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.