How to Experiment with ChatGPT

As ChatGPT continues to make waves, is it time to learn more about it? One way to approach this is begin experimenting with ChatGPT within your context.  Learn where ChatGPT can help and where it can benefit you. In other words, what do you want to get out of ChatGPT? This allows you to test your hypothesis and the surrounding assumptions to provide knowledge and insight into whether (in this case) ChatGPT can help you or not. Here is an example.

Start with the question: Can ChatGPT help my team improve? Validate this question. Conduct preliminary research to gauge if this is relevant for your team. Start by finding out if team members are interested in using ChatGPT. This can also help you identify assumptions and if there are any other variables in play that can impact the direction of the experiment. It can also help you narrow down an area that you think ChatGPT can help.  After discussion with the team, team members believe that ChatGPT can help in retrospectives

Craft a hypothesis in a clear sentence on what you expect to find: Include ChatGPT in the retrospective can lead to better root cause analysis.  Some team members had an assumption that ChatGPT could provide root cause analysis capabilities. A hypothesis can help you validate whether ChatGPT can provide better root cause information. You can also use the “if… then” form: if we use ChatGPT during our retrospective, it will provide better root-cause analysis results, leading to more effective actions for improvement.    

Craft the experiment. Now that you have a sturdy hypothesis, it is time to craft your experiment. Describe the steps through your experiment. To do this, consider how long the experiment will run and who will be involved.  In this case, you decide to include ChatGPT in the next three retrospectives in order to get a more meaningful set of results and to have time to determine if the actions are leading to more effective results. Determine who will use ChatGPT during the retrospective and how the questions and statements will be written. Also consider the metric you will use to validate your result and what success criteria you will use to determine if the hypothesis was true (or not).  At this point, it is time to run the experiment. 

Run the experiment. An experiment should be considered as recognized effort and categorized as real work to track in your backlog.  Enact the steps listed in your experiment. Capture observations along the way and results upon the conclusion of the experiment. Get together with those who are involved in the experiment and determine what you’ve learned. Ask the question, did what we learn validate the hypothesis (or not)?  Then determine what decisions you will make as a result of this experiment. In this case, should you to continue using ChatGPT for retrospectives (or not)? Determine if there are any next steps. 

In conclusion, if you are thinking about ChatGPT, the key is to experiment. ChatGPT is a tool like other tools that may benefit you. Brainstorm where ChatGPT can help you in your context. Use the experiment to see if it does. Consider multiple experiments so that you build working knowledge of ChatGPT in your environment and working context.

---------

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

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

What is Self-Management and is it good for Agile?

This is a four-part series on Self-Management.  This first article focuses on what is self-management.  The second article conveys the difference between self-organization and self-management.  The third article focuses on putting self-management into action.  The fourth article shares the ways to mitigate the challenges in moving towardself-management.  First up, what is self-management?

Self-Management is an alternative approach to management.  It moves away from the traditional structure of hierarchical management and moves the core management activities and work related activities to employees therefore effectively eliminates the manager role.  Typical management activities that move to employees include planning, organizing, staffing, directing and controlling (per Morningstar Self-Management Institute). 

A major change that must occur for self-management to be achieved is a shift in mindset.  People within the organizations that move to self-management must believe they both have ownership and accountability of the work and each other.  More importantly, relationships matter in self-management as there needs to be personal responsibility to each other. 

Self-management in context to organizations and corporations doesn’t mean people can do whatever they want.  Leadership defines the mission level 'what' and 'why' for the organization. Employees own the 'what' to work on and the 'how' to do the work, along with 'who' does the work.  It means that within the boundaries of the organizational mission or strategy, employees align the priorities, budgeting, planning, staffing and more around the work.   

Models similar to self-management include Holocracy, which is defined as a different way of operating an enterprise that moves power from a hierarchy management structure and distributes it across autonomous teams. Holocracy should have clear rules and definitions on what teams and individuals can do. 

It is recommended to start self-management with first understanding all of the types of activities that management would do so that they are understood and then adapted in a manner what allows for more of a distributed ownership of the activities. 

