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? 

Rose Retrospective - A Rose by any other Name

Many Retrospectives in the Agile world tend to follow the “what went well”, “what problems did we encounter”, followed by actions for improvement. I call this the WWW (what went well) retrospective. While this serves as a practical retrospective, did you know that there is no one specific retrospective practice expected by Agile? The Agile principle only asks that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  Even Scrum is not specific.  Per the Scrum Guide, it suggests that a retrospective “is to plan ways to increase quality and effectiveness”.

If you are applying the “what went well” type of retrospective, would you like to experience something new, a more adventurous retrospective? Allow me to introduce you to “A Rose by any other Name” Retrospective or Rose Retrospective.  

This is a botanical approach that uses the parts of the rose to explore how things are going and what you can do to improve. The parts of the rose that we explore during this retrospective are the Flower, the, Thorn, and Bud. To put some color to these parts, here are some definitions:

• Flower: This highlights the positives, what you're happy about or what is going well for you or the team.
• Thorn: These are negative things that are impacting your work or life. It may be something that didn’t go your way, causing stress, impediments to success, or something that you’re not proud of. 
• Bud:  These are areas that have a potential to bloom or improve if we nurture and put some focus onto them. They have the potential of becoming a flower. 

How might you implement a Rose Retrospective?  Let’s step through the preparation and steps through conducting a retrospective. 

Prepare the space 

Whether a physical room or a virtual room, create a space to (e.g., white boards, etc.) to add Flower, Thorn, and Bud. 

Determine what cohort of people will participate. It is best to invite those that were actually engaged in the topic (e.g., the team that did the work).

Conduct the session 

Start by explaining the process of the Rose Retrospective and the meaning of the flower, thorn, and bud. Advise them on what they will be reflecting on (the recent sprint, project, time period, etc.). 

Begin with Flowers. Give everyone 5 minutes to brainstorm their flower(s). Everyone shares their flowers. This may include recent successes in delivery, relationships, and progress. You may use data as an input. The intent is boost morale and make people feel proud of their activities and progress. The result is to visualize as a bouquet of flowers on a rose bush.

Continue with Thorns. Give everyone 5 minutes to brainstorm their thorn(s).  Everyone shares their thorns with the intent is to share challenges. The result is to visualize the thorns of a rose bush. 

Finally, the group discusses the buds. Reviewing the Thorns, consider what can be improved and actions for improvement. Provide time to consider the root cause, brainstorm new ideas, and suggesting solutions. Also consider other ideas that may need a boost in areas that are ripe with infusing extra effort to turn the bud into a flower. Prioritize ideas and solutions and focus on the top 2 or 3 actions. The result is to visualize a group of buds that may blossom with some extra effort. 

Work on the actions 

Once the session is over, the next steps are to add the actions to your backlog of work, marking them as high priority. Then work on the actions to turn the buds into bouquets of flower. 

Putting Self-Management into Action!

Applying self-management is a journey that requires deliberate steps. This article, the third in this four-part series on Self-Management explores those steps. The first article explains what is self-management, the second focuses on the difference between self-organization and self-management.  The fourth article shares the challenges in moving toward self-management.  Let’s explore some steps in applying self-management. 

Gauging your Readiness

The first step in approaching self-management is to gauge whether your culture is ready to accept self-management and if there is enough of a mindset that an experiment can be tried.  After all, it is a shift in mindset. Equally important is to gain agreement from your manager that the team can operate in a self-managed way.  This step shouldn’t be taken lightly, since if the environment is too traditional and not accepting of self-management or if you don’t have manager’s buy-in, then you may have some ground work to do before you can get this to happen. 

Leading with Education   

The second step in applying self-management is to understand what is and isn’t self-management (e.g., this can occur in parallel to the first step).  Begin education regarding self-management including what it is and what it isn’t. Consider reading part 1 (What is Self-Management and is it good for Agile?) and part 2 (The Difference between Self-Management and Self-Organization) of this series as a good place to start.

Learn the concept of Bounded Authority as this is a critical element for moving toward self-management.  This concept captures the essence of understanding your baseline of ownership and then allows you to better consider which activities to incrementally move toward the team.

Building your Self-Management Activities Matrix

Create a self-management matrix of those activities the team should own in the first column labeling it “Activities”.  This should include things like backlog management, planning, prioritization, stakeholder management, budget management, staffing, growth, performance feedback, vacation management, space management, guiding principles, and more.  

Then create two more columns to indicate who currently has that bounded authority for those activity.  The minimum bounded authority configuration is 1) the manager owns the activity and 2) the team owns the activity.  This may become more nuanced to 4 bounded authority configurations such as 1) the manager owns outright 2) the manager owns with team input, the 3) the team owns with manager input, and 4) the team owns outright.  There is also a more nuanced bounded authority configuration called the Delegation board by Jurgen Appelo with 7 bounded authority configurations.  I recommend starting with the manager and team columns.   

Understanding your Baseline of Ownership

