Scrum Lego City by agile42 is licensed under a Creative Commons Attribution-Share Alike 3.0 Germany License. Openly sharing experiences should be in the spirit of the creative commons license. I’ll provide a brief summary of our setting and the key learning points below.

Setting:

• 5 “players”, 3 of them Scrum coaches, 2 SCMs. So the Scrum Team consisted of PO, SCM and a development team of 3. The game facilitator was part of the development team.
• We used a Lego Duplo set with a train set.
• We used the standard set of requirements/stories as provided here.
• In the Sprint planning, we did not break down the stories into tasks, merely committed to a certain number of stories.
• We used the timing / “rules of play” suggested by agile42 as a basis.
• We used one “event card” in the 3rd sprint: “The PO gets a call from the MD, stating that all work needs to be stopped immediately in order to build a McDonalds restaurant in Lego city.”

Learnings:

• The rather chunky Lego Duplo worked great for a group of such a small size. The train set contains a few handy things such as a crane, train, lorry, … It was definitely sufficient to try out the general idea and to have a good learning experience.
• Towards the 3rd sprint, the (Lego) resources were nearly depleted – make sure you bring a ton! (Or, use this restriction to bring out creativity in people.)
• For a bigger team, the “standard” Lego should be used. It allows for better parallel working on the same story, and for much more detailed results.
• It is important to find the right balance between providing some pressure and sufficient time learning. The proper balance depends on the people involved and the general setting. Particularly less Scrum-experienced teams should not be rushed too much, otherwise learning will be inhibited. The time box for the retrospectives might be loosened or a “Stop” sign agreed for additional reflection any time.
• The suggested 10min for the first Release Planning are definitely too short. For a rookie team, this should be something like 30min.
• We only did a Team Estimating of about 10min, did not play Planning Poker at all. For teams new to Scrum, this could be confusing. There, starting with Planning Poker only and introducing other techniques like Team Estimating or Magic Estimating later would probably be a safer path.
• Timing for the sprints themselves (5′ Planning, 5′ Sprint, 3′ Review, 5′ Retrospective) worked surprisingly well.
• The facilitator should normally not be involved as a player himself or herself, as this naturally distracts attention from observation and things like bringing in event cards when the team works too smoothly ;)
• Last but not least (thanks Sven for reminding me): Don’t let your kids notice you “stealing” (borrowing) their lego sets!! A lot of hassle down the road, certainly if they’re around the age of 3 :-D

Ideas / things to try out in future games:

• If enough people, materials and facilitators available: Try the game with multiple teams working in parallel to introduce a competitive element which increases pressure.
• Use more “events” to get more pressure and learning points.
• At first, only provide the team with half of the available Lego resources, then let them handle this constraints.
• Besides some real “events” like PO getting a high urgency interrupt from management, a team member getting sick etc., behavior-oriented cards could be used. For instance, give players different stereotypes of personalities to play, like a whiner, a very shy person, someone who always tries to dominate the others etc. This will bring much richer situations, as in real life. Remember, the Scrum practices themselves are easy, it’s the behaviors and team dynamics that make things interesting.

During these studies I came across a paper called “How to kill creativity” by Teresa Amabile. (It was originally published in Harvard Business Review, September 1998. You can probably find it in the HBR online archives, I am not allowed to share my copy due to copyright restrictions.)

In her earlier studies, she identified three components necessary for bringing out creativity in people:

• Expertise,
• Creative thinking skills, and
• Motivation.

The latter one, motivation (very intrinsic!), is the piece that can be best influenced by managers and has profound impact.

With a bit of humor,  she suggests exemplary managerial practices in six areas that managers who want to purge all signs of creativity from their teams should follow:

1. Challenge - “Marry” the most eligible employee without any further thought to the most eligible (i.e. most urgent and open) assignment.
2. Freedom – Make sure to change goals frequently or don’t define them clearly at all. Grant autonomy in the name only (i.e. prescribe process and make it risky for your staff to diverge).
3. Resources – Impose fake or totally impossible timelines.
4. Work-group features - Assemble totally homogeneous teams. Diversity is dangerous for team harmony ;)
5. Supervisory encouragement - Look for reasons NOT to use an idea, wait for a few weeks and then put the person with the idea through an excruciating critique.
6. Organizational support – nurture politics and make sure to undermine all efforts of knowledge sharing.

