Meeting Facilitation, Scrum

SWOT Matrix: Validating results after 4 months

Have you ever used the SWOT Matrix? Did the results bring about a decision? And then? Have you used the results after some time to validate your decision again? This post describes how I used a SWOT Matrix to help a team to try working with Scrum. After 4 months we validated what we thought then defined as strength, weakness, opportunity or threat.

A “SWOT analysis (alternatively SWOT Matrix) is a structured planning method used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture.”
Prepare a four-square quadrant using 4 or one huge flip-charts. Each quadrant is named one of the following words: Strengths, Weaknesses, Opportunities, Threats.

SWOT MatrixStrengths: characteristics of the business or project that give it an advantage over others
Weaknesses: are characteristics that place the team at a disadvantage relative to others
Opportunities: elements that the project could exploit to its advantage
Threats: elements in the environment that could cause trouble for the business or project
(Source: Wikipedia)

I asked the team to write on post-its what the strengths, weaknesses, opportunities or threats are if we try working with Scrum for 3 months. After everyone had finished writing, explaining and sticking their post-its, we simply clustered the post-its and then dot voted the cluster (“What are the most relevant cluster for that quadrant?”).

SWOT Matrix

By now the SWOT Matrix helped the team already to identify and address all factors related to the change (“Try working with Scrum”), both positive and negative. It also helped team members to understand that they are not the only ones who see a threat or an opportunity. Or the other way around: Team members understand that their identified weakness of the change might as well be ruled out by several strengths of other team members.

Having identified all the factors with the SWOT Matrix I pushed them in a direction with the final question: “How high is your resistance to try working with Scrum for 3 months?” (I made some good experiences in the last months with avoiding “Yes-No-Decisions” but rather to start an experiment with asking about the resistance to something and then try to reach an agreement.) As the resistance to try it was rather low, we worked with Scrum in the last 4 months.

P1010096

This week we validated our decision to work with Scrum and as well checked which of the assumed strengths, weaknesses, opportunities or threats really came true.
It was great to review the dot voted clusters from 4 months ago and then validate if those have proved true. For this purpose I simply prepared a flip chart with a range from “yes” to “no” next to the names of the cluster and asked for each “After 10 Sprints: What has proved to be true?”

As a result we had a good discussion about the clusters that didn’t turn out to be true and what to do about it. (Could be a nice topic for a post as well. :)) Again we finished the meeting with asking about the resistance to keep on using Scrum. As you can see: There is hardly any resistance.

P1010097

Advertisements
Conference et al.

Knackered at Lean Start Up Machine Munich

“Lean Startup Machine (LSM) is an excellent excercise in learning how to validate ideas quickly and figure out which of your assumptions are wrong.” (Jameson Detweiler, Co-Founder & CEO LaunchRock) There is actually not much more to say about the Lean Startup Machine event which I attended last week-end (Aug 9-11, 2013) in Munich. Besides: I hated it, I loved it, it had an unsustainable speed, it was exhausting, it was intense, I learnt a lot, I definitely got out of the building, I am very happy I could attend it and, yes, I definitely recommend attending a Lean Startup Machine when there’s one near you.

Lean Start Up Machine Munich

Made it stick:
Don’t ask “Can I build the product.” but rather “Should I built it.”
If you are familiar with the Lean Startup books, you know this already. Still people think and talk very quickly about a solution before validating their assumptions about the problem. LSM forces you to start with the problem, validate it and only then start to think about a solution. Which helps is the following:

Don’t think “Minimal Viable Product”, but rather “Minimal Viable Experiment”.
If you start with a product already in mind, you are more likely to restrict yourself. If you think in experiments you are and think more likely open. LSM teaches you hurtfully that most (of your) product ideas will turn out not to be working. But you learn that fast, as:

Lean Start Up Machine MunichNobody can predict the future.
True. I knew that before, but forgot. So do a lot of people: they are trying nevertheless, like to draw a plan, spend a lot of money and find out much later.
The same is true about LSM: I expected more fun, took it too easy, hated the mentors who kicked our a****, then tried harder, was still frustrated, but felt really happy in the end. And also on the following day.

