1. Ask yourself the question: do I enjoy large or small companies? There are pros and cons to both and you need to figure out what is best for you. This is important in that you want to determine if you want to be part of an organization that does things on a large scale and you may have to deal with more politics. In a small organization, decisions might be made quicker but you also might have more responsibility. In terms of programming, this might include gathering requirements, testing/QA, maintenance along with new development.

2. What kind of stability is important? Does the company have a good track record? Any layoffs in the past 5 years? These days some organizations will cut workforce without hardly any notice, perhaps a week and sometimes none at all.

3. Determine what else is really important to you? (salary, commute, stability, benefits?) There is a lot to consider when considering a new position. Work on large or small teams? Individual or team contributor?

4. The obvious: Are you networking? Are you staying on top of your competition? It is very important to stay in touch with your old co-workers. Where are they working, do they like where they work – do they have any openings? Stay on top of user groups or meetups in your field. There are also a lot of job search outreach programs everywhere, especially in the DFW area. Nowadays, there are plenty of opportunities to connect with peers and learn from them. If you are an expert in a certain area, consider blogging or speaking at local or national conferences to help others.

5. Personal Branding/Social Media: Do you have a blog or website? It is very important to brand yourself in several areas. Have you kept up with your LinkedIn account and is it up to date with skills, awards, recommendations? Do you have an Aboutme page? This is a free service that you can use to brand yourself and list places you can be found on the internet. If you do have a website, make sure you list your resume and any relevant information on your projects. Twitter is great to follow those in your field and find out what they are up to (Latest trends).

6. Update that resume – make sure you have your skills numerous places on the resume. Recruiters and Applicant tracking systems use tag words and key words to find you. Without the keywords and skills, you are not going to be found among the numerous applicants. Take out the header with your name/address and put it in the main section of Microsoft Word. Make sure to use Microsoft Word rather than PDF. PDF looks nice but it sometimes doesn’t get parsed in the applicant systems.

7. Keep track of the places you have applied or have interest in applying. This is very important! Make a spreadsheet on Google Docs or Excel with the apply date, name of company, title of position, and the recruiter you talked to if that occurs.

8. Follow up after you interview. Send a thank you email to the recruiter and the hiring manager. Make it brief and to the point mentioning the skills you can bring to the position. Persistence is key if you feel like you are a match for a certain position but try not to be a pest, that can be a turnoff. See if you know anyone on LinkedIn that is connected to the company of interest. As many people refer to a black hole when applying, unfortunately the internal recruiting staff usually has bad systems or are too busy to even get to the applicants. The managers are very busy behind the scenes. It’s a catch 22, they really need to fill the position but are sometimes too busy traveling or in meetings all day to make time to interview.

9. Landing: make sure you do your due diligence on the company. That might include Glasdoor.com, or finding people you know that work at the company. Are they listed on any Best Places to Work lists? What are the pros and cons? How is the industry itself doing? – are they stable, upward trending? good revenues? Make sure the benefits are in line with your needs (vacation, medical, 401K, work from home?, etc). Agree on a start date and you are ready to go!

Best of luck in your search!

Timing:

20-30 minutes

Materials:

• A minimum of 10 people
• A bag of 20 small coins
• A flipchart to record the scores

Instructions:

4 people are to be workers, seated at a table

Each “worker” will have a “manager” stood behind them with a timing device (stopwatch or smart phone)

Two extra non-workers will also be stood around the table with timing devices

Give the 20 coins to the first “worker” and instruct everyone that the objective of this game is to process the 20 coins through the system of workers.

To be processed, coins must be flipped – one at a time and with your left hand only – and then passed to the next worker in the chain who will do the same. Once the coins have been processed by all four workers, they are considered “done”

Workers may only pass the coins once the full batch of coins is complete.

The managers of each worker will time how long it takes for their worker to process the 20 coins

One non-worker will also be timing how long it takes for the first coin to be processed completely

One non-worker will also be timing how long it takes for the 20 coins to be processed completely

Round One:

Workers operate in batches of 20 i.e. they may only pass coins to the next worker once they have flipped all 20 coins

Round Two:

Workers operate in batches of 10 i.e. they may pass a batch of 10 coins to the next worker once they have flipped 10 coins

Round Three:

Workers operate in batches of 5 i.e. they may pass a batch of 5 coins to the next worker once they have flipped 5 coins

Round Four:

Workers operate in batches of 1 i.e. they may pass each coin to the next worker once they have flipped it

In each, round, the facilitator will capture the time for each worker, the time for the first coin and the time for all 20 coins to be processed.

At the end of round 4, the facilitator will lead the group through the analysis of the timings.

Individual timings will typically increase while the time to get coins process goes down which gives the impression of each worker becoming less efficient (especially those at the end of the process) while the process itself becomes more efficient. Discussions around bottlenecks, cross-functionality etc will typically be instigated.
Variations:

Try throwing in a different sized coin in to the process to see how teams cope with variations

Try tracking how long it takes for an “urgent request” to get through the various batch-sized systems

Teaching Risk Management – 60 mins

Conducting a risk assessment – min 60 mins (depends on the project and how steady your team’s hands are)

Materials:

1 – Jenga game

Flip chart paper & markers

Instructions:

Teaching risk management:

If you have a team who needs to learn about risk management I have some fun with the game. I tell them we’re going on an interior canoe trip to Algonquin Park (Ontario), and we need to conduct a risk assessment. Usually very few people in the room have been on such trips so the example provides for a wide variety in the perception of risk. For example, someone who hasn’t been on a canoe trip will pull a block from the bottom identifying a risk a bear may come through our site.  I would take a block closer to the top as I see the risk of bears ruining my trip as low.  I respect bears but don’t fear them, so therefore I know how to live in their home without creating a problem.

Conducting risk assessments:

Running this game with a project vs. during training doesn’t change the approach. If you’re running this game on a real project make sure you have the team present (including your customer).

If you’ve never played Jenga the basic idea is you remove a block and put it on top of the stack. Eventually if you’re not careful, or you have removed too many blocks the tower becomes unstable and falls.

To run this game:

1) Place the stack of Jenga blocks at the front of the room on a table (preferably one no-one is sitting at to avoid accidents)

2) Everyone is encouraged to come up (one at a time), identify a risk the project is facing and remove a block commensurate to the degree of risk. If it’s a minor risk the person might remove a block from the top of the stack.  If it’s a big complex risk the person might remove the block from the bottom middle of the stack.

3) On the flip chart paper record each of the risks identified and a ranking for the risks. When ranking I usually record it as high, medium or low (the ranking is relative to where the block was removed from the stack).

4) Participants can ask clarification questions regarding the risk and ranking. At this stage I usually don’t allow for risks to be discounted. However I encourage people to discuss where the block was pulled from (remember my bear example above).

5) The game ends when you run out of risks to discuss or the stack falls

As a team you then need to debrief the results regardless of the state of your stack. Leave the stack where it is during this time:

A few big risks resulted in too many blocks being removed from the bottom causing the stack to fall relatively quick.   In this case you may consider things like:

• Do we have so many big risks the project may not be viable?
• What is causing the number of big risks (ie. new technology, etc)?
• How can the team respond to this situation to reduce the risk profile

Too many small risks accumulated to cause the stack to fall (even if you didn’t identify any big risks)

• Do we have so many small risks you project could suffer death by a thousand cuts

The stack still stands after you run out of time or risks to discuss

• Is the risk profile manageable?
• Is the project taking enough risks? Are you being innovative enough?
• Are there things your project could do to increase the innovation and value of the project?

IMPORTANT!  When you’re using this game to facilitate risk assessments, make sure you’re identifying an action plan. If you leave this step out you’re wasting your team’s time. The action items need to be prioritized and included in your backlog based on the ranking the team assigned them.

Learning Points:

• Teach the importance of risk management

• Facilitate the discussion to identify the risks on your project (without dying of boredom)
• Rank the risks without getting bogged down in trying to quantify them (I find quantifying risk rankings in software development is as useful as estimating … it’s often a waste of time!)
• Facilitate team discussion regarding the risk profile of the project

The reason for this is, after the 14 of us finished brainstorming the creation of this game at Agile Coach Camp Netherlands 2012, we came to the conclusion that this game could not be given a name, as doing so would transmit its intention, and thereby reducing its impact.  See, this “Exercise Without A Name” started out as a desire to name, and reveal, the “elephant in the room”. Of course, if the word “elephant” was in the game’s name, then we we would inadvertently lead people to conclusions, which they would benefit to uncover on their own.

———–

Game Name: E.W.A.N. McGregor**

Purpose: help a team admit a difficult topic, to prepare to talk about it & move forward

Participants: Minimum: 4, Ideal: 10-15, Maximum: up to room capacity

Timebox: 20-30 minutes, depending on discussions; allow time for the debrief

Accessories: (Small) room, tape (to mark on floor), lots of chairs/obstacles, camera

*

Creation Date: 29 April 2012 at Agile Coach Camp Netherlands 2012 Co-creators: Thorsten Kalnin (initial question), Deborah Preuss (idea: build elephant using chairs), Silvana Wasitova, Niels Verdonk, Rob van Lanen, Robert van Vark, Coen Sanderink, Jan Salvador van der Ven, Dave Brands, Joost Jonker (?suggested “Ewan McGregor” name), Sander Huijsen, Freek Giele, Sandra Warmolts, Nicola Lovadina (who else?). Thanks to all who asked “what are you doing?” and provided inspiration. Silvana’s Photos: http://www.flickr.com/photos/silvana/sets/72157629932639519/ On Flickr I used tags: accnl12 elephant http://www.flickr.com/search/?w=10905026@N00&q=accnl12+elephant

Steps:

Preparation

1. Select one or two “Observers”, and ask them to leave the room. (Could be from inside or outside the team, but people trusted by the team.)
   Select a “Documenter” to take picture(s) during Step 3.

2. Ask the participants to build a large “obstacle” in the middle of the room, e.g. a big pile of chairs (avoid calling it “The Elephant”).

3. If Obstacle does not get very close to the room’s walls, delineate space tight to the Obstacle Area by placing tape on the floor; game area is “inside” the taped area.  Facilitator: re-arrange chairs as necessary to make obstacle course more difficult, intricate. Take a picture.  Position Participants, spread out within the game area.

Play