These are a few examples, I’m sure you’ve come across these and similar ones. Care to comment and share your experiences?

I’ll follow up in a few days with the second part which summarizes recommendations for practices managers should follow to make their work environment more creative.

And b.t.w. creativity here has a pretty wide application, not just required for developing new products or services. It also includes capabilities to improve business operations, business model or strategy and is therefore required in basically any organization in today’s business world.

I look forward to your comments, and will post part II soon.

You might have read one of my prior articles about PMI’s Agile Communuity of Practice (CoP) which is currently given fresh life. There were many discussions about PMI’s upcoming Agile Certification, which I’m not going to chime in here. I’d much rather tell you about how I got our local group of the PMI Agile CoP here in Hamburg running.

It all started with a list of ten or so people “interested in agile topics” that I got from the PMI local group lead here in Hamburg. Via Doodle, we agreed the time for our first meeting. In February, we had our first “live” meeting in a local cafe which went really well. We basically used this to agree on ground rules, like place, format, frequency, and timing of our “real-world” meetings, objectives, etc.

How does communication work? We agreed to set up a XING group as the backbone for our communications. (For those of you not familiar with XING, this is comparable to LinkedIn, and much more common particularly in the German-speaking areas of Europe. XING are based here in Hamburg, and one of the early and very successful adopters of agile/Scrum in Germany). We’re using the Events feature to plan our meetings, which we agreed to restrict to 13 people max, as we all felt this is the limit where we could really have one joint meeting. For file sharing purposes, we’re currently testing Dropbox. We’ll see how this works out.

In the second meeting, we developed User Stories for our initial Backlog, which was a really good exercise. We had a few attendees who had never worked with user stories before. They could practice in a safe environment, applying the three-parts structure (As… I want…. In order to…). For the others it was still interesting, as our user stories are very non-technical, e.g. “As an agile evangelist, I want to understand, how fixed price projects can be done in an agile way, in order to explain this to other people interested in agile.” We came up with 11 stories. In the cafe setting, large post-its and a number of pencils worked well, so that all could participate. At the end, we wanted to do a quick prioritization and adopted “Magic Estimating” (as presented by our colleague Sven Röpstorff at the XP Days 2010) into “Magic Prioritizing”. We found that we first needed at least a rough understanding of the size of each story. So we gave all stories S/M/L t-shirt sizes. We then spent about two minutes silently, all moving the post-its around the table, sorting them by their relative priority. After that, we had a brief discussion about two stories that bounced back and forth and had then quickly agreed the initial order of our backlog.

In two weeks, we’ll have our third meeting. We’ll spend around half of the time with networking and chatting, and the rest of the time to start working our user stories.

So far, this has been a real pleasure. Efforts have been reasonable, I’ve met interesting people, and we had many fruitful discussions.

If you’re about to do something similar and would like to get more info from me, just contact me.
If you live in the Hamburg area and are an agile practitioner and/or PM interested in agile, join the group!

You probably know situations like this from somewhere: In a meeting, everyone is mulling over something, and the chair suggests: “OK, so let’s have a quick brainstorming here”. Sigh, ok. You then have about 5 minutes to switch to ‘creative’ mode and spit out anything that comes to your mind. After there are 10 or so more or less mind-blowing suggestions on the wall, you stop and move on. If you’re lucky. Or even worse, ideas are immediately being criticized and/or one of the early ones that seems suitable is selected, and the meeting moves on…

A brief recap of the brainstorming rules below. This might be boring but helpful to be reminded from time to time. Do you (still) know all of them?

• There are no bad ideas (defer judgment).
• Quantity breeds quality (go for 100, not for 10 items).
• Freewheeling (dare to think wild, be crazy).
• Hitchhiking (stealing is ok!)

It is also good to know that in a brainstorming session the ideas / thoughts typically come out in three “waves”:

1. the obvious, usual ideas (somewhat helpful but nothing out of the ordinary) ……….
2. totally crazy, mostly useless ideas  ……….
3. still wild but also useful / more practical ideas (finally the really juicy stuff!)

