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? 

Can your Desk become your Kanban Board? Yes, it Kanban!

Once upon a time, I found I had little space in the office to organize my work.  With the more recent office hoteling policies, while there is more flexible space, there is less of one’s own personal space.  I wanted a place where every morning I can quickly visualize my work for the day ahead. While there are online tools that I can use, I wanted something more tactile.  What I did have was a desktop surface.  I did have post-its, and sharpies.  I decided to experiment with Kanban on a physical desktop. 

As an Agile Coach, I work in iterations and increments much like I educate and coach teams and organizations.  It allows me to listen to what my customers want and prioritize the work based on value, much like a Product Owner should do. With this in mind, I used my simple tools to craft a kanban board on my desk.

Before I go any further, allow me to provide you with a brief description of what is a kanban board.  It is a work board that helps you visualize both the work and the flow of that work. It helps you optimize the flow of your work by understanding your WIP (work in progress) limit. In its physical form, it is usually shaped by a few state transitions as columns, the most basic include ‘To Do”, “Doing”, and “Done”. My work card (where I write the activity) was written in canonical form and I added when the task was written and then when I completed the work on the card, the “done” date so I could understand my flow.

I took the initial discovery activities that my client (aka., customer) and I agreed to, wrote them onto post-its with my sharpie, and added them to the kanban board in priority order based on both value and order dependency.  As I completed some of the discovery tasks, I added new tasks from my customers to the “To Do” column and reprioritized on a regular basis.  I experimented with keeping my WIP limit to about 3 activities in “Doing” at a time.

What I liked about this kanban experiment was that each morning when I got to my desk, I had my work right in front of me.  This immediately reminded me of my work for the day. It was very easy to maintain as it only took some post-its and markers to update the board. Every morning I checked the work that was in “Doing” so I knew what I had to get done for the day. I also enacted a quick reprioritization of the work so I knew what to pull from the “To Do” column when I had available WIP.  I managed to get a lot of work done this way. 

I’d say the experiment was a success.  What did I learn? That it is too easy to add more activities into “Doing” adding to WIP. This had the unfortunate result of slowing my throughput. What else did I learn?  That yes I kanban!

Building an AI and Agile Culture of Learning

Does your AI and Agile education begin and end with barely a touch of training?  A number of colleagues have told me that in their companies, training ranged from 1 hour to 1 day.  With this limited training, they were expected to implement and master the topic.  AI nor Agile isn’t simply a process or skill that can be memorized and applied. It is a culture shift. Will this suffice for a transformation toward AI and Agile?

Education is an investment in your people.  A shift in culture requires an incremental learning approach that spans time.  What works in one company doesn’t work in another. A learning culture should be an intrinsic part of your transformation that includes skills, roles, process, culture and behavior education with room to experience and experiment.

A transformation requires a shift toward a continuous learning culture which will give you wings to soar!  You need a combination of training, mentoring, coaching, experimenting, reflecting, and giving back. These education elements can help you become a learning enterprise.  Let's take a closer look at each:

Training is applied when an enterprise wants to build employee skills, educate employees in their role, or roll out a process. It is often event driven and a one-way transfer of knowledge. What was learned can be undone when you move back into your existing culture.

Coaching helps a team put the knowledge into action and lays the groundwork for transforming the culture. Coaching provides a two-way communication process so that questions can be asked along the way. A coach can help you course-correct and promote right behaviors for the culture you want.

Mentoring focuses on relationships and building confidence and self-awareness. The mentee invests time by proposing topics to be discussed with the mentor in the relationship. In this two-way communication, deep learning can occur.

Experimenting focuses on trying out the new skills, roles, and mindset in a real world setting.  This allows first-hand knowledge of what you’ve learned and allows for a better understanding of Agile.

Reflecting focuses on taking the time to consider what you learned whether it is a skill, process, role, or culture, and determine what you can do better and what else you need on your learning journey. 

Giving back occurs when the employee has gained enough knowledge, skills, experience, to start giving back to their community to make the learning circle complete. Helping others highlight a feeling of ownership to the transformation and the learning journey.

It takes a repertoire of educational elements to achieve a culture shift and becoming a Learning enterprise. When you have people willing to give back is when the learning enterprise has become full circle and your enterprise can soar.

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

For more Agile related Learning and Education articles, consider reading:

• Agile Education Engine - Bringing power to your Agile Transformation - http://cmforagile.blogspot.com/2014/11/agile-education-engine-bringing-power.html
• There is no Success of Fail, only Learn - http://cmforagile.blogspot.com/2015/12/there-is-no-success-or-fail-only-learn.html
• How a Self-organizing Agile Education Vision can help your Agile Transformation - http://cmforagile.blogspot.com/2014/02/how-self-organizing-education-vision.html