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 

Agile Executive Playbook

Imagine that you are an executive of a company (and quite possibly some of you reading this are or have a direct line to an executive).  You’ve heard about this thing called Agile and some of you have experienced it.  However, Agile is still a bit confusing because in many cases, it appears to be occurring only at the development team level and can occur in many different ways.  Some of you believe that Agile is a set of practices and tools and may be surprised to know that it is nothing-more-and-nothing-less than a set of values and principles.   Maybe some of you haven’t seen the connection between applying Agile and gaining the business benefits.  What exactly is your role and responsibilities in moving your company toward Agile?  Here is guidance on what you may do to support Agile and more importantly increase your chances of deriving the business benefits of Agile. 

Strategic Shifts           

The key responsibility for the executive within the organizational scope is to become the sponsor of the Agile initiative.  This highlights to the employees that Agile is important and increases the chances of buy-in.  But simply proclaiming “make it so” isn’t sufficient.  The executive must continue to be a key player in this on-going sponsor role.  Here are strategic shifts that are beneficial:

• Study the Agile values and principles.  Knowing this language helps you become more conversant in Agile and to the teams and organizational players that are involved.  Studying the values and principles will also help you ascertain if you really believe in them (or not). 
• Move away from the iron triangle of schedule, cost or scope and move to a framework focused on value.  Prioritizing ideas via cost of delay will provide a much better value-driven pipeline of ideas.  These ideas can be decomposed into increments that can then be validated with fast feedback loops. 
• Measure and adapt the flow of your end-to-end concept to cash pipeline.  There is a tendency to focus on just development, but it is often other parts of the pipeline where ideas wait much too long.  Consider value stream mapping to better understand waiting states and no or low value steps. 
• Adapt the organization from a hierarchical organization to more of a self-organizing organization.  When employees feel that they have more ownership and decision-making of their work, they will apply much more brainpower and bring passion to their work.

Key Sponsor Activities

Now let’s take a look at the more in-depth activities that you as an executive should consider playing and why.  These are more tactical, but since becoming Agile doesn’t happen overnight, they help keep the engagement and interest along the way. 

• Treat your Agile initiative as a journey.  Because this does take time, it would benefit you to build an adaptable roadmap.  This may be best handled with a small local team of Agile champions who are committed to adopting Agile and an Agile consultant who has experience in this area.  To get a good understanding of what an Agile roadmap may look like, consider reading the book Being Agile: Your Roadmap to Successful Adoption of Agile.
• Build a learning culture.  Consider establishing an education vision on how to best educate your organization. Infuse the education with experiments and experience. I suggest starting with the Value, Flow, and Quality materials that provide the reader with great insight into many of these new concepts and ideas, along with case studies and activities.
• Build the foundation for a Customer Value-Driven Enterprise.  This is a company that is explicitly looking for the highest value ideas, applying an incremental mindset, and applying feedback loops to validate value along the way.  Learn more by reading The Agile Enterprise.
• As an executive, examine your own behavior and align it with the Agile mindset of Agile values and principles with a focus of delivering customer value.  Are you speaking the language of Agile and the strategic shift that you are looking to achieve? 
• Provide funding for the Agile initiative.  Funding should include meeting education needs, bringing in talent (coaches) as needed, and providing tool support. This may occur incrementally or per the budget cycle.  
• Periodically provide public support for Agile. Establish an Agile communication plan, of which portions can be executed over time to keep employees aware of the progress and accomplishments of the deployment.  This may also include providing 'air cover' to the Agile deployment team and the coaches and champions and mitigating the risks that could prevent a move to Agile.  
• Consider your staff.  Ask yourself, “are they Agile minded and aligned with the cultural shift that is needed?”  You may need to be involved with making adjustments to staff members who cannot make the switch away from command-and-control. This can be hard to do, but if they don't, then those around them will not take the change seriously.
• Learn how to read agile metrics and measures of success. Gaining an understanding of the lagging to leading metric path, sprint burn-downs, release burn-ups, value capture, release frequency, Agile Mindset, Values, and Principles (MVP) Advisor, and other Agile-related metrics can help ensure the organization is moving in the right direction.
• Adapt the employee compensation model toward agile behaviors being sought and away from rewarding command-and-control attributes. To change behavior, recognize the behavior you want to change, evaluate the reward system, and adapt it to the behavior that is needed for Agile. Without aligning the reward system to Agile, you will not get to behavior you want.
• Attend the Sprint Reviews of your top products within your organizational scope. This will give you a genuine sense of progress and see actual working functionality of your products.

The intent of this article is to provide highlights of what an executive can do to get the most business benefits from their Agile initiative.  There can be other perspectives and further details.  As an executive (or those who have supported executives), what have you found helpful in your Agile journey?

User Story Writing Starter Kit

Prior to Agile coming into existence, I was fortunate to learn how to write requirements by Elemer Magaziner (i.e., business requirements) and Alistair Cockburn (i.e., use cases).   They provided various alternatives to writing clear requirements that were irrespective of methodology.

 

From this I learned that there is a strong benefit to establish what I term as the “requirements language construct”.  This construct helps you consistently document your requirements focusing on key requirements elements. One common requirements language construct in the Agile world is the canonical form. It is important to realize that elements of the canonical form have been around for years.   With that being said, the three basic elements of the canonical form provide a good framework for establishing requirements. 