Did you notice the little dots after the first two waves? That’s where the s-i-l-e-n-c-e comes into play. This is of course what makes the whole exercise a bit more interesting and nail-biting. And: this is where you as the facilitator can show you are of some value ;) First, let there be silence. (Diana Larsen recommended in her book to silently count to 30. Works brilliantly for me.) This will also help the more introverts to speak out. If there are still no creative outbursts in sight after a while: Consider ‘random stimuli’, e.g. postcards, every-day-objects that you gather from the office, or even a change in location (park nearby) etc. These will help your analytical mind to stand back and let your ideas and associations flow more freely.

Example: In our brainstorming session, we used a box of these marvelous postcards that you get in restaurants and bars for free. There are easy to keep in a corner of your shelf or in the meeting room. Just ask people to freely select a card and spit out anything that comes to their minds. In our case, a card with a portrait of Che Guevara spawned a whole new threat of thoughts around revolution vs. evolution, how far one is prepared to go, etc.

Thanks to Marc Innegraeve for putting new shiny sparkles on this somewhat rusty technique (what a metaphor)!

After some practicing and subsequent reflecting I noticed that I’d made one of the most common mistakes myself: I’d stopped too early in some of my brainstorming sessions. I’m glad I know better now, and I’m really looking forward to my next brainstorming now. I might even dare random stimuli (will go for the rather ‘safe’ option of postcards first). Give it a try, too, and tell me how it went :)

I am sitting on the train to Holland, Noordwijkerhout, which is appr 30min away from the Schiphole airport, at the coast of the Northern Sea.
I’ll be spending the next 2.5days there at the last Residential School in my MBA studies with the Open University Business School. This weekend is for the B822 course ‘Creativity, Innovation and Change’.

The travel started really “interesting”. I got up before 6, hurried on icy sidewalks to the public transport, just to find out at the man station that my train was to be 30min late. Plus, the wagon with my reserved seat wasn’t to be part of the train. When the train finally arrived at the platform, it turned out the order of the wagons was reversed but everyone was hurried into the train which was then full of people crossing each others’ ways. Gee. As if we hadn’t had 30 boring minutes on the platform to fix that in advance. The company in my compartment was really nice. And even more luckily, my connecting train in Osnabrück was late as well and waited a few minutes, so that I’m almost back on track. If I had missed that train, I’d have to change 4 (!!) times on my way to Leiden.

The train is just stopping at Amersfoort where I travelled to quite often when I worked for Sun Microsystems. Thinking about old times…

Back to the weekend: There is a full schedule, we’ll be starting early and finishing late. The program is quite flexible, but we’ll basically be working in groups, with some theory but many practical exercises in creative problem-solving techniques.

The residential schools on the European ‘mainland’ are usually a nicely mixed crowd, with many people from mid and eastern Europe, and usually a few ‘exotic’ places as well. It will probably be a lot of fun to work with this diverse bunch of people, and get some of the to know a bit better.

The first mission is to register, check into the hotel and find out the WLAN access. If you read this, I was successful!

PS – As you’ve read at the beginning of this post, my success there was limited ;)

Sure it wasn’t boring but not really hectic either. I was lucky enough to find local projects, which allowed me to work flexible times. Definitely one advantage of not being an operational Project Manager any more.

The year didn’t start too bright though – I had found myself unpleasantly surprised at the amount of reservations in German companies against hiring a young mom. The kind of questions and comments I got to hear were sheer unbelievable. As I was sure of my knowledge and experience, freelancing seemed to be a good solution. And it worked out well! People were then far more interested in my abilities as a professional rather than my private life circumstances.

I made a lot of progress with my MBA studies at the OUBS which were both challenging and interesting. I completed B821 (Financial Strategy), and got my second elective, B822 (Creativity, Innovation and Change) started. Getting closer!

Highlights of the year were definitely the two (very different) conferences I attended: PM-Forum in Berlin and XP Days here in Hamburg. I learned a lot of new things, particularly in the Agile realm, and met many interesting people.

With a good amount of the first quarter under contract already, the year 2011 starts much more comfortable than 2010. I believe it will be another exciting year: I very much look forward to getting the local group of the PMI Agile COP started here in Hamburg. I hope my business network will give me more interesting opportunities to work with clients. I plan to be at the Agile Coach Camp in Rückersbach in June. With some luck, I’ll almost be done with my MBA with only a few months of masters thesis left at the end of this year.

Fingers crossed, and good luck with all of your endeavors in 2011 as well!

