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 

Visualizing your Team with the Team Constellation

Your team is real. It is made up of real people that support each other toward common goals. We often get so engrossed in our work that we forget the important connections and relationships across and beyond a team. What really is a team?  Emergn defines a team as having a shared purpose, compelling direction, complementary skills, shared responsibilities, and common performance goals. It is important to imprint the team in a visual way.  Equally important for a team to visual themselves is for those that support the team to be visually connected.  

One way to envision a team is through the visual Team Constellation.  The team constellation is a visual way to share who is on the team and who may contribute to the team.  The question is how to create the constellation? If you have a team room or area, you can construct one on a white board or on large poster paper, although in either case, I recommend using post-its to represent the people. I’ve had some teams print out small photos of their faces. For distributed teams, you can create a digital online constellation via a number of graphic or illustrative tools and place them on team sites or printed out so they can be shared.

I typically recommend a Team Constellation with three tiers as there are three levels of responsibility that typically are needed to embrace the team’s needs.  The first tier includes the core team who are committed to work directly on the product or service and meet the definition of team (in the first paragraph). They provide leadership for each increment, self-organize around the work, build the deliverables, and attend team ceremonies.

The second tier are the extended team that contribute to the team but are not fully committed. They may provide subject matter expertise in a specialized area or a missing temporary skill needed by the team to build the next increment. For work done in an increment, they should participate in any planning, stand-up, or demo related ceremonies.

The third tier are the stakeholders that support and advocate for the team.  Those in this tier, have an interest in seeing the team’s work become successful.  This will include providing sponsorship in terms of people and resources.  They help with communicating progress more broadly and may attend team demos to observe what is being build and may provide feedback. They may also help the team remove roadblocks beyond the team level.

Consider taking time to visualize your team via a team constellation. Take a moment to adapt the definitions of each tier. I suggest making it publicly available so that others understand those that work on and support the team. It can also help you solidify what it really means to be a team.  

Unlock the Power of Self-Forming Teams

A collaboration by Chris LeBlanc and Mario Moreira

It is quite possible that many teams in your organization are going through the motions of Scrum.  Per the Tuckman model, they are in the Norming phase of team group development, but are hard-pressed to break into the Performing phase.  This may be due to the team feeling a lack of empowerment and what it means to be Agile beyond the mechanics.  We are going to share a technique that can help bring your Agile organization to the next level, increase employee engagement and help make your engineers high performing and happier. This technique is relevant when you have a squad of 14 or more people who need to form into 2 or more teams.  

The common scenario in team formation is where a manager (or those who do not do the work) decides the team structure.  Managers have external knowledge of who may work well together and what skills they possess.  This is an educated guess at best.  Might we consider another approach?

By embracing the concepts of self-organizing teams and bounded authority, we ask those who actually do the work, the team members, to use their team internal knowledge of who they work best with and how their skills are able to complement the members of their team.  The result can be happy, high performing cross-functional teams composed of engineers that that want to work with each other.  For those experienced with the process of self-organizing teams, might it best start with the ability to self-form? 

May we introduce the Self-forming Teams starter kit!  This is a technique used to help engineers self-organize toward an engaged and effective team based on their current skill sets.  There are few steps that need to be completed by the leaders before you begin:

Create a vision of the work ahead.  This will give the engineers the information they need to understand who is best to work with based on their current skill set.

Set up bounded authority for the exercise.  The leaders can provide their bounded authority guidance on a few inputs to the exercise: mix of senior and junior team members and buy-in to this process.Everyone follows the bounded authority of the Scrum process as input: team size (7+/-), cross-functional skills (Dev+ QA)

An Agile Coach or facilitator to help guide the team toward their self-forming goals

Once the bounded authority and the vision are established, the Agile Coach or facilitator is ready to begin.  Here are steps to follow. Again, this is relevant when you have 14 or more people who need to form into multiple teams. 

• Kickoff the session with sharing the self-forming goals with everyone. They include: Well-balanced teams who can successfully and efficiently complete any item in the backlog;  Long-term teams and can autonomously deliver value as fast as possible; Teams that understand skills needed on each squad and a learning path for the short term; Team members like the team they are on and the work they are doing
• Conduct a connection Ice Breaker to lighten the mood of the session
• Describe the definition of self-organization
• Introduce the Product Owner and Architect to discuss the vision and any backlog input
• Conduct a divergent conversation with everyone.  Ask “What skills will be needed to tackle the presented work from the backlog?”  Write down each skill given by the engineers.
• Follow this with a convergent conversation that draws affinities between the skills to generate a list of Macros Skills each team would need (5-7 is a good number)
• Ask each engineer to walk to the board and mark off each skill they currently have and each skill they want.
• Now start the self-formation process.  Ask the engineers to self-form into teams, using bounded authority and the Macro Skills that were generated as guidance.  As the facilitator, move the conversation along when they become stuck.
• Finally, nobody leaves the room unless everyone is happy with the team they are on.  Ask for a Thumbs Up / Thumbs Down vote from the group.  If there are any thumbs down, explore the reason and adjust the teams accordingly.

