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 really is an MVP in an Agile World?

There is often a bit of misunderstanding of what is an MVP (Minimum Viable Product) in an Agile context (and I contend in any context).  MVPs are meant to provide the minimal functionality or feature set that will be useful to customers.  However, to attempt to define the minimal set up front means that you know what the customer wants from the start.  How often do you know what the customer wants at the beginning?

Instead, think of an MVP as an opportunity to learn what the customer wants, loves, and needs.  It should neither be fixed nor should you be certain of what it is.  Instead it should be considered an evolving concept from which you learn what the customer wants over time based on continuous feedback.  What mindset shifts might you have to make in order to adapt to what an MVP is in an Agile world? 

The first Agile mindset shift is the MVP is a draft.  Defining an final MVP upfront is akin to big-up-front planning and claiming certainty.  Instead, you hypothesize what the minimal set of features might be as a draft, and then have a mindset and practices where you validate your assumptions and hypothesis.  You start with an adaptable idea of what might be minimal and valuable to the customer. The moment you attempt to succinctly define the set of features, you are doing a disservice to your customer. 

The second Agile mindset shift is that customer feedback is key to evolving the MVP.  It is an opportunity to learn what the customer wants, loves, and needs.  If you want your MVP to align closely to customer value, you must include continuous customer feedback loops when working on an MVP.  These can take the form of customer demos or hands-on sessions.  Customer feedback can start as early as when you are hypothesizing what is an MVP and must be part of evolving the MVP to gain a strong inspect-and-adapt mindset with the inspect coming from the customer.  Eric Reis writes that an MVP “allows a team to collect the maximum amount of validated learning about customers with the least effort.”  Customer feedback is the cornerstone to validated learning and establishing an MVP. 

So who really determines what is the MVP?  If you think the answer is you, your management, or your team, then maybe its time to Reduce your certainty and Ready your mind with the Agile mindset, discovery mindset, and Feedback loops. The right answer is the customer determines what is the MVP in Agile.  The more closely you align with customers throughout the effort, the more likely you will have an MVP that is considered valuable to the customer.          

There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?

While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?  

Is it finally time to “Be Agile”?

As I look across the Agile landscape, I am worried that Agile has become little more than a superficial tag that some teams and companies seek without really aligning with the cultural shift that is needed to truly become Agile.  What I mean by this is to really align with Agile, it means to understand and embrace the Agile Values and Principles.  While this sounds obvious, I believe there is such little focus on the values and principles and much more so on the mechanics. 

I have hypothesized that those involved in Agile are more knowledgeable about the mechanics of “doing Agile” than understanding the cultural aspects needed for “being Agile”.  My specify hypothesis stated that I believe fewer people could name 3 of the 12.

As I look across the Agile landscape, I am worried that Agile has become little more than a superficial tag that some teams and organizations seek without aligning with the real cultural shift that is needed to truly become Agile.  What I mean by this is to really align with Agile, it means to understand and embrace the Agile Values and Principles.  While this sounds obvious, I believe there is such little focus on the values and principles and much more so on the mechanics. 

I have hypothesized that those involved in Agile are more knowledgeable about the mechanics of “doing Agile” than understanding the cultural aspects needed for “being Agile”.  My specify hypothesis stated that I believe fewer people could name 3 of the 12 Agile Principles, then could roughly name 3 of the 5 Scrum events (i.e., Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective).  In order to make my hypothesis meaningful, it was important to test it. 

With that in mind, I established an experiment that tests if people can articulate the Agile principles and if they can articulate the Scrum events.   I created a simple survey that asked Agile participants to write down as many of the five Scrum events that they knew and then write down as many of the twelve Agile Principles they knew.  I distributed this survey to two different Agile professional events and accumulated over 100 survey responses (109 to be exact).  The results were quite revealing and support my hypothesis.  Of the 109 Agile participants: 

• 59% knew 3 or more of the five Scrum events
• 11% knew 3 or more of the twelve Agile principles

I actually find these results quite astounding.  Could it really be true that only 11% of Agile professionals and enthusiasts could name just 3 Agile principles?  I don't mean they they memorize them but can provide at least the key words of the principle.  This means that 89% could only name 2 or less.  What makes this even more astonishing is that 67% could not name even a single Agile principle (and I did give credit to those who could name the key words of the principle - e.g., self-organizing,  frequent delivery, etc.). 

In reviewing the survey results, about half of the 67% confused the Agile principles with the Agile Values (e.g., Individuals and interactions over processes and tools).  On the flip side, 59% could name at least 3 of the mechanical Scrum events.  Here are two charts that illustrate the number of respondents that could name a certain number of Scrum events and Agile principles. 

Based on this data, my concluding hypothesis is that the reason there is such a lack of awareness of Agile principles is that there is very little education focused on the Agile principles.  This is particularly concerning since the principles form the basis for what an Agile culture should look like. A simple way for each and every one of us to test this hypothesis is to ask these two questions:

• How many Agile principles can you name?  Is it 3 or more?
• How much Agile related education have you have received and how much of it was focused on the Agile principles? 

Now do keep in mind, knowing the principles is just the first step and it doesn't make you Agile. Next its time to live it.  But how do we expect to “be Agile” if our focus is so much more focused on the mechanics or “doing Agile”.   I would suggest that anyone who claims to be an Agile enthusiast ought to periodically bring their work back to the Agile values and principles.  Maybe its time to revisit the values and principles and understand what it really takes to be Agile.