PMOs (Project Management Offices) seemed to be somewhat of a hot topic in 2010. There were lots of presentations on conferences like the PM-Forum, full conferences dedicated to PMOs, and many articles in journals.

One common message was conveyed in all of these: A PMO needs strong stakeholder orientation! This applies both up and down the chain as well as laterally. In order for a PMO to succeed, it must a) be aware of their stakeholders (wide focus here) and b) must produce value / quick wins for the most important stakeholder groups at the onset.

Two critical stakeholders for PMOs are typically the Project Managers in the organization as well as management. When starting a PMO (or trying to improve an existing one), care must be taken to help both groups. As needs and objectives don’t fully overlap, this becomes a tiny bit more interesting, though not impossible. Management could be provided with reports and escalations, while Project Managers are offered services that really help them succeed with their projects, making their life easier.

PMI posted an interesting article in the November 2010 PM Network journal: ‘The PMO Survival Guide‘. Recommended!

One quote in the article sums it up nicely:

‘It’s important to talk to both sides. Executives want transparency, and Project Managers need an advocate. That’s the PMO’s role.’

I believe that 2011 will be another year with interesting developments around PMOs, one of them being the agile / lean PMO. Stay tuned!

The format of the session worked well. For those of you unfamiliar with the fish bowl concept: This is an open but somewhat controlled form of discussion. There are four chairs in the middle, that can be occupied by people who want to speak up in the discussion. When someone thinks they have made their point clear, they will stand up and go back to the ‘spectators’, making room for another one to actively join the discussion. The other ones (sitting outside the fish bowl) are silent observers (except from laughter, cheering etc).

Here the most interesting points of view I took away from the discussion, loosely grouped:

‘Self-organized team’ – what is that?

• A very important basis for self-organization is a functioning team. No team players, no self-organization.
• Self-organization does NOT equal chaos. There will be roles, but they will be emerging from within the team rather than being imposed from the top.
• There are still rules, but they are self-imposed and on a meta level (e.g., agreed rules how decisions are being made).
• Team role model like Belbin’s are still valid, and you should try to foster diversity in order to be successful.
• Self-organizing teams need in most cases a frame / boundaries to operate in (i.e., clear mission / targets etc., e.g., a sprint within Scrum), as most teams are part of a wider organization that is not self-organized.

Commitment & Responsibility:

• Self-organizing teams generally take on greater responsibility.
• The individuals in the team must feel some ‘pain’ when team commitments are not being met. This generates the required pressure to initiate required adjustments / improvements. (Pain as a catalyst in the feedback loop?)

The role of the coach:

• The coach needs to convey the objective and guide the team through the process.
• One more quote regarding pain: ‘The coach needs to inflict some pain on the team’. My interpretation: The coach needs to point the team to areas that need improvements, sometimes helping them to get outside the comfort zone.

The role of management:

• Managers of self-organizing teams must have the courage to stand back and let the team go (even if it seems like a tangent).
• Management in general needs to encourage the team and show sincere appreciation for the endeavors.

How to get there:

• Self-organization is the goal, even if many teams won’t get there 100%.
• Self-organized teams need a clear goal!
• Funny: When someone said ‘In our private lives, we are all self-organized’, the audience (mostly male!) burst into laughter. They were obviously thinking about the influence of their better halves on them. Let’s not go there….
• We are all trained, starting from Kindergarten, school, hierarchies at our companies, to learn and work in command&control structures. We have to (re)learn self-organization as individuals.
• Depending on the type of personality and experiences, some people just panic when they’re suddenly confronted with the level of freedom and responsibility that self-organization means.
• As with teams in general, work load balancing is easier with generalists rather than specialists.
• People working in self-organizing teams need to be / get properly skilled in communication, as this forms the connection between the individuals.
• If individuals strive for harmony only, issues will not be discussed, and the chances for improvements are thrown away.

This session really helped me to get a better grasp of the topic. As with many XP Days sessions, the input from the attendees was invaluable. Key fish in the bowl here were Ilja Preuss, Silke Reimers, Jens Oldewey, Uwe Friedrichsen, Jiri Lundak (not a complete list, sorry!). Thanks!

Another interesting post on this topic: “The Myth of Self-Organizing Teams” by Jeffrey Palermo.

The plus list is very long: Well organized conference, very open, interesting people, highly interactive sessions. Only a few minor deltas for me: The location itself was very old school and somewhat dusty, some of the rooms were too big, with lots of reverb and didn’t work well for the format.