4. Run two or three “Challenges” so Participants have to move around the obstacle to go to a  new spot. These should be activities where everyone want to be in one spot at the same time. INSTRUCT Participants to observe and remember their positions, movements and steps around the obstacle. Examples:

   • A Participant invites others to see something at their spot (“Look at this code!”).  Others have to navigate the obstacle to get closer to the inviter.

   • Another Participant invites others to go to another spot. (“Pizza has arrived!”).

   • Optional: one more “movement”.

5. Clear out the “Obstacle” (pile of chairs). (Think about what you will do with the chairs if the room is small). Ask the participants to go to the same starting position as in Step #3 and prepare to repeat the same movements they remember from Step 4..

6. Invite Observer(s) back in.

7. Without explaining to the Observer, Participants repeat the movements from Step  4.

Now it gets strange – what’s going on?

8. Ask Observer(s) for their insights (DO NOT yet show picture from Step 3), e.g.:

   • What do you want to ask us?

   • What advice would you give us?

9. Ask Observer to participate in the “movements”; show the Observer “how we do things around here”; (Facilitator: group will probably warn Observer not to step in the “wrong” places to not get hurt – wait to see if it happens naturally). Main message: that’s the way we work here!

10. Ask Observer for their observations. (Optional: Repeat Steps 6 to 8).

11. Show Observer what the Participants “see” (picture from Step 3).

Shift people to observer mode:

12. As a facilitator, walk right through the “Obstacle”.  Ask all to “Join me in the middle”. This may feel tense. Ask – “How does this feel?” and wait for answers.

13. Ask people to sit down in a circle for the debrief.

14. Debrief.  Sample questions:

    • How did it feel when <Observer> walked through the <obstacle>?
    • How did it feel when <Participant/Facilitator> walked through the <obstacle>?
    • What happened when <Observer>  challenged us?
    • What happened when <Observer>  joined us?
    • What was the role of the <Documentor>?

     

    Connect to today’s situation:

15. Facilitator: explain why you asked the group to do this exercise. Could be along the lines of: “I have been observing how we work… I have a hunch/feeling that there is something we are not talkiing about, that makes us less effective…”

    • What are we not talking about?  (WAIT! Allow for reflection).
    • Facilitator: if things get tense, ask “What is happening right now?”
    • Continue focusing on the team and the process, do not let it get “resolved” by focusing on one particular person in the team.

16. You might want to read up on navigating conflict for the discussion that will surface at this point. See ideas below.

17. At the end of your time: Invite the group back into the center (where the Obstacle) was.

    • Ask: “How does it feel now?”
    • Possible wrap up questions: What’s possible from here? What do YOU want?

     

    After the “Aha Moment”, ask the real questions

    (Optional: can write these down in private, no need to share with others):

    (Optional: Dress up the obstacle so it can be recognized as an elephant)

    • Is there an elephant in the room?

    • Do we have an elephant?

    • What is our elephant?

Possible next step:

• read on Facilitating Conflict Resolution.
• check out Lyssa Adkins’ article on “navigating conflict” instead of resolving it
• set up a big awesome goal and play FearlessJourney.info using the obstacles you are now willing to talk about . Influence change, even without authority!

**About the Game Name:

“E.W.A.N. McGregor” came from “EWAN”, short for “Exercise Without A Name” – since the co-creating group wanted to stay away from using the word “Elephant” in the game name.  Without hinting to Participants in advance what the game is about, they can experience their own lessons and discoveries.  (Please do not call this “Pink Elephant Game” even tho it started out that way )

————

The game’s original write up is at  https://docs.google.com/document/d/10WlzaTpyZS5uHg1fA8NI_inOpjdpNOtOI2br543FtIc/edit

Materials:

piece of cardboard from any unused box  (~20cm x ~20cm), marker, scissor, ~10 threads (around 60/80cm each one), big sheet of paper

Instructions:

You need to do some preparation first:

• Do a hole in the middle of the cardboard piece with your scissor. You need to be sure the pen is able to go there and it is not dropping.
• Do small perforation in each side of the cardboard square. You need to do as many perforation as participants. (between 5 and 15 should be fine).
• Attach one thread to each small perforation.
• Design your race in the big paper sheet.
• You should get something like that:

How to play:

Each member of the team need to pull one thread and place the pen in the start line.

They must do one “clean loop”. It means, not blank spot, and the line is not able to go out of the design. If one of these impediments happens, they need to re-start again. To avoid confusion, you could change the marker color.

To increase the difficulty and fun, you could design crazy races or mazes. Up to you.

It is a game that you could play it few times during the year with the same team, you only need to change the design (race or maze). The fun is warranty.

Learning Points:

Communication, collaboration, and leadership.

As facilitator, you could detect how take the leader and guide the team. I personally, when I detect the leader, I add one extra rule, he/she needs to stop talk for few minute or seconds. The idea behind the game is, the full team need to talk and collaborate to arrive to the end line. Normally after few tries, they got the idea, and they start to talk.

At the end, you only need to ask what happens, and the team alone will come with collaboration and communication as themes to discuss. You could guide the team to the level of communication you are expecting from the team, why and how they could get it.

You could see also one video here: http://www.agilecafe.org/team-communication-improvement

Variations:

You could design wherever you want to add complexity and generate frustration at the beginning