What we have seen to be true of self-forming teams is that knowledge workers who choose their own team structure are more invested in owning the health of the team.  When something is not working on the team, they are more likely to improve it. They are excited and happy to be on that team.  Healthy, happy people create high performing teams that build high quality products quicker.  Unlock the potential (and untapped power) of your teams and extend your ability to self-organize with self-forming teams.

To read more of Mario Moreira's articles, visit: http://cmforagile.blogspot.com/

To read more about Chris LeBlanc, visit: https://www.linkedin.com/in/chris-leblanc-47619a5 

What happens in the Retrospective stays in the Retrospective!

The Sprint Retrospective is the last event in Scrum occurring at the end of the sprint.  It is a private and safe session for Scrum team members only and facilitated by the Scrum Master. It is used to identify what went well, what did not go so well, and what can be improved.*  It is important to discuss what went well so that you can celebrate successes and when the team feels certain things are going well. 

A sprint retrospective promotes continuous team improvement.  The areas that did not go so well are rated by the team as to which were the most problematic.   The team takes the top 2 or 3 of these problematic areas and identifies the root cause.  Root cause analysis ensures that the real challenge is uncovered so the team crafts a solution that will resolve the problem.  An improvement action is established for each problematic area. Then the team commits to a couple of these improvement actions to be worked on in the next sprint. 

The retrospective is an opportunity for the Scrum Team to reflect on the past sprint’s activities including team dynamics, processes, tools, and culture.  It supports the Agile principle of self-organizing teams.  In order to really get to the nitty-gritty of the problem areas, sometimes “dirty laundry” needs to be discussed. This includes taking a hard look at the problems.  

In order for the team to feel comfortable in airing problems, the team needs to feel that they can trust each other.  Team members must believe they can discuss problems knowing that anything said will stay in the room.  If what is discussed in the retrospective gets communicated outside of the room, folks on the team will be less likely to raise and discuss problems.  And discussing and resolving problems is what the retrospective is all about.  This is why it is important to discourage outsiders, particularly any managers of the team members from attending these sessions.  When outsiders attend, you often see far fewer real problems get raised.  Outsiders may not understand the context of why a team made a decision or did something a certain way which can lead to inappropriate judgments.

The retrospective only has value when the team discusses problems in a sincere manner, has a safe environment to discuss problems, and provides a strong commitment to resolving the problems to the benefit of the whole team.  So keep all of this in mind when you hold a Sprint Retrospective and remember, what happens in a retrospective stays in a retrospective!

* An alternative approach is to discuss what we should stop doing, continue doing, and start doing.  

Do you bring the “Semper Fi” mindset to your Agile Teamwork?

When I think of a strong example of an Agile team, I recall teams that would help each other out, would watch each other’s back, and would focus on the project at hand, working strongly in a collaborative manner to achieve the common goal. 

Interestingly enough, this is what it takes to achieve the ideal Marine mindset.  Semper Fidelis is Latin for “always faithful” and has been the Marine motto since 1883.  This motto guides the Marine to remain focused on the mission at hand and stay focused on each other as part of the unit, as part of the team.  The intent is that once you commit and become a Marine, you transform to something new, something better, where you don’t worry about yourself.  Instead, you worry about the guy next to you and to the success of the mission.  You live a life with personal integrity, courage, determination, and commitment.  These are the same attributes that make a member of an Agile team successful. 

   

Another mindset within the Marine leadership is “to lead by example”.  In Agile, we don’t need people telling us what to do.  We need people who lead by example and who live the Agile mindset.  This is the best way for the team to absorb what is expected by the Agile values and principles and is another way to grow.  

If you want to learn about the importance of teamwork, spend a moment learning about the mindset of a Marine.  As I would illuminate the attendees of my numerous Agile workshops, one strong attribute of teamwork is “no one succeeds unless everyone succeeds.”  Agile team member should bring encouragement to each other, integrity to do what is right, courage to challenge the bad habits, and commitment to see the work through.  This is teamwork and beyond.