Week 6: Reflective practice and using repositories#

Studio Abstract#

In this studio, we will investigate two different topics. First, we will discuss and use reflective practices based on the theories of Graham Gibbs, which is part of what you will need to do for each submission in this course. Second, we will give you some ideas for how we expect your Github repository to be used throughout the source.

We will address the following activities and exercises:

  • Overview of Gibbs’ reflective cycle (GRC)

  • Understanding how reflective practice can help future improvement

  • Applying GRC to your experience in COMP1100 so far

  • Using Github and Markdown together effectively to keep track of things other than source code

  • Laying out your team repository

Gibbs’ Reflective Cycle (GRC)#

Devices closed for this entire exercise and discussion

⏱️ 5 minutes - Class

The self reflection is a requirement for each of the three major submissions in COMP1100.

The foundational principle of personal growth is learning from mistakes. This self-reflection allows us to witness and evaluate our own cognitive, emotional and behavioural processes to help us grow. Self-reflection depends on a range of functions including introspection and meta-cognition; and it is important in professional practice as it allows us to continually improve our effectiveness.

Graham Gibbs developed a self-reflection framework called ‘Gibbs’ Reflective Cycle’ in 1988 to give structure to learning from experiences. This is one of the most famous cyclical models of reflection and is used pervasively in professional settings. The structure is circular and a closed loop:

  • Description of the experience

  • Feelings and thoughts about the experience

  • Evaluation of the experience, both good and bad

  • Analysis to make sense of the situation

  • Conclusion about what you learned and what you could have done differently

  • Action plan for how you would deal with similar situations in the future, or general changes you might find appropriate.

The action plan bleeds into the description of the next experience. The idea is that it’s a feedback loop, continually optimising the experience for the most effective and efficient outcome.

Understanding GRC#

⏱️ 10 minutes - Individual

Read through the following article (linked below) and take some notes on GRC. Make sure you understand the framework and can apply it as it will be needed for the next exercise.

🌐 https://www.ed.ac.uk/reflection/reflectors-toolkit/reflecting-on-experience/gibbs-reflective-cycle

Refine your understanding#

⏱️ 5 minutes - Group

As a group, briefly discuss your understanding of GRC and share your notes. If you find similarities in your notes within your group, try to generalise your notes. If there are significant differences, rationalise the inclusion of those differences and try to come to a consensus to what is important to know about GRC and what information is superfluous.

Exercise: Applying GRC to your experience in COMP1100 so far#

⏱️ 30 minutes - Group, Individual and Pair

This exercise involves implementing the GRC in a real world scenario, then reflecting on those learnings and adapting to new situations.

This will require you to revisit the ‘Helpful questions’ from the article above. For each of the six stages, there is a set of helpful questions.

  • On a single post-it note, each team member should select six questions from any of the ‘helpful questions’ in the GRC article, one of each of the six stages (description, feelings, evaluation, analysis, conclusion, action plan).

  • Once you have completed your six questions, within your group, number each post-it note from 1 to X (depending on how many people in your group). Then:

  • Odd number: If your post-it note is odd, stand up and move to another table. Pair up with another person who has an even numbered post-it note, who should be seated.

  • Even number: If your post-it note is even, stay seated at your table for another person to approach you and pair up. After you answer all the questions, swap post-it notes and move on to another table.

  • Once you have a pair (should be someone NOT in your team), the person with the odd number will ask the other person the six questions on your post-it note (note: you should be asking the questions your chose, NOT what the person choose for themselves).

  • Once they have finished, swap roles.

  • When you answer the questions, relate it to a specific reflection from the past few weeks in COMP1100.

  • After about 10 minutes, your legends will stop the discussion, and the person with the odd number will switch tables again to a new table. Repeat.

  • Aim for 5-10 minutes per session. With change overs, you should manage 3 question and answer sessions.

Once the activity time is up take your post-it note and stick it on the whiteboard at the front of the class. Browse everyone elses to see what questions there were.

Take a break#

⏱️ 10 minutes

Using Github in COMP1100#

Devices required for this entire exercise

In a previous studio, you learnt some basic Markdown and checked this into a repository. Part of the reason that Markdown was invented by Gruber and Swartz was because it was compatible with source code repositories like Github, so people could use it for documentation, and repository tools could do things like track versions and detect conflicts.