You could add also gifts when they arrive to the end, the last time I gave to each member one post card with a big BRAVO.

Find People on Google-Plus
March 21, 2013 By booleanstrings
I’ve always felt that Google-Plus has a great future, since it was announced. Adding Communities was a big and positive change. A recent shift in its User Interface tells me that Google-Plus continues moving in the right direction.
Did you notice the “new” Find People function?

When selected, it provides the ability to:
Check your gmail address book against your circles
Search “for coworkers” and “for classmates”, that, in fact, offers to look for people from any workplace and from any school. This is faceted search
Import contacts from an address book (a CSV file)
Did you know that all of this people searching functionality has been there a while? The only new (visual) add-on I have noticed is graphically pointing to the number of (sort-of) friends in common; I’ve highlighted on the screenshot above.
The user interface shift doesn’t affect the explained concepts in my recorded Google-Plus presentation available at the Training Library. This people search functionality was previously buried under “finding people to include in your circles”; we explored it in-depth at the webinar. When I present the Google-Plus again, for now, I will only have to re-do the screenshots. What a fast moving target it is, Social Networks and People Search!
I am glad that this better People Search is now clearly visible. Check it out if you haven’t.
Compare this with the “old” search that has been easily visible all along:

The “old” search only offers using keywords and narrowing down to “people and pages”. (The location facet is there, but I haven’t seen it working properly.) The search weakness is a shame, since Google-Plus has well structured information about its members in the About pages, including employment, skills, places, education, and valuable for the People Sourcers links to other social profiles and sites. That, and given that the amount of information in Google-Plus is tiny, compared with the whole surface web that Google search indexes, should let Google-Plus Engineers easily provide us with multi-faceted people search. (Why has it been taking it so long?) The third party site that implemented multi-faceted search early on, FindPeopleOnPlus, it seems, ran out of steam over a year ago, and now covers only a small % of the total network population. Hopefully, the described shift in the User Interface is a sign that Google-Plus is working on solid people search functionality. Let’s keep an eye on it.
Unfortunately, selecting several people and “rolling” them to a circle is no longer available on the new page, while it’s still available on the “old” circles page. Hopefully this inconsistency in the user interface will be cleaned up soon. I prefer the way it used to be.
That’s really minor though. Google-Plus has a big and bright future.
- Irina

Materials:
Paper, pen, scissor, tape, watch.

Instructions:
This game is good fun to understand how to prioritise using the Lean “bucket” system and Agile concepts and managing RISK with the best-known strategy. The participants will also learn the power of information radiators and retrospective.

1. Teams are created (3 to 5 people each)
2. Each one receives paper, a pen and tape.
3. The moderator informs that they should create as many paper
planes -of the following types- as they can:

	1. Jet 2 wings (5 points each)	2. UFO (50 points each)
	3. Tubular jet (5 point each)	4. 4-Wings plane (20 points each)

Each plane MUST fly and be DECORATED.

FIRST Round
Each team has 5 minutes to take a look at the previous type of planes and group them according to the following table:

Basic Plane       - Easy to build, easy to make it fly, standard decoration.
Performance Plane - Medium-easy to build, easy to make it fly, standard decoration.
Exciting Plane    - Medium-easy to build, medium-easy to make it fly, super-cool decoration.
High-uncertainty Plane - Unknown how to build it or make it fly, unknown decoration.

Each group should write the strategy in a banner and stick it to the wall (i.e.  We
will make 4 basic planes first, make 5 of each one, etc).
The moderator should explain that if strategy changes then it has to
be reflected in the banner as soon as it happens.

SECOND round
The team has 20 minutes to make as many planes as they can. Each finished flying and decorated machine has to be stuck to the Basic, Performance, Exciting, High Uncertainty area.

End of the game
The moderator stops the watch and:

1. Reads the different strategies.
2. Discusses with the teams what could have been done in a different way.
3. Counts the points of the flying and decorated machines only.

The team with the highest number of points win.

Learning Points:
Prioritise using the Lean “bucket” system and learn about risk management in Agile and retrospective.

(c) 2011 Erich Buhler

AgileIberoAmerica.wordpress.com

Cathie Hagen, Marie-Claire Dean and Megan Cook invented the game and originally ran this at SxSW 2012. There’s a write-up of that session on Marie-Claire’s blog and also on Adam Kleinberg’s blog (he was a participant).

Timing

This game can be run in 60mins (we did so at SxSW), but you can also make it a longer session if you wish.

Materials

For the “Customers”

• Post-It Easel Pad
• Super Sticky Post-It Notes
• Coloured Marker Pens

For the Zoo Building Team:

Construction workers

• Play Doh  (4-6 tubs per team)
• Coloured Marker Pens
• Coloured Pencils
• Large sheets of blue, green, yellow, white paper
• Pop sticks
• Tape (masking preferred)
• String
• Cellophane
• Scissors
• … anything crafty

Business & Design Group

• Graph paper
• Coloured Marker Pens
• Coloured Pencils
• Super Sticky Post-It Notes

A variety of craft supplies will allow teams to be creative. Therefore, variety in raw materials is encouraged. Also, sharing resources within the team should be encouraged.

Facilitator:

• Timer
• Whistle (something loud to capture everyone’s attention, especially with a large group)