As self-management relates to Agile, it may be said that they are both mutually supportively of each other.  Agile works better when the bounded authority of many management decisions particularly regarding the work are pushed down to the team effectively reducing hierarchy.  Inversely in order to achieve self-management, it is supported by the Agile values and principles and the mindset it brings that is center around a strong focus on individuals and collaboration.

To read the second article in this series, go to: The Difference between Self-Management and Self-Organization. 

The third part of this series is titled: Putting Self-Management in Action!
The fourth part of this series is titled: Ways to Mitigate the Challenges of moving toward Self-Management.

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

To learn more about self-management, consider visiting the Morningstar Self-Management Institute website at: http://www.self-managementinstitute.org/about/what-is-self-management. 

Psychological Safety leads to High-Performing Agile Teams

There are two types of safety that factor into a healthy and productive enterprise environment and high-performing teams.  The first is physical safety. This is where employees have an environment where they are free from physical hazards and can focus on the work at hand. This type of safety should be part of the standard workplace promoted by company and government regulations.

The second is psychological safety that is core to enterprise effectiveness. According to Google research, high performing teams always display psychological safety.  This phenomenon has two aspects.  The first is where there is a shared belief that the team is safe to take interpersonal risks and be vulnerable in front of each other.  The second is how this type of safety along with increased accountability leads to increased employee productivity and ergo high-performing teams. 

Psychological safety helps establish Agile in that it promotes a safe space for employees to share their ideas, discuss options, take methodical risks, and become productive.  An Agile mindset promotes self-organizing teams around the work, taking ownership and accountability, and creating an environment for learning what is customer value through the discovery mindset, divergent thinking, and feedback loops. Agile with psychological safety can be a powerful pairing toward high-performing teams.   

However, accountability without psychological safety, leads to great anxiety.  This is why there is a need to move away from a negative mindset when results aren’t positive or new ideas are seen as different. If this occurs, employees are less willing to share ideas and take risks.  Instead consider ways to build psychological safety paired with team ownership and accountability of the work. This can lead to high performing teams. 

Everyone has a role to play in establishing a psychologically safe environment.  Agile Coaches and ScrumMasters can help you evolve to an enterprise where psychological safety and accountability are paired. Leadership has a strong role to play to provide awareness of the importance of a safe environment, provide education on this topic, and build positive patterns in the way they respond to results of risk taking by teams.  Team members must adopt an open, divergent, and positive mindset that is focused on accepting differences and coaching each other for better business outcomes.  Employees at all levels must be aware of the attitudes and mindset they bring.   

The Role of Middle Management in an Agile World

When discussing Agile roles, there is much written about the ScrumMaster, Product Owner, Development Team, and Customer.  But there is less written about what the Middle Manager should do in an Agile World.   Note, when I talk about Middle Manager, I am talking about the Line Manager, Functional Manager, Manager, and Director level manager. 

I recently discussed the middle management roles within an Agile context to several different middle managers.  They each had an interesting perspective on what it was like when their teams became Agile. Here are two excepts:  

• The Functional Manager who was also the team's Line Manager noted that they spent much less time on directing the team on what to work on since the work was now coming out of the Product Backlog.  I told him that yes this is big adjustment.  He needed to focus on ensuring that his team members had the right skills, team impediments were removed, the Agile principles were understood, and the team were given the education they needed to become a fully cross-functional team.
• In talking to a Director who now has 3 self-organizing teams, she was telling me that she was having a hard time knowing what to do since she felt she had to get more hands-on.  She needed to help educate the team members around their new roles, and then allowing the teams to self-organize around the work was the right thing to do.  I told her by backing off, she could better provide more strategy level guidance to connect the organization’s strategies to the team or product visions.  She commented that this was very different from the more traditional management role she had been used too.  

Ultimately, it is important to understand that middle management are critical to the success of an effective Agile deployment.  They are the lynchpin between the executive’s vision for Agile and the team's ability to apply Agile as Middle management's willingness to allow Agile can help make it flourish or fail on a team. If they are engaged and buy into Agile, then the change may succeed. Even when executives buy in, if middle management does not do likewise, they can block a team's ability to succeed with Agile.    