In this part of the studio, we will get you to start using this more systematically to document your business model canvas, etc.

If you didn’t complete the Markdown task or you have forgotten, have a quick look at the Markdown cheat sheet.

Basic structure#

⏱️ 10 minutes

The basic structure we expect for your repository is below, where each of these is a folder (Interviews should exist already from the Github workshop) and the .md files are inside those folders:

  • Interviews

    • Iteration_1

      • Team member 1

        • Interview_Tue_13_March_2:00pm

        • Interview_Tue_13_March_2:45pm

        • Interview_Wed_14_March_11:00am

    • Iteration_2 - ….

  • Documents

    • Iteration_1

      • business_model_canvas.md (this can include your value proposition canvas)

      • test_cards.md

      • learning_cards.md

    • Iteration_2

      • …

  • Prototypes – when you design prototypes in future

  • Meetings – for any meeting agenda, notes, etc.

  • Code – the source code for your final product

Feel free to add other folders as well.

Your tasks:

  • Create these folders and (empty) .md files. Distribute the work among the team, and commit & push these to your repository; then everyone can pull the changes.

  • Rename the interview transcripts that you have so far to have meaningful names that include the day and time. If you don’t know these exactly, just get an approximate time.

Create your documents so far#

⏱️ 25 minutes

Up to this point, you should have the following:

  • a business model canvas with hypotheses

  • test cards

  • some learning cards

  • interview transcripts

Your tasks:

  • As a team, divide up the above parts of your project so far, and convert all of these into Markdown.

For example, document your business model canvas as follows:

## Business Model Canvas

**Customer Segments**
- Segment 1
- Segment 2

**Value Propositions**
- Value Prop 1
- Value Prop 2

**Channels**
- Channel 1.

**Customer Relationships**
- Relationship

**Revenue Streams**
- Revenue steam

And similar for the value proposition canvas – don’t forget to add one canvas per segment though!

Test cards can similarly be formatted as:

# Test Cards

## Hypothesis 1: Hypothesis name

**HYPOTHESIS**
We believe that...

**TEST**
To verify that we will ....

**METRIC**
And measure ...

**CRITERIA**
We are right if ....

**INTERVIEW QUESTIONS**
1. Question 1
2. Question 2

Similarly for test cards.

Goal: The end result should be all of your work so far, documented as Markdown.

Deliverable: Show your legend when you have completed, and move on to the next task.

Linking these together#

⏱️ 15 minutes

In Markdown, we can use hyperlinks to link to other documents. This can be effective when linking together parts of your project.

The syntax for a Markdown link is: [text](link).

This can be used to link to an external web-page, such as the [COMP1100 notes](https://comp1100.github.io/), which displays as COMP1100 notes.

It can also be used to link internally. To do this, you need to:

  1. Label things. For example, if you have a hypothesis, you would make the title (hypothesis:older-people-dislike-the-green-button)=## Hypothesis 1: Older people dislike the green button. The stuff between () is the name of the link, and the rest is just a normal Markdown heading.

  2. Reference things. For example, we would write: “this is what we mean in [hypothesis 1](hypothesis:older-people-dislike-the-green-button)”, and the text hypothesis 1 would contain a link to the hypothesis.

You can use this to great effect.

Your tasks:

  • Link the hypotheses in your business model canvas and value proposition canvases to the correspond test cards.

  • Link the test cards to the corresponding learning card.

  • Link the learning cards to the set of interviews that you did.

Goal: The end result should be Markdown that allows someone to seamlessly read your business model canvas, value proposition canvases, test cards, learning cards, and interviews; linking to various parts when they want.

Deliverable: Show your legend your beautifully-formatted business model canvas.

Why use Markdown instead of tools like Word and Google docs?#

Git, and most other repositories, only work on plain text files. Uploading images or things like Word documents is possible, but Git will not detect conflicts, will not keep track of versions, etc. Non-text files are just treated as blocks, while text files are treated as strings of individual characters.

This is why Markdown is so popular with software developers!

Bonus: It’s dangerous to go alone! Take this.#

⏱️ ∞

Personal Empowerment through Reflection and Learning#

https://www.youtube.com/watch?v=uzDsT-25w14