Instructions

Split the players into 2 main groups: the customers, and the zoo builders.

The customer group will help the facilitators guide the game play, by acting as customers of the zoos. They will vote with their feet to determine that zoo offers the most fun.

The zoo builders will be split up into teams to compete against each other. Each team will be split into 2 equally sized groups:

• Planning & Design group (to oversee the overall direction of the zoo);
• Constructions workers (to build the zoo).

Once the teams have been formed, the game can start. The game is carried out over 3 iterations, during which time the zoo is built. After each iteration, the safety inspector will determine if the zoo is safe to open, and if so the customers “visit” their preferred zoo. A retrospective occurs between each iteration to reinforce the learnings from the game.

After the final iteration is finished, the points are counted and a winner is declared.

Learning points:

The objective of this exercise is to the demonstrate the principles of agile, in particular for experience designers:

• Working Software – Why it is important to deliver value early
• Responding to change – How iterative development makes integrating change easier
• Communication and collaboration – Every team member brings something to the table
• Customer Feedback – Importance of soliciting and integrating feedback regularly
• Managing a project – How a success project requires both business and customer needs to be met
• Retrospectives – How continuous improvement is part of the process

You will learn the above by:

• Being rewarded for delivering value early
• Working in a team. We expect successful teams to:
• Communicate between the groups
• Co-locate
• Note: pairing and changing roles is to be encouraged
• Talking to your Customer. The customer role will provide a demonstration of vague and changing requirements. To be successful the team needs to:
• Elicit requirements from the customer
• Elicit acceptance criteria from the customer
• Sharing your observations with the trainers and learners on:
• Balancing business and customer requirements
• Role of a Customer
• Feedback
• Acceptance Criteria
• Adaptive Planning
• Product Evolution
• Feature Refinement

Number of Players

This game is designed for a large number of people 50-150.

Each zoo builder teams consists of 3-12 people

The customer team consists of 5 – 50 people. The recommended minimum number of people for this team is twice the number of zoo-builder teams, to allow for greater variance in voting and a richer experience during iterations.

Please note: As the size of players increase, so will the number of facilitators required. It is useful to have 1 safety inspector/facilitator for every 2 zoo-builder groups, a dedicated facilitator for the customer group.

Game play

For each iteration:

• During an iteration (5 minutes)
  • Customers have specific tasks for each iteration, refer to role description
  • Zoo team builds the zoo
  • Ending an iteration:
    • Safety inspector reviews the built zoos and applies penalties if required.
    • Safety inspector determines whether the zoo is open for business. That is, the zoo must have gate, and at least 1 animal enclosure.
      • If a zoo fails inspection it is closed for business, no points awarded this round.
      • If a zoo passes inspection it is open for business
• Each zoo showcases their zoo.
• Customers vote for their favorite zoo. Points are awarded for each.
• Retrospective (5 minutes):
  • Run collectively
  • Tease out learnings
  • Customers should be allowed to participate in the retrospective

Facilitator Notes: Most teams will be unfamiliar with retrospectives. Provide a quick briefing before the first retrospective to everyone, and assist the teams by helping them focus on process improvement. It may also be useful to provide templates as a framework for the running the retrospectives. The anchors and engines template is an easy, quickly understood template.

Role Descriptions:

Customer

Congratulations! You as a customer get to mess with the rest of the teams J

This group will act as customers for the zoo building teams. This team should be located away from the zoo building teams, a break-out room is preferred. Zoo building team members can visit at any time.

Iteration 1

• Brainstorm what a good zoo should have
• Rank theses ideas

Iteration 2

• Discuss trends/events that may effect zoo attendance
• Vote for a disruptive trend/event. This occurred! The zoo builder teams are told about this event occurring after iteration 2 finishes and before iteration 3 starts.

Iteration 3

• Mingle and checkout progress early with the zoo building teams.

Rules:

• Cannot visit a zoo if the safety inspector has deemed it “unsafe”
• Can fill in comment cards for a zoo at the end of an iteration during “visit” time
• Can join a team at any time
• Can provide feedback to a team at anytime

Facilitator Notes:

The customer group may require hands-on facilitation, depending on the pro-activeness of this group. If needed, help the determining their requirements using fun gamestorming techniques.

Zoo building team

Start with 3 equally balanced teams. The teams can self organize, but people working outside their role are handicapped.

Facilitator Notes:

Resist the urge to prevent the zoo-building team from making mistakes, e.g. overlong planning. Mistakes should be highlighted by the scoring system, and raised within the retrospectives (hopefully by the players themselves).

Construction Workers

You get access to lots of materials. Only current members of the can build the zoo.

Correlation in a software team: developers (front & back end)

Rules:

• Cannot start building without a plan
• Must do what the designers and planners team tells them

Designers and Planners Group

Only have pens/pencils, planning paper, post-its notes. You determine the direction of the build; the construction workers must follow your say-so.

Correlation in a software team: analysts, designers, managers, testers, SMEs.

Rules

• Can assist with building animals/infrastructure, but may only use 1 hand
• Can request safety briefings and evaluations
• Customers embedded into team, join this group

Safety Inspector [Optional]

A facilitator will play the safety inspector(s). They provide briefings on the rules that the zoos need to follow. Briefings are carried out with all teams.