As I just recently attended a ‘traditional’ conference (PM-Forum 2010 in Berlin), I noticed quite a few contrasts and thought it would be fun to reflect on them. Please don’t get me wrong – I enjoyed both events, they were just quite different. Plus, I am part of both communities, so I’m allowed to joke about them ;)

Let’s start with some superficial observations about the individuals at the XP-Days, compared to the PM-Forum: As expected, the number of ties at the XP Days turned out to be … zero! Share of women was even lower than at the PM Forum (at 13%), with an estimated 5%. Definitely more piercings, goatees, sneakers, slightly younger folks. There were surprisingly few tweets on the first day, which spiked on the second day and afterward. We were probably all too caught up in the sessions at first! At the XP Days, business cards were much less important, as the biggest chunk of connecting happened via Twitter.

While the XP Forum was like a bee-hive only during the breaks, it was very lively also during the sessions at the XP Days. The sessions had much more different formats, only very few were in classic lecture / presentation format. Attendees were usually actively involved, in brainstormings, idea gathering, fish bowl sessions or good old discussions. The breaks between the sessions were often 30min or longer, and left enough room for a lot of interesting conversations. The two days at the XP Days certainly felt shorter.

A brief list of my favorite sessions, some more details to follow:

• Communities of Practice (Christoph Matthis), where I got a lot of ideas and concrete starting points for my work with the PMI Agile CoP.
• Roman Pichler’s session about Agile Requirements Engineering with Scrum – liked him in person as much as his books.
• Fish bowl on self organization, facilitated by Uwe Friedrichsen. I left this session with a sound view of self-organization and the biggest issues involved. See my session summary here.
• The Power of Feedback by Ralph Miarka and Deborah Hartmann-Preuss – it never hurts to be reminded of the power and good practice of feedback. Highlight: the appreciation shower!
• Rachel Davies’ keynote on the 2nd day with some concrete guidance and tips for agile coaches, where she reminded us to be patient, as change takes time, and not always is a good time for a change!
• Olaf Lewitz’ session “A good cook alone is not sufficient, you need a good kitchen as well”. I liked the metaphor very much, plus the session was well moderated, with attendees reflecting on the information flows between Scrum projects and the organization, what works and what could be done to remove impediments. Nice one!
• Jens Himmelreich was in ‘The agile Self’ courageous enough to talk about the dark side of the Force – the negative implications of the shift towards the “service economy”, with some rudiments of ways to protect oneself. Very valuable!
• I learned a lot about Kanban (and ScrumBan) from Olaf Lewitz, Arne Roock and Bernd Schiffer. Interesting stuff, helpful (though somewhat lengthy) exercises. WIP limits sound like a good approach to experiment with in Scrum teams, too.
• Bernd Schiffer enlightened us in the ‘decisive session’ about some of the more cognitive aspects of decision making, and presented some concrete examples of decision-making processes that deal well with our own cognitive limitations.
• Last but not least I attended Sven Roepstorff‘s Wildcard session about Magic Estimating, an agile estimating game derived from ‘affinity estimating’. We tried it out in teams, and it worked really well. Estimated 40+ stories in under 10 minutes. Will use this for our next big chunk of requirements. It is a good choice for a first pass – so much quicker than planning poker.

Overall, there was a ton of input, which will take some more time to digest. I will start into the next week with new impressions and ideas, looking forward to it!

This will be my first conference of this kind, so far I’ve been more around the ‘traditional’ conferences like the PM-Forum, so I am looking forward for some interesting experiences and potentially contrasts. I’ll probably be able to count the suit and tie folks on one hand. Place your bets!

Topic-wise, I am particularly interested in learning from other agile practitioners about techniques / serious games / practices they successfully applied in their teams. There are a number of interesting workshops, e.g. about warm-up exercises (potential for awkwardness?) or much more exciting estimating games than planning poker (yay!).

Plus, I hope that there are more folks like me who do agile-but-not-software-development-kind-of projects. Let’s see. There are definitely some more generalistic sessions around things like overcoming resistance, the role of the ScrumMaster and so forth. One of the Wildcards I am very interested in made it into the conference, too: A brief session around agile coaching of organisations.

I’ll keep you posted on my Twitter channel and with some blog posts as time (and network connectivity) allow.