If middle management don’t understand their role in the new order or feel threatened by the change, they may become Deceivers or Deniers and block the success toward Agile. Because of this, it is critical that middle managers are educated on Agile at the same time their teams are.

Middle management must adapt their role and learn to gently back away from their functional leadership, act more as a servant leader who trusts their teams, helps them remove roadblocks, and supports the agile principles and practices. They may attend the Sprint Review to see progress of the working functionality and the Daily Stand-up to gain a sense of team progress.   Middle management must also learn how to establish the concept of bounded authority where teams can make their own decisions and commit to their own work. The balance is that managers keep limited responsibilities to provide a vision and support their staff, while allowing teams ownership of their work.  Finally, middle management must be willing to be transparent about what is going on in the organization and be willing to communicate this information to the team. 

Other Roles that may suit Middle Management

Often middle management have less to do in an Agile world. The good news is that they may consider options such as changing their role to Resource Manager, where they manage more people but do not own an organizational functional area. They may consider a Product Owner role if they have been engaged in collecting requirements and interacting with customers. Although this role should no longer be managerial (i.e., not direct reports), a PO helps shape the product by collecting and grooming the requirements and collaborating with the team.   They may also move to another Functional Manager role where there is still a need for this role.  And some will remain their current middle management leadership roles.  If they continue to want to do the more traditional middle management roles, they may consider looking for companies that continue to look for the more traditional roles.  

How Middle Management can evaluate themselves in an Agile World

Here are a few questions  middle managers can ask themselves to see how aligned they are in managing teams in an Agile World.  These questions are based on material from "The Manager's Role in Agile" by Michael Spayd and Lyssa Adkins.  

• Are you allowing for self-organizing teams while still providing servant leadership? 
• Are you removing command and control elements while providing bounded authority?
• Are you supporting the Agile values and principles starting with marshaling a culture toward delivering value?
• Do you remove the language of false certainty, big-up-front planning and requirements, and big batches?
• Do you remove the significant roadblocks that hinder an agile team’s progress?
• Do your teams perceive you as a coach and leader more than as a manager?
• Are you helping the team with supporting their people and equipment needs?
• Are you adapting the performance objectives to support team accomplishments to ensure they are delivering the highest value?
• Do you help the teams when they have external team dependencies in order to get their work done?
• Are you fostering a learning organization?  Do you provide teams the time to get educated (training, coaching, etc.)? 

Agile’s Little Secret – It Makes You Money

Agile tends to be introduced at the team level and it’s the Agile teams who are expected to adopt Agile.   While there is various amounts of buy-in from management, some don’t seem to understand that it takes an organization to embrace Agile in order to gain the business benefits.  In other words, management has a strong role to play including adapting their behavior, embracing the Agile values and principles, and leading a culture change, in order to gain the business benefits of Agile.  It requires significant buy-in to achieve a culture change.  But this doesn’t always seem to happen. 

Some of this is not management’s fault.  Part of the issue is that Agile gets introduced to them is various ways – as a way to improve productivity, as a way to speed up development, as a way to increase quality, but in most of these cases, those introducing Agile to them fail to mention the significant buy-in they need to make.  While each of these ways have different levels of merit, it often doesn’t convey enough of a reason for management to motivate a change in their behavior and their organizational culture.    

   

How about changing the message?  Though there are many benefits for going Agile, it occurred to me that to get serious executive/senior management attention and buy-in to Agile is to give them a reason that is near and dear to their heart.  Explain to your management that Agile can increase revenue—in short, it can help them make money (or more of it).  In my experience, this gets them to actively listen, versus the passive listening they may exhibit when they think Agile is an engineering method or something the engineering team and others must do.

Yes, Agile can lead to an increase in customer sales, ergo an increase in revenue. This is all true if the organization is truly allowed to “be Agile”.  This means that teams continually demonstrate working software to customers and they are allowed to continually adapt their requirements to customer needs.  Then teams can more closely align with what customers find as valuable.  The more value customers see in your products, the more likely they will buy (or buy more).  Maybe, just maybe, if you convey that Agile can make them more money, they will listen and buy-in to what it really takes.