Are there Benefits for adding ChatGPT as a team member?

There is evidence that ChatGPT can be beneficial in helping you do your work. Involving ChatGPT today is already occurring in repetitious, creative, and diagnostic type work. Some say it’s inevitable and you should learn to work with many forms of AI. Current uses have shown that it can improve work efficiency, assist with tedious tasks, help you with creative tasks, and facilitate learning. We are also learning that because ChatGPT is based on a large language model, it can act as your assistant; providing personalized responses based on your inputs, helping you work smarter, and boosting your productivity.

As it can help an individual in their work, how about helping a team?  In this article, I explore how helpful ChatGPT can be for a team. In other words, I suggest making ChatGPT a member of your team. ChatGPT is an artificial intelligence chatbot capable of mimicking human-like conversations so why not be a member of your team? As mentioned, ChatGPT has been recognized to boost productivity so let’s consider the context of a software engineering team who are producing new features and correcting bug fixes to the code base.  To consider this, here are the potential positives, negatives, and limitations of incorporating ChatGPT as an engineering team member. Here are some considerations:

First, let’s start with some Positives:

• Multi-tasking: ChatGPT can handle many questions, inquiries, and tasks simultaneously allowing certain work to be handled more efficiently and scaled to a higher volume of work.  
• Quick feedback: ChatGPT provides quick feedback to questions and inquisitions allowing for more input for potential better options and decision-making.
• Availability: ChatGPT is technically available 24/7 and can work while team members rest allowing for busy work to get completed and tasks to be ready for team review when they are back online.
• Scalability: As an AI, ChatGPT can handle a high volume of inquiries without experiencing fatigue or requiring breaks.
• Database of information: ChatGPT has access to a vast amount of information and can provide accurate and up-to-date answers to team members' queries.
• Human Languages: ChatGPT can speak in multiple languages and can accommodate global teams across multiple boundaries and locations.  
• Programming Language: ChaptGPT has the potential for programming capability across various language platforms.  

Next, let’s move to the Negatives:

• Time from Team Members: Working ChatGPT will take time from some team members. A buddy for ChatGPT will need to be designated to help provide context for ChatGPT, line up tasks, reduce ambiguity of the requests, verify and validate the work done by ChatGPT, and more.
• Lack of emotional intelligence: ChatGPT lacks emotional understanding and empathy, which may limit its ability to provide refined and empathetic output to team members.
• Limited contextual understanding: ChatGPT will struggle to understand the context in which you are working including the complexity of the work, potentially leading to misunderstandings or incorrect responses.
• Bias and completeness fn training data: the database from which ChatGPT pulls has already shown some bias based on patterns and data provided which means it may generate reasonable responses but may be incorrect or biased if not carefully reviewed.
• Lack of creativity: Because ChatGPT pulls from existing data and patterns, this limits its ability to generate genuinely innovative or creative ideas.

Finally, several considerations should be factored in. The first is ethical considerations as ChatGPT may inadvertently generate or reinforce biased or discriminatory responses due to its training data (which includes such biases). Careful monitoring and bias mitigation strategies will be necessary. The second consideration is legal and compliance challenges.  Incorporating ChapGPT into a product team may raise legal and compliance concerns, particularly in regulated industries that require human input, oversight, and/or accountability.

It's essential to consider these factors and strike a balance when integrating ChatGPT or any AI model into a product team. Human supervision, ethical guidelines, and continuous evaluation can help mitigate the limitations and ensure optimal utilization of AI technologies like ChatGPT. Now it is time for you to wrestle with this question: Are there Benefits of adding ChatGPT as a team member? Hopefully the overview, positives, negatives, and considerations can help you with your answer. 

----------

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 
• Are there Dangers with ChatGPT for Agile? 
• How to Experiment with ChatGPT 

The Meta of getting to Small in an Agile World

If you are Agile in the Product delivery and software development space, there is strong emphasis on thinking small.  This means decomposing work to small pieces to allow for iterative and incremental delivery and eventually the continuous flow of work. While this sounds straight-forward, in practice, it is hard because it disregards the challenging mindset shift that must occur to get people to think small. 

It is important for Agile teams, coaches, and leaders need to understand for those who have never decomposed their work to “small” size chunks, they have little idea what that means and it may take time. This article focuses on several reasons why “decomposing the work to small pieces” is challenging and the meta surrounding the concept of small.

Small is mindset shift  

Imagine that you have never considered what is small and someone says, “think small!”  This is meaningless without any context or experience in “getting to small”.  To achieve the concept of understanding small bite-sized pieces or work, there is mindset change that must occur.  Imagine if you were piloting a plane for the first time and your instructor says, you must go “fast” to take off.  What does fast enough mean if you’ve not done this before? If you only ride a bicycle, then fast may mean 25 mph (or 40 kph). However, in order to take-off, fast means 75 mph (or 120 kph) for a propeller plane and 170 mph (or 275 kph) for a jet.  There must be a strategic steps to shift the mindset to think differently that includes allowing the team time to learn and experience their way to small. 

Small is Relative 

What is “small” will be different depending on the type of work a team is doing. There is back-end, middleware, front-end work and more. Each team must gauge what is small based on their work. Also, what is small will differ from team to team and is relative to team size, talent, and experience. What is small must be specific to each team. Management must not compare sizes across teams as this will deteriorate the relative sizing for the specific teams.

  
Small is Complex 

Creative work like building new products and services (or features therein) are considered complex (per the Cynefin framework) as there are unknowns and “unknown unknowns”, ergo requiring a "probe–sense–respond" approach.  Many will translate small to days of work. But translating small to time of work disregards the complexity and unknowns of the work. In an Agile world, we consider not just effort, we look at complexity of the work (e.g., what is known and unknown), and any risks involved in the work (e.g., what skills, experience, tools, infrastructure a team has and more specifically what they don’t have.  What this means is that to identify small work, you must look at effort, complexity, and risk so it isn’t straight-forward.

Small is Imprecise 

In an Agile world, we don't pretend to think that we can have precision in our sizes. We want good sizes but we have to move away from the traditional mindset where we think we can provide accurate estimates. If it isn't correct, this is actually okay as we’ll soon learn more about the work.  When you size the work within an iteration (aka, sprint) and the iteration is done, you will quickly build a historical database of sizing and will learn more about the work.  The very next iteration, you will have learned whether you were over or under for a size and when similar type work comes along you have input for the future sizing of work.  In other words, “don’t sweat the sizing”. 

Summary

When transforming to Agile, there is a shift to to small pieces of work allowing for iterative and incremental delivery of the work. Small is challenging for teams that have not had to work decompose to small. Understanding the meta around getting to small can help coaches, teams, and leaders navigate the challenges knowing that it is a mindset shift, it is imprecise, it is relative to the work and each team, and is complex.