The safety inspector also can inspect. Inspections are only carried out for 1 team at a time. If inspecting during an iteration, they act as consultants, allowing the team to correct mistakes without penalty. If inspecting after an iteration is complete, the safety inspector can prevent the zoo from opening, or remove features that are dangerous (e.g. remove a animal which does not have an enclosure), when inspecting at the end of an iteration. Reasons for failing inspection are always explained.

Rules

• Safety rules are clear, concise and straightforward. They do not change during the game.
• Examples of rules:
• An animal must have an enclosure.
• Predator & prey cannot be in the same enclosure (don’t put the lions with the gazelles)

Facilitator notes: The safety inspector should demonstrate the benefit of testing often, and why quality should be embedded into the process.

Scoring

Overview:

Mura is one of three fundamental Lean principles. In short, it’s about unnecessary variations. It states that people are more productive when not dealing with unnecessary variations. Playing this game should help people to feel a situation when variation is unproductive.

Learning Points:

Ask some of participants how they felt during the first session (with different monkeys) and how they felt during a second session (with only one monkey). What was faster? Which session was more stressful?

After this, let them understand that a task was to draw 8 monkeys, not to draw 8 different monkeys. So it means these variations were unnecessary. Also, it is important to say that a real reason why they were faster during a second session was because they learned how to deal with this monkey.

Help participants to correlate this situation to a real world examples:

• one of the worst situation are unnecessary variations in product backlog. It generates stress and makes us less self-confident during estimations. That’s why we need a balanced flow
• it is relatively often that people implement multiple, slightly different implementations for a same problem. We don’t need such variations. In that case, we should use “a same monkey” – a component
• ask participants to add more real world examples of unnecessary variations

Link to Game: http://zvonekriz.com/2013/03/17/8-monkeys-in-a-cage-a-mura-learning-game/

Participants will quickly learn about how adding some basic structure to tackle problems can help teams self-organize and become more effective. The lightweight structures introduced included iteration planning, iteration review, and retrospective. The team should be able to take away that by having these small meetings, they will be in a cycle of continuous “innovate and adapt.”

Timing:

30 Minutes. Will depend on the number of iterations; however, keeping it short 15 minutes of activity followed by 5-10 minutes of debrief.

Materials:

(# of Teams) * Deck of Cards, white board or flip chart, a visible timer (e.g. http://www.online-stopwatch.com/) , and situation cards (see below). If you like, get some prizes for the winning team.

Hint: Get your cards from a dollar store, no need for great cards.

Number of Participants:

Minimum of six (two teams of three), but ideally you will have multiple teams of 4-7 team members. If you have teams of more than 7, have some play the role of observers and change out active team members during iterations.

Instructions:
The basics of the game are simple – you’ll conduct a two-minute iteration where the team must drop the cards on the floor, pick them up, place them on a table, and then sort them in the order based on the objectives of the iteration. At the end of the two-minute iteration, the team reflects on how things went and what can they do to improve, then we do it all over again.

There are a few things to do to prepare:

• Shuffle the cards – yep, no brainer, but they should be shuffled each iteration.
• Create a scoreboard — have the teams come up with names. At the end of each iteration, you’ll write down the amount of time it took for a team. At the end of the game, sum up the total seconds and the team with the lowest wins (NOTE – the competition helps the chaos of the game, not to mention raises the pressure the teams feel — and it’s fun!).
• Prep the room – teams will need table space and space to move around, so move chairs out of the way.

Some key things to do as the facilitator — you are the Customer or Product Owner in this game. So, when a team says they have the cards sorted correctly, you will need to verify the team followed the instructions. Be picky if necessary — I always like either nice neat stacks as well as make sure they are in the correct order. If not, make them re-do it.  If they get it right, the team captures the amount of time it took them to make the stacks (in seconds).  At the end of each iteration, update the scoreboard.

For the first iteration, simply start – no planning. After the first iteration, give the teams one minute to review and retrospect, then show the next iteration objectives, and then give the teams a minute to plan. Keep the time boxes crisp and rapid.

Now here’s where the fun comes in, after the first iteration — ask one team member from each team to come up to the front of the room and randomly select one of the situation cards. Each team member should read their card, put it back in the deck, and during the iteration – do what the card says. And most importantly tell them, “do not tell anyone what your card says or your team will not be allowed to do this round and automatically get hit with a 120 second iteration.” Do this during the planning minute.

I recommend doing four to five iterations. Below, you’ll find links to download an example presentation with four iterations.

Learning Points:

At the end of the game, have the team reflect on what they learned. Point out the key areas of improvements that you observed. Also, discuss where teams innovated (e.g. I had a team put post-it labels for each number card, and they had one team member take the role of tester). Ask the teams how they dealt with team members acting out their scenario cards. This points out self-organization of the team and point out that sometimes, it is necessary for teams to make hard decisions surrounding other team members.

Variations:

• Change requirements (sorting specifications) right after planning (e.g. make King high or change sorting to colors versus suit).
• During the last iteration, have two team members per team do a situation card.

Resources:

• Presentation - http://agilemaniac.com/resources/52CardPickupMysteryCards.docx
• Situation Cards - http://agilemaniac.com/resources/52CardPickupPresentation.pptx

Thanks to Steve Paro for helping make this game really work!

The era of off-shoring is over.

The data shows that the wage differential between “here” and “there” is no longer as stunning as it once was. Labor costs in China and India, the main outsourcing hubs, have been going up by double-digits amounts every year for the last 15 years, while salaries in the US stayed the same. Labor in some other countries is still cheap, compared to US costs, but the culture difference is greater, and infrastructure is lacking, making outsourcing projects there even more risky.

In addition, a lot of data (and emotions) have been collected over the last 15 years about off-shored work done badly. Companies are now armed with data that activities that used to be considered peripheral to the organization’s success, when done badly, can have enormous influence on the bottom line. A lot of this work is now being brought back in – geographically and culture-wise.

Another problem, that has surfaced with the practice of off-shoring highly-skilled work, concerns intellectual property rights. US companies are used to strong protections of the law, police willing to investigate, and public, generally familiar with and respectful of IP. As some organizations have learnt the hard way, IP rights are different, and are not nearly as vigorously enforced outside of the US and the developed world, as expected. Companies that choose to outsource work involving sensitive or valuable information find themselves largely on their own, when it comes to enforcement, as local law enforcement, even if local laws support foreign company claims, usually chooses not to get too involved in such cases.

All the arguments boil down to one big question: does shipping work across the globe make US companies more or less competitive? With the data available today, when all costs and benefits are taken into account, the answer appears to be that it is more advantageous to work close to home.

We have all new tracks and fresh content for you and will also have trendy food trucks for lunch to complete the experience!

Don’t miss this 1-day packed full of fresh Agile and Microsoft technology and tools information. REGISTER NOW! At just $99.00 per person – which includes breakfast and lunch – it will sell out very fast!

Where: Addison Convention Center

When: Friday, March 1st, 2013

Time: 7:30am – 5:30pm

Register Now: http://www.agiledotnet.com

Timing:

A team of 5 people with two rounds and a intro and debrief for each round took 20 minutes in total.

Materials: 

A team of 5+ people, if larger could be split into two teams.

A way of timing, phone with stopwatch etc.

Post-its and pens.

Whiteboard or Flip chart + pens.

Instructions:

The concept of the game is for the team to communicate a picture through each member of the team and ending up with the last person drawing the same picture on the white board at the end. As somebody in the team described it, “it’s like Chinese whispers, but with pictures”.

The rules:

Each person only has 2 seconds to look at the picture.

Each person has only 15 seconds to draw their picture.

No talking until the end.

The team need to shield their post-its drawings from the others while the game is in progress.

The Flow:

It starts with a Product Owner (the facilitator in this case) describing to one of the team what he wants them to draw, this can be verbally outside the room or already written on a card/post-it. The next person then has 2 seconds to look at the drawing and has 15 seconds to draw the object and then show it to the next person… and so on. The final person in the team can use the whiteboard and draw the last picture in front of the whole team. Starting with the last person the PO then goes through the team asking in turn to guess what they thought the picture was meant to be. The team then scores 1 point for each person who guesses the answer correctly. (for example if by going back through the team the 3^rd person in the chain guesses correctly then they earn 3 points)

The running:

Arrange the team around the table and give them each some post-its and pens. Describe the concept of the game and the flow, then ask for a volunteer to start or which way round the table the team would like to go.

Get the stop watch ready.

At this point it is best to have some objects/things already written on cards for the team to draw (real world items are best: lighthouse, car, umbrella, bottle etc.)

Start the timer and show the first person the name of the object. Then keep the timings and instruct the team when to move on. At the end encourage the last person to standup and draw their picture for the team. Then proceed through the team asking them to guess of the picture, and ask what the team were thinking during the game, what were the challenges etc. Facilitate.

Learning Points: Discussion and facilitation guidance

There are several themes going on here, the communication of visual concepts, the rush and timings, the lack of negotiation and requirements clarity.

The most enlightening moment was when asked in the second round why they nearly all got the same drawing, one of the team said “it was because I consciously didn’t add to the drawing”. Meaning they didn’t solutionise, add to, or draw what they think it ought to be they merely copied the previous drawing. This for me captured the relevance to software development where requirements are misinterpreted and then expanded by the developers without the communication loop from “doing the right thing” to “doing the thing right”.

The first one started off as a bottle, the second a banana

AgileDotNet unites the worlds of .NET development and Agile methods, delivered by agilists passionate about providing superior content in unique settings.

This will be the fourth year of AgileDotNet, and the content will rock you! AgileDotNet brings developers, QA, scrum masters, project managers, and business leaders with all levels of experience to empowering and unique sessions across four tracks. You’ll return to work with the tools, motivation, and support to be more agile – as an individual and as part of a team.

#ADN13 is different from those past. Despite maintaining a high bar for great workshops and discussions, we realized there was a common theme among many of the most steadfast agile coaches and leaders trying to bring change within their enterprise.  The organizations are difficult to change.  Budgets, risks, unfamiliar territory, and planning are all excuses that point to one thing. The enterprise has trust issues.

At #ADN13, we will break the trust barrier down. With a wrecking ball. You will learn from passionate field-tested agilists how to establish trust amongst the team, with management, and throughout the organization as a whole. Regardless of the role you play.

And as if the conference is not cool enough already with agile experts, Scrum experts, and FOOD TRUCKS! Improving decided to up the game another notch. After the conference on Friday, there is a Saturday March 2nd workshop at the Improving Offices. This is just crazy!

What? You haven’t registered? Quick, jump over to the registration site, and

Register Now!

Improving Enterprises is pleased to offer an Agile ALM with Microsoft Team Foundation Server Workshop. In this hands-on, mentored workshop, we will dive into how Visual Studio supports the Development process, the Quality Assurance process, and the Project Management process. We will have a full TFS environment, interactive labs, and instructors on hand for questions.

We will be breaking the day into the three segments.  Each section will include a free form section to bring your problems to the ALM Team at Improving and get some much needed answers.

• Development Lifecycle Management is all about getting a streamlined routine that doesn’t hinder velocity and contributes to quality code. We will guide through developing, developer-testing, and deploying an application.
• Agile Project Management can be quite challenging, and managing multiple projects even more so. We will dive into how to set and measure effective KPIs, automate reporting, and manage work items in an effective, logical, and visible way.
• Quality Assurance Management is encapsulated in an agile environment able to effectively and quickly report on the status of the product. We will walk through defining test cases, writing test steps, recording automation, and enabling regression testing.

Join us on

March 2^nd

and discover best practices around Agile ALM using Microsoft® Visual Studio and TFS. And don’t forget to bring your real-world problems for our on-site mentors!

Hope to see you there!

Register Now!

It has really helped projects get off to a good start and its good to revisit later on to see how peoples understanding have changed.

Timings:  1hour – 1hour 30mins

Materials: The Team, White Board, Pre-written out index cards, Blank index cards, Pen, some method of sticking cards up (magnets, bluetac etc)

Instructions: Draw a big circle on the whiteboard, inside that draw a smaller but reasonably sized circle in the middle. You should now have something that resembles a ring doughnut. Now draw three equidistant lines from the outer circle to the inner circle as if you are going to divide said doughnut equally between three people.

In the very centre of the doughnut write “Everybody” and then put one of the following in each section of the doughnut: Product Owner (PO), Development Team (DT) and Scrum Master (SM). Finally on somewhere outside the doughnut write “no one”.

Now on the index cards write roles and responsibilities with in the Scrum Framework. These are some of the things I have written down in the past, but its certainly not the exhaustive list:

• Scope
• Cancelling a Sprint
• Changing the Product Scope
• Conveying The Product Vision
• Prioritises Product Backlog
• Prioritises Sprint Backlog
• Writes User Stories
• Facilitates Meetings
• Facilitates Retrospectives
• Builds the Product Backlog
• Commits to a Sprint Backlog
• Remove Impediments
• Motivates the team
• Protects the team from outside distraction
• Chooses the Amount of Work in a Sprint
• Commits to Completing the Sprint
• Inspects and Adapts to Improve their Performance
• Manages the Team
• Points Out Other People’s Mistakes
• Makes Sure the Product Works
• Accepts a Story as Ready
• Recognises Impediments
• Accepts a Story as ‘Done Done’
• Ensures Something Useful is Built by Launch Date
• Represents the Business/Customers
• Keeps Stakeholders Informed

Now get everyone in the team to arrange the cards on the board. If a responsibility is for one section of the team it lives in its specific area of the doughnut. If two groups share it, it goes on the dividing line between them and “everyone” and “no one” are self-explanatory.

The way that has worked best for me is tackling each card at a time, talking about it and trying to reach a consensus on where the card belongs, but you can equally get all the cards up there and start pulling them off. I find that can get confusing though.

Variations: This can be used for developing broad understanding of Scrum, but also for specific areas that we may be misunderstanding i.e what are our responsibilities for testing?. I also find that asking: “Where do you think this card goes?” reaps different result to asking the question: “Where do you want the card to go?” so I am sure there are other clever questions that can be asked while playing this.

Learnings:

• This is a very good game for setting the expectations within the team and avoiding conflict due to misunderstandings.
• It establishes a level of good communication throughout the team.
• Creates a very focused discussion on what things should be happening on the project overall.
• Can create commitments from everyone early on.
• Helps expose misunderstands that have grown over time.
• Reinforces the idea of the whole team being the committed people on the project (if you are bored of pigs and chickens).
• It helps highlight responsibilities that no one has taken on or thought about.

This release incorporates a number of smaller features and bug fixes, many of which were originated by users.

Happy parsing!

For 2012, the Beckoning of Lovely up to Dec 21, 2012

http://new.livestream.com/tedx/TEDxSMU2012reTHiNK

a few good ones:
Pay it Forward Foundation 

Greg Parker

Ask me about our new referral program. We will pay out $500 for any referrals who get placed for at least 60 days.

Referral Guidelines:

1. Referral does not already exist in our internal database.

2. Referral has not applied to one of our current open positions in the last 60 days.

3. If the candidate you refer is hired for Improving or an external client through our Networked Recruiting, you will receive a referral award of $500 (gift card) after the employee has worked for 60 days.

4. *Anyone who is not a salaried Improving Enterprises employee or relative is eligible.

5. Referral program is effective between 7/15/12 and 12/31/13 and may be extended at the discretion of Improving Enterprises.