This was the output of the team I was working with at the end of LSM Munich:

  • A simple landing page with a possibility to select emails of interested persons
  • At least 20 face to face interviews, including a simple Concierge MVP approach
  • Facebook Page, Twitter Account to drive traffic to the landing page
  • A reasonable insight that the idea could work and how we can move on
  • Several empty bottles of beer and pizza boxes (Thx for the catering again!)

Related articles in the WWW:

Books, Good Question!, Meeting Facilitation

Activity for Team-Building event: The one thing…

The other week the team I’m working with as a Scrum Master had their first team event. We tried an activity that I found quite useful: The one thing I didn’t know about you before this meeting.

Some of the team members know each other already from working together in former teams, others just joined the team or our company and are not very familiar with the others. Our team event was planned for only half a day, the activity was an ongoing activity until the team stand-up the next morning.

At the beginning of the event I presented The one thing I didn’t know about you before this meeting simply on a flip-chart with a QR code and explained the rules:
team building activity

“During the event find out one thing about every team member that you didn’t know before the event. Remember it and post it via the Google Drive Form that is linked to the QR code.”

The Result

The result the next morning was a long list of things we discovered about our team members that we didn’t know about before the event. So with 10 team members we gathered over 90 things. Of course, everyone got access to the list and could read what the others found out about others and about oneself.

Not all of mentioned things can be taken seriously, but we definitely learnt new stuff about the others. When we start to share other aspects of our lives than work with our colleagues, we also start to speak openly with them about other things. Here is again a connection to Lencioni’s The Five Dysfunctions of a Team. (Read related post “Job or Joy” here)

the one thingWhy I liked the activity?

  • It is an on-going activity during the team event.
  • It is easy to generate via Google Drive From.
  • It has a straight-forward list as a result.
  • It has a “Nerd” flavour. (Uuuh! QR code! Uuuh! Type in stuff with my mobile phone! Uuuh! So cool. :))
  • It influenced the “quality” of small-talk during the team event as you needed(wanted to gather data…

If you try this activity, please let me know your experiences.

Books, Conference et al., Meeting Facilitation

Gamestroming Retreat

We need to collaborate more within our teams, with our managers and with our customers. Books like Gamestorming (David Gray) and Innovation Games (Luke Hohmann) or websites like GoGameStorm.com and InnovationGames.com foster fresh practices for facilitating innovations when gathering in meetings or workshops with others. Last week-end I took part in a Gamestorming Retreat at The Hub Vienna.

Like a Code Retreat the Gamestorming Retreat is a day-long, intensive event focusing on enhancing your skills as a facilitator using the practices mentioned above. It is not about getting to know those practices, but rather to intensify on how to use and practice those while getting lots of feedback from the other participants.

The event in Vienna was facilitated by Michael Lausegger (@michael_lausser ) and Clemens Böge (@Beraterei_Boege), the about 12 participants came from different areas. The common theme for this Retreat was Team Development.

After the warm-up, Clemens and Michael shortly described the theory on one flip chart only:

Gamestorming on one flipchart

What followed was practicing this theory in three rounds with three practices:

I used and played all of the practices already before in workshops and retrospectives; still it was awesome to watch how others were facilitating and how different improvisations of the practice lead to different results or problems.

The Gamestorming Retreat Vienna was a great experience: It is helpful for everyone who wants to train her facilitation skills in Gamestorming and who wants to share her experiences with other facilitators.

If I was not living in Munich, I would definitely visit the next Retreat. Actually I’m thinking about organizing a Gamestroming Retreat in Munich. If you are interested, please contact me.

BTW: My team won the Marshmellow Challenge! 🙂

Meeting Facilitation

Agile Retrospective with LEGO® StrategicPlay®

Lucky I am, because I attended “StrategicPlay FUNdamentals on LEGO® SERIOUS PLAY™” about 2 years ago. (Read my post on it here.) My company was unbelievable and invested in the “Identity and Landscape Kit” afterwards and I had the chance to do a number of LEGO Serious Play (LSP) Workshops since (HR team, UX team, different Project teams and others). I especially use the “Exploration Bags” for team building and also for retrospectives.

At “Play 4 Agile 2013” every participant got one “Exploration Bag“:

LEGO Exploration Bag #p4a13

So I decided to do a session with those and get feedback on the LEGO retrospective I tried with teams already.

LSP is mostly about Story-Telling, creating metaphors, Constructionism, De-Constructionism. As a facilitator you try to enable “Flow” for the participants. In that state the participant is “fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.” (Wikipedia)

This is a set of activities that could be used in a LEGO retrospective:

  1. Warm-Up
  2. Build a feeling or mood that you experienced in the last iteration.
  3. Build your wish for the next iteration.

The session at “Play 4 Agile” was on Sunday morning, so we actually did a retrospective on the UnConference.
tumblr_miq2oxzy221s6e8gqo1_500

 

What normally happens is that after the third round (“Your wish for the next iteration.”) you have so many stories, themes or topics on the table. You can then simply start a discussion and create an action plan.

If you feel that the team members really liked the retrospective so far, you could finish with this activity: “Give one of the team members a gift and build this.”

I got really good feedback on the session. Thanks!
And I even got the “LEGO Rampensau Badge”. Yes!

 




 

Good Question!, Meeting Facilitation

Retrospective activity: Significance Story

Remind team members in a retrospective of the significance and meaningfulness of their jobs. After some bafflement they could realize again that their jobs are important and do create value.

This Monday I was inspired by the following tweet:

I tried to work with the answer (“Remind them why their jobs are important.”) in a retrospective activity straight ahead and thought it worked quite well.
Like a User Story Form (“As [role] I want [desite] so that [benefit].”) I asked each team member to complete the following empty columns by wiriting post-its:
My work as [role] has [this concrete significance] for [target group, user]. (Significance Story)

Retrospective activity: Significance Story

In the [target group, user]-column you will find several, different post-its. Ask in the next step what the expectations might be that those users have on them as a team. Let them again write their answers on post-its and stick those in a new, empty comlumn.

Finally let the team decide in a discussion which “Top 3” of the user’s expectations they want to measure up to preferentially.

 

2 3

Be surprised about the outcome.
In my case the team wanted to measure up to the exectation of being a team that creates value and that makes a difference. 🙂

Kanban, Meeting Facilitation

A Kanban Team Retrospective Activity

ticket-kanban

Although Kanban does not prescribe retrospectives (nor any other mandatory meeting) all our Kanban teams are doing retrospectives on a regular basis. As a facilitator of a retrospective you should try to create an awareness of why things went well or not so well and let the team discuss issues that hopefully lead to improvement (“Kaizen”). The following approach describes how to review finished tasks or User Stories of the last Kanban cadence and at the same time making the Spectral Analysis Chart (SAC) more vivid (especially if a team is at war with (Kanban) metrics anyway). 🙂

The team I’m working with at the moment agreed on a 2 weeks cadence: Every other Monday we meet for a retrospective to look for improvements. We collect all items from the “Done” column before the retrospective. I write the lead time (in days) on the ticket and order them according to their lead time ascending on a board (or the wall of the conference room).

Spectral-Analysis-Chart-Retrospective-1

Then visualize where the team’s average lead time is.

Spectral-Analysis-Chart-Retrospective-2

Concentrate in the retrospective on the tasks that are above/beyond the average:

– What are the reasons for the high lead time?
– What can we do to prevent that this will happened with future tasks? Can we do something about it?

Point out to the team members that the visualization on the board (or wall) is actually a SAC, only upside down. With this approach the team members create a better understanding of a SAC (as they connect it to “real” tasks) compared to just showing them an generated chart.

Spectral-Analysis-Chart-Retrospective-3

What do you think?