First I will discuss the user story that is typically expressed within the three-part canonical form.   Then I will introduce the enhancement of a requirements language construct that can adapt the canonical form.  The language construct for a user story in canonical form looks like this:

The persona is the user type who will receive the value.  The action is what the user type desires.  The business value is the benefit to that user type.  Note: you can learn more about personas in the article Personas – Do you really know your Users?   The following are examples of user stories in canonical form:

• As a learner (persona), I want to set up my profile to include my photo (action), so that my distributed team members know what I look like (business value).
• As a prospective buyer (persona), I want to search on homes (action) so that I know what properties are available in my price range (business value).

As enhancements to this construct, you may consider adding the system that will be used or interacted with and the receiving entity which identified the expected output from the requirements.  If applying these, the requirements language construct would look something like this:

As a (persona)

I want (action) from (system) to the (receiving entity) 

so that (business value)

The following are examples of user stories with these enhancements.  The first example below takes the second example from above and enhances it with the system and receiving entity.

• As a prospective buyer (persona), I want to search on homes (action) from MLS (system) to a separate window (receiving entity) so that I know what properties are available in my price range (business value).
• As a quant analyst (persona), I want a derivatives report (action) from the asset management application (system) in the form of a pdf (receiving entity), so that I can distribute it to my fund managers (business value).

There is no “right” requirements language construct.  It is important to craft one and then experiment with it.  I would suggest starting with the canonical form and work from there. 

Finally, the Product Owner, Business Analyst, Product Manager, and anyone who writes requirements should be trained in writing user stories in whatever form is used to articulate requirements. The Agile Team should be educated in understanding what to look for in a user story and asking questions regarding the elements of the canonical form. You may also want to train stakeholders and customers on how to provide their needs in your requirements language construct for consistency and clarity. 

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 18 of Being Agile. 

The Importance of Language in a move to an Agile Culture (with Polling Results)

In my experience in helping teams transform toward an Agile culture, moving away from the traditional terminology and adapting Agile terminology is very beneficial.  At the same time, I have sensed reluctance in organizations in removing from their traditional language.  I believe the language you use matters a great deal if you are attempting to achieve a certain culture.  A prime example is moving from the language of certainty in a more big-upfront Waterfall culture to discovery and hypothesis driven language in an incremental Agile culture.

If you are trying to change culture, the change in language highlights that something has changed and provides folks with a learning opportunity assuming that there is true meaning behind the language and a commitment to change. It makes everyone pay more attention. If you think about it, when you travel from one culture to another, the language does indeed change.  Using the proper language helps you inform and communicate needs more effectively while a common language provides a bond within our community.

Maybe the key is to use language that is most efficient and effective for the culture you want to get to. If you want to change your culture, you need to ensure that the language is not tripping you up and dragging along its baggage of prior meaning.  When you move from a big-upfront Waterfall to an incremental Agile culture, using the same waterfall language will trip you up.

Why? Because people in the organization still think the definition of the term is stemming from the 'old' culture. Attempting to change culture is hard enough and when you have language from the old culture still around, you can be sure that those people within the org are still interpreting the language using the old world context. This can impact your success to advance your new culture. 

With all of that being said, this is the opinion of one person.  So what of the opinions’ of others?  With that in mind, I embarked on a poll via LinkedIn to gauge other’s thoughts on how important is it to use Agile terminology to get to an Agile culture.  I present you with the following results:

Within a period of a month, there were 83 votes cast along with 26 comments.  The poll results revealed that 65% percent (or close to two-thirds) of the participants felt the use of Agile terminology was either ‘Very Important’ or ‘Important’ for an Agile culture.  Another 12% felt it were neutral.  The remaining 23% felt that the use of Agile terminology was of ‘Little Importance’ or ‘Not important at all’.

In order to more fully understand other opinions, I have included a paraphrasing of some of the comments.  They include: there is a need for specialized vocabulary; there are fundamental differences amongst various practices and methods so terminology should be considered; the terminology contributes to language precision; and the words used should work for the culture.  You can see one of the threads within the “Agile” Linkedin group for specific comments from others.

Some took my examples literally.  I didn’t really mean to imply that the term ‘sprint’ and ‘phase’ are the same, but I have seen teams use those terms interchangeably.  So I do agree that one term is not necessarily better than another but that you should ensure the language you use does not get in the way of learning and advancing within your culture.   Also, I’m not clear that there needs to be a standard “Agile” terminology across the industry.  However, with that said, if you are applying Scrum, you should use Scrum terminology (and the same for XP, Kanban, etc). There is a value of having a common Agile terminology within an organization so that there can be a more effective platform for Agile related discussion across teams.  

Also a few people mentioned that the meaning is more important than terminology.  I do favor this line of thinking because there should be an effective meaning behind all terminology used.  Terminology without meaning is babble.  So yes, it is important, dare I say critical to have a well understood and clear meaning behind all the terminology used in order to gain an effective Agile culture. 

Ultimately if you are truly trying to initiate a culture change, then the language should reflect the change you are looking to make.   In this case, if want to establish an Agile culture, utilize the terminology that provides an appropriate and clear meaning which drags little or no baggage.  This will help you get to the Agile culture you may be seeking.  Cheers!

Note: another article that discusses Agile terminology focusing on the terms 'size' vs 'estimate' may be found at: http://cmforagile.blogspot.com/2012/10/size-matters-using-size-instead-of.html