The next step is to understand where you are right now with ownership. Once the activities and your bounded authority configuration are on your self-management matrix, identify where the current ownership of those activities live today (e.g., manager or team – bounded authority configuration).  This will help you understand where you are today. 

Progressing with an Incremental Approach

Applying an Agile mindset, I recommend an incremental approach in moving toward self-management.  This helps you focus on just a few areas where you think the team can benefit most and/or where it may be easier or more challenging depending on which approach you want to take.  

Discuss your incremental strategy.  Do you want to start with those activities that may be easier to move ownership from management to the team or those that are harder?  Also, determine how long do you want to experiment with this increment.

Now review your Self-Management Activities Matrix and identify 2 to 3 activities that you’d like to move toward self-management.  Discuss what it means to move an activity from manager to team.  This involves understanding what it means to own an activity and the details of an activity.  For example, if the team moves staffing from manager to team, the team should understand what is involved in staffing, who to contact, what processes are involved in hiring, how to get new staff on-boarded, how to get them a work space, computer, id, and more. 

Getting Started

Now it is time to get started.  Once you select the activities to move to self-management, begin the experimentation and adoption process of those activities.  Treat the self-management experiment as a real project or task as it takes time to adopt.  Have checkpoints along the way.  At the end of the increment, consider a retrospective to discuss how self-management and the adoption of the new activities are going (e.g., inspect and adapt).

-->

Finally, it is important to keep in mind that the manager plays an important role toward self-management.  They are effectively giving up control of the many activities listed on the matrix.  The manager will trust the team to methodically own the activities being moved, the team must ensure that it handles the activities with accountability.  Consider periodically communicating progress to the manager.  Remember that it isn’t always easy for a manager to give up ownership of activities so that team must appreciate and embrace ownership in a serious manner. Consider reading the rest of the Self-Management series:

• What is Self-Management and is it good for Agile - Part 1
• The Difference between Self-Management and Self-Organization - Part 2

Agile Retrospective – the Gift that keeps on Giving

As we approach the holiday season and the new year, it may be a good time to celebrate our past success, understand where we may need to improve, and commit to where we want to go in the future.  Applying a “Year-in-Review Retrospective” can be a good way to do this.  This type of Retrospective asks you to reflect on the year (e.g., 2014), embrace what you are thankful for, and help you build meaningful and realistic resolutions for the new year. 

Borrowing a page from an Agile retrospective, here is a personal way to conduct a "Year-in-Review Retrospective".  It can be done individually, with your family, or any size cohort of people.   The 12th Agile Principle asks us “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  This can be adapted to read “At regular intervals, we celebrate our successes, reflect on areas for improvement, and commit to resolutions to improve. “

Let’s begin by establishing a framework for applying the retrospective.  Let’s call this the Retrospective Starter Kit.   We start with creating a reflection (or retrospective) board.  This board should have a place to indicate “What I am Thankful for” (or “What we are Thankful for”), “What can be Improved”, and “Actions for Improvement”. 

Start with reflecting on what went well over the past year.  Document the successes and events and then put them in an order of significances or importance.  Then take a moment and celebrate what went well (maybe over a drink and with some music in the background).

Next, reflect on what was problematic over the past year.  Write each statement as a problem.  Avoid jumping to solutions (that will come next).  Once all problems are listed, prioritize which problems may be the most significant or challenging. 

Lastly, take the top 2 or 3 problems and consider actions for improvement.  You want to identify the root cause for each problem so that you establish a solution that addresses the cause behind the problem.  For example, if the problem is that “I am out of shape”, suggesting a solution of “I need to work out” may not be the only action.  Instead, applying root case techniques may uncover that you need to create time in your schedule first.  Otherwise simply saying that you should “work out” will be unrealistic.  Once you have identified actions, then you must commit to your resolutions (or actions that you identified).   

Over time, if you find the retrospective valuable, you may want to conduct this practice in an increasingly timely manner, possibly every month.  Within an Agile context, this occurs at the end of each iterative of work which could be weekly, bi-weekly, every three weeks, or four weeks.

Finally, in the spirit of giving, may I gift you with the following items:

• Agile Adoption Roadmap – this blog offers many helpful ways to implement and practice Agile to achieve an Agile mindset and receive the business benefits of being Agile. 
• Being Agile: Your Roadmap to a Successful Adoption of Agile – in 24 concise chapters, this book focuses on the business benefits of Agile and then introduces you to the Ready, Implement, Coach, and Hone (RICH) deployment model as a pathway to help you in your Agile transformation.     

Happy Holiday and Celebrate, Reflect, and Improve!

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.  

Daily Stand-up Starter Kit

The Daily Stand-up can be one of the easiest or hardest Agile practice to do well.  When introducing the Daily Stand-up (aka, Daily Scrum or huddle), the initial goal is to get people to share their progress in a brief manner.  The benefit of the stand-up is that it promotes transparency of what everyone is doing where you communicate your progress.  It can also be a place to help you understand your impediments where you can collaborate on addressing the challenges. The focus should be on:

• What I did yesterday (or since the last time the team met)?
• What I will do today (or until the team meets again)?
• What impediments have I uncovered?  

The daily stand-up keeps the team aligned as to what everyone is doing. The "What I did yesterday" keeps everyone in-sync on what progress has been made.  The "What I will do today" helps you plan for your day and helps you commit to a day's worth of work.  The "impediments" are to share what is slowing you down or stopping you from making progress. Others can help you address the impediment once the stand-up is over. 

One challenge is when either the sharing of these three questions are too vague (e.g., yesterday I work on the same user story) or too detailed.  The key is speaking with detail yet brevity.  Enough details should be shared to ensure people understand what was worked on (e.g., yesterday I worked on opening the port to allow communications to occur) or what will be worked on (e.g., today I will work on setting up the asynchronous protocol and set a test packet through the port).  To keep from going too long, an initial helpful instruction is for each team member to limit their progress to about 1-2 minutes (assuming a team of 7 +/-).

Part of the initial adoption of the Daily Stand-up is simply getting people to go from one person to another and provide your daily progress. A challenge is when the team members expect the Scrum Master to tell you when your turn is.  Instead, consider a round-robin approach where you identify an order amongst the team to share progress. This can be alphabetical by name or around the virtual table by site. Another helpful technique in a distributed setting is ensuring each person introduces themselves with their name (e.g., I am Mario…) and ending with a code-word such as “Thank you” or “I’m done”, to let the next person know it is his or her turn.  This is particularly useful in a distributed team setting.

Another challenge is that too many team members direct their progress to the Scrum Master (or leader).  Instead, the team should communicate to each other and avoid directing their progress to the Scrum Master. This allows all teams members to know what each other is doing and promotes cross-team communication.

Once the team has a good handle on the daily stand-up, it can be helpful to evolve the process via the Retrospective. This helps the team reflect on the Daily Stand-up and determine if it is satisfying the needs of the team. For example, you may want to view the stories in the sprint backlog in a priority order and ask those that are working on the highest priority work to share their brief status. The benefit of this is that the team can more readily be aware if the highest priority work is getting done. Because the Agile mindset focuses us on working on the priority work first, this ensures that the progress sharing is focused on the highest priority work first and then so on. This also provides more visibility when the highest priority work are not getting done especially when others are getting done. It then can help you rally resources around the higher priority work that isn’t done.

The key is to adopt, reflect, and adapt. Good luck on your Daily Stand-up journey. How do you conduct your Daily Stand-up and have you evolved it over time? If so, in what ways did you evolve it?

Agile Definition of Done Starter Kit

I often find it amusing when the definition of ‘done’ in Agile is sometimes called ‘done-done’. This is meant to imply that we are not just done with development (the 1st done), but we are done with testing (the 2nd done) as well. However, if you think about all of the activities that are needed to get stories in a sprint backlog into the shape to be potentially shippable, you should probably call it “done-done-done-done” and possibly more (LOL).

So what is the importance of done criteria? First as mentioned, it helps the team understand what is the expectation of getting a story (or the functionality therein) into shape to be potentially shippable. Second, it helps identify the activities and expectations that must occur to build a quality product. Third, all activities in the done criteria are considered when the team sizes the work during Sprint Planning and, therefore, has a direct impact on the sizing of stories. When the team sizes a story, they need to ensure it includes all of the work described in the team’s "done criteria".
 
I usually bring a starter kit of typical tasks to get a story to "done". This helps initiate an active discussion prior to sprint 1 among the team so that each team member understands the various elements of the done criteria and what elements we are agreeing too as a team. Here is my done criteria (aka, definition of done) starter kit:

• Incremental designing (and what type of design type(s) the team will use)
• Incremental development (per the development programming techniques, and this includes developing documentation such as user guides and non-functional requirements associated with the story)
• Incremental building/evolving the unit tests
• Consideration for incrementally building out automation for regression testing, etc
• Applying appropriate source control, checkout/checkin, and branching/merging
• Applying approach incremental local builds (in private workspace)
• Applying code review (or pair programming if being applied) as appropriate
• Incremental testing (per the testing types, e.g., functional, system, integration, etc., pending how much automation there is)
• Meeting acceptance criteria shared by the Product Owner

At this point, the team discusses these elements and establishes a common definition of done for the stories and the sprint. Now keep in mind that this is the team’s common done criteria and it should be flexible depending on the type of work. Also, once the team agrees to done criteria, expect it to evolve over time and it may be a discussion in the Retrospective if it needs improvement. Some of the effort associated with your definition of done is dependent on what tools, infrastructure, and automation, that currently exists and where you want to go, so keep this in mind.

Finally, if your definition of done has nine key activities, then you can call it the “done-done-done-done-done-done-done-done-done” criteria (LOL).  Maybe just one "Done" is enough.  Once you establish the done criteria for the team, don’t forget to evolve it over time to get you to a quality and releasable product!