Tag Archives: agile

Team Building Activity – Look into the future!

Posted on by
Reply

This past Wednesday I had the opportunity to facilitate a workshop with all the senior leaders in our organization to start working on our Annual Objective for 2024. As part of that workshop, I put together a team building activity to bookend the workshop. I got a lot of positive feedback from the attendees, so I thought I’d share what we did here, along with my lessons learned, so that others could use it if they were interested.

Activity: Looking into the future
Time Required: 10-15 minutes
Materials Needed: A decent sized ball. I used this kick ball.

  • Get your participants to stand in a circle, ideally arms-length apart.
  • Stand in the center of the circle and introduce the activity while holding the ball. Here’s a paraphrase of what I said to my team – “Today, we’re going to predict the future. Now, as many of you know, I’m an actor. The last show I was in was about a medium who used a crystal ball to speak with dead Hollywood celebrities. I learned something very valuable when I was doing that show – Genuine crystal balls are heavy, fragile, and expensive. The crystal ball we were using was the most expensive part of the show. Even more expensive than my salary! Because I want to be responsible with our members money, and because I don’t feel like cleaning up a bunch of broken glass, I’m going to ask you all to use your imagination and pretend that this fine kick ball is, in fact, a very fancy crystal ball and that when you are holding it you can see into the future.”
  • Introduce the rules of the game. These are the rules that I shared with the group on Wednesday (you can partially see them on the slides behind me in the picture above).
    • Only the person holding the ball can speak.
    • Players who are not holding the ball may communicate with eye contact, gestures, etc…but no words.
    • Prediction must be accompanied by the current count of predictions
    • If a prediction is a repeat of a previous prediction the team must start over
    • Predictions may, however, BUILD on previous predictions. Example – “1! There will be a rain of trout that hits New York City!” “2! The ambassador from Chile will suffer a serious injury after being hit on the head by a falling trout.“
    • If the ball hits the ground for any reason the predictions must start over.
    • If a new round of predictions begin, predictions from a previous round may be repeated
    • You cannot throw the ball back to the person who threw it to you.
  • Explain that the goal is to see how many predictions the team can hit in the time allotted. You should challenge the team with two goals – One of them that you think should be achievable, and one that should be hard. In our case, we used 25 and 50. Put some kind of bet in place to make it interesting. I initially had the idea to be the “bad guy” and assert that the team would never hit the goal and my partner (Adam Ulery from Compass Productivity) would be the “good guy” and bet that they would. I volunteered to agree to conduct the rest of the meeting using my puppet, Mr. Judgey, if I lost. We were discussing our bet with the CEO before our workshop, and he got into the game in a big way. He offered that if the team hit 25 predictions we’d donate $2500 to the local chapter of Celebrate Birthdays (the charity the team was sponsoring for the day), and that if we got to 50 we’d donate $5000. I threw in me using the puppet for the rest of the meeting as a bonus to tier on the 50 predictions.
  • Toss the ball to one of the participants and get the game started!
  • Play referee and make sure they follow the rules.
  • If you can, record the session.

The point: I based this activity on an exercise we have used as an ensemble warm up in a few of the productions I’ve done in the past. In that activity, the goal was to keep the ball in the air and count out every time you hit it, and the point was to get everyone in the ensemble thinking and working together as a unit before the show begins. It’s also a lot of fun. In this case, I wanted to add on to that by getting them thinking about the future as our workshop was around building an Objective for 2024 that would focus on the Most Important Thing our credit union would accomplish next year.

Retrospective:

  • What went well: The team hit the stretch goal, with a list of 50 predictions that ranged from serious, silly, far-fetched, and realistic and pretty much everything in between. We had some laughs, shook off the after-lunch drop in energy, and got into the right mindset to do some forward-thinking. We raised $5000 for charity and I got to freak everyone out with my eerily accurate Muppet. We gave a spontaneous lesson-in-the-moment about stretch goals in relation to the 25 and 50 targets, getting the team to agree that if we had started with 50 as the goal, or even 75, that they would have been less motivated to try and hit it.
  • What didn’t go well: I didn’t anticipate how quickly the team would devise a strategy to get to the goal without dropping the ball. In the theater world, the ball is constantly moving. In this scenario, the team member got to hold it while they were making their prediction. They quickly realized they could just hand the ball to the person next to them and let it go around the circle. There was also no motivation to make a prediction quickly, so team members holding the ball could pause to think about an answer.
  • What I’d do differently: Add the following rules to the list above –
    • You cannot pass the ball to the person immediately to your left or right.
    • You cannot move from your spot.
    • If you hold the ball for more than 5 seconds the count resets.

Conclusion

After we finished the workshop I closed our time together with the following (again paraphrased, because I don’t work from cue cards my friends):

I spent a good deal of time working in and around Renaissance Festivals when I was younger. Yeah, probably not much of a surprise given the fact that I’m wearing a kilt. When I was doing so, I got to know quite a few fortune tellers – Tarot card readers, psychics. You name it. I’m sorry if I’m ruining the illusion for you, but none of these people possessed any kind of supernatural powers. What they had, was the ability to look at the world as it is, look at trends, ask probing questions of their patrons, and make a relatively accurate prediction about what their future looked like. We did that together today. We may be right, we may be wrong, but we used our collective knowledge together to gaze into the future and make some predictions. I’m excited to see how they turn out.

Bonus: Adam recorded the session for me, and I’m going to keep track of their 50 predictions for 2024 to see how many come true!

Update: I can’t believe I left out one of the most impactful parts of this! As I was finishing my summary, I asked everyone to pass the kick ball around the room one last time and sign it as we moved on to our next activity. This, I told them, was our contract that we were committing to building a future together as one big team. I gave the ball to our CEO as a memento of the event and a reminder for everyone of what we did together.

Some thoughts on “Comprehensive Documentation”

Posted on by
Reply

There is no value in documentation.

Why Would You Say Something So Controversial Yet So Brave? is a quote from The Eric Andre Show rendered in an image macro and used as a reaction image on Tumblr humorously in response to relatively banal statements.

I am sure that if you know me personally, or if you are at least tangentially aware of what I do and how I view the world, you are rolling your eyes right now and writing off my statement as being naive. My ask is that you go along with my thought process for a minute to understand what I am really saying.

One of the four values in the Agile Manifesto is “Working Software over Comprehensive Documentation.” Many people inherently interpret this as meaning that those of us who resonate with the manifesto believe that we should never document. This is patently untrue. In fact, if you look at the statement under the four values it explicitly says that “while there is value in the items on the right, we value the items on the left more.” Agile enthusiasts do not advocate for the abolition of documentation.

What we want is documentation that is valuable, and for documentation to be valuable it must be useful. The people it was written for must be able to find it. They must be able to understand it.  The documents must be relevant to the current environment.

Having a document repository that nobody uses is wasteful. Putting effort into populating such a repository is wasteful. Using physical and/or virtual space to store documentation that is never referenced is wasteful.

One of the reasons why I am so critical of “traditional” project management practices is because of the amount of documentation that is considered a requirement for projects to be completed, and the main reason I feel that way is because I see most of them being designed as cover for the Project Manager. Often, I see situations in which a Project Manager has all the responsibility for ensuring project success but none of the authority to make it happen, so they make sure that they document everything that they do to be able to say they have done their job when a project fails or is delayed. I cannot tell you the number of times I have seen this happen personally. I have, in fact, watched a Project Manager bring up said documentation and force people to look at it to prove exactly this.[i]

I do not claim to have the right answer for what is the proper amount of documentation in any given situation. Like most things in the Agile world, it really depends. As a developer, I was a huge fan of self-documenting code (using variables with long, descriptive names to describe what the code was supposed to do), so I did not spend a lot of time adding comments to my code. I also contend that if your organization does not have individuals dedicated to the creation and curation of knowledge most of your documentation efforts are going to end up being wasted (largely because doing so is a full-time job). If your end users search for a document on your intranet and cannot find it, it might as well not exist.

Even more controversial is the notion that your systems/processes/products should be designed in a way that does not require documentation in the first place. Documenting complexity does not generate value for your users but eliminating that complexity does.

Creating documentation is a process, and like any process you should constantly evaluate it to determine whether it is generating value. If it is? Think of ways to make it more valuable! Maybe teach others how to do what you are doing or find ways to make your documentation more accessible to your end users.[ii] But if, as if often the case, your documents are essentially locked in a disused lavatory behind a sign that says “Beware the Leopard” your time could be better invested.

[i] In the specific example I am thinking of, the PM in question asserted that it was not their fault if the people in the meeting were unaware of a situation because the PM had followed the communication plan. My contention is that if you followed the communication plan and your message still did not get across the fault is in your communication plan, not the people.

[ii] If, for example, a user says they searched for your document on your company intranet and could not find it ask them to show you what they did and give that feedback to the people who manage the intranet.

They Moved My Cheese

Posted on by
1

Kanban board

Sharpies are important

When I decided to start this blog, my plan was to chronicle my experience as a member of middle management and my possible path further up the corporate ladder. I should have remembered that old saying about best-laid plans and what not, because a week after I created this blog and put up my first post my proverbial cheese got moved.

A lot.

Nothing bad, mind you. I didn’t lose my job or anything dramatic like that. I was asked to take on the role of Scrum Master/Agile Coach at my organization.

Continue reading →