Have you come across Geoffrey Moore’s template for a vision statement? It goes like this:

FOR (target customer)
WHO (statement of the need or opportunity)
THE (product name) is a (product category)
THAT (key benefit, compelling reason to buy or to fund money)
UNLIKE (primary competitive alternative)
OUR PRODUCT (statement of primary differentiation)

For my German readers, here the translation:

FÜR (Zielgruppe und deren Bedarf)
IST (Produktname)
EIN(E) (Produktkategorie),
DIE/DAS (Grund, es zu nutzen / uns viel Geld dafür zu bezahlen).
IM GEGENSATZ ZU (wichtigste Wettbewerber / bisheriger Zustand)
IST UNSER PRODUKT (primärer Unterschied / Mehrwert).

The neat thing is that while the scope is broad and long-term, it is expressed in a very specific way, providing a lot of focus. So I guess that is not the kind of vision Helmut Schmidt had in mind when he coined that phrase!

A good and bought-in vision statement will help the Product Owner a lot during the project when he has to juggle with a lot of user stories waiting to be prioritized and will generally aid communications about the project.

In the case of a Scrum team I was coaching recently, there was general agreement that the product to be developed by this team was needed (to substitute a legacy system that could no longer be maintained). However, there was no clear vision present. So I scheduled a 1-hour ‘Visioning Workshop’ with the team.

A brief documentation of the workshop follows. Feel free to use as a recipe or create your own dish ;)

Preparation:

I prepared a wall with a few sheets of A4 paper, using different colors for the fixed parts and the gaps to be filled, using the template given above. In addition to that, you’ll only need a few pens and plenty of sticky notes.

In the workshop:

First – 10′ Warm-Up

Warm-up is important. Adjust it, don’t skip it!

Creating a powerful vision requires everyone to step out of their rather short-term, tactic day-to-day frame with a lot of constraints present, and to think more freely.

I used the ‘Imagine You’re the Idea’ card from the Creative Whack Pack (highly recommended card set, great on the iPad as well).

After reading out the card, I asked the team first to imagine being the legacy software, timeboxed to 3min. The start was a bit slow, so I helped to get it going by suggesting questions like ‘How old are you?’, ‘What kind of clothes do you wear?’, ‘How do you feel when someone wants to change you?’ etc. This produced a good set of ideas. I captured the words/ phrases on post-its and put them on a flipchart.

In the second round, I asked them to imagine being the new software, timeboxed to 5min. This went much smoother.

As a result, people were not only in a more creative / playful mood, but we had also produced a nice set of characteristics we could use for the exercise going forward.

Second – Fill in the blanks

I then turned around the wall I had prepared (I thought it would have been distracting otherwise). With the help of sticky notes, we went through the 2 sentences and jointly filled in the blanks.

The objective here was not to come up with the final formulation, but to create enough substance that the PO and I could write it up neatly afterwards.

Be careful with the product name section – the quest for a good name can take you right into ratholing. If you feel you’ll not be coming to an agreement within the next 5 minutes or so, put this one aside, throw in a rough working title and schedule a separate session. In our case, we briefly brainstormed subjects and activities involved and came up with yet another TLA (three-letter acronym) which was totally fine for an internal tool.

After the workshop: Drafting the vision

Directly after the workshop, it was a matter of 15min to take the great output of the workshop produced by the team and turn it into two crisp sentences. Done, yeah!

Unfortunately I can’t give you the anonymized resulting statement here as it is quite specific to an industry and would not make any sense if the details were left out.

The effect

I felt this exercise had created a new level of cohesion within the team. Motivation had increased a lot, as the justification for the project turned out to be really clear and much stronger and wider than anticipated. The template worked really well to trigger the right questions.

The vision is now being used on the Wiki pages and in all kinds of stakeholder communication and is a great help for the PO whenever he needs to deliver a pitch for the project.

Bottom line

If you’re at the beginning or even in the midst of a project and you think ‘We don’t need to spend time writing down that vision thingie, everyone knows what this project is about!’, I’d like to encourage you to take the time and do the exercise. It can be done in as little as one hour. It will pay off!

Happy visioning :)

As this was real fun, I continued and took it all a bit further. On my journey I continued to follow the TDD principles and did quite a lot of refactoring.

For example, I found out that having 7 or even 14 ‘inning’ instances would be waste, as all I’ll keep is the score which can easily be stored in the game object. Later I created a Team class to keep the score. It also dawned on me that what I implemented called ‘inning’ is actually a half-inning. All of this was easily changed (also due to the Eclipse IDE).

In the process, the design more or less emerged (I had to make design decisions, but one after the other rather than up-front).

Particularly during this later stage it was a great example for how the agile development techniques are linked. TDD, refactoring and incremental design work as a team like Thor, Ironman and Hulk :)

OK, I guess that’s all for now regarding software development techniques. There’s just not enough hours in the day to spend hours with coding. So… some more boring process stuff again next time ;)

No, this is not about the latest designer drug but about an agile software development technique stemming from Extreme Programming called “Test Driven Development”. (If you want to learn about TDD, there are plenty of resources available online or in old-fashioned books).

It basically reverses the old paradigm of coding first and testing afterwards:

1. Write your test (which will fail) – “red”
2. Write code to make the test pass with the least possible effort – “green”
3. Refactor the code (i.e. improve it / clean it up – another technique)

I recently read the TDD chapter in the book “Agile Entwicklungspraktiken mit Scrum” (available only in German) and tried a few things.

Then I thought that it would be much better if I tried an own example. First I thought about a TimeTracking app for my projects but then I would have had to dig into timing issues / libraries etc.

So I picked a tracker for softball/baseball games. Very basic – just counting runs and outs in innings and keeping track of the overall score.

I first drew a picture of a baseball scoring board and found that an “inning” would be a great place to start. So I went ahead without further ado.

Here are the tests I came up with:

1. Inning starts with 0 runs
2. Inning starts with 0 outs
3. 1 run after scoring once
4. 10 runs after scoring 10 times
5. 1 out scores
6. inning is “open” after the start
7. inning is “closed” (ends) after 3 outs
8. inning is “open” after 2nd outs

I had written down tests 1-5 at the beginning, added 6-8 in the process. I approached them top-down following the 3 steps given at the start. And yes, I didn’t skip the refactoring- removed a few code duplicates, renamed methods etc.

I wanted to upload the corresponding pieces of JAVA art but wasn’t allowed for security reasons. Will have a look at that later on. Oh and in case you’re interested, I used Eclipse and JUnit.

Next I thought I’d move to the “game” level, thus worked at these tests:

1. Game starts with inning 1
2. Game starts with 7 innings
3. No runs or outs when game starts

Here it all got a bit more interesting. The test class and GameTracker class were quickly created, and then I had to make a few design decisions.

How to “glue” innings to a game for instance? Use one instance or keep one instance for every inning? I decided for the latter option which would present more options later on (I hope).

Writing this I notice that I only implemented half innings so far. In a 7 innings game, there will be 14 instances of an inning needed. Anyway, I am sure this will come out with the next development steps where the team notion and offense / defense will have to be taken into account as well.

During the whole process, everything flowed easily and grew quickly.

I got all of this done during a baby afternoon nap (about 90min), which I think is really not bad given that I hadn’t written a line of code for years and had to look up a few syntax rules (e.g. creating an array of objects).

So far, thumbs up for TDD. Yes, in a “real” project everything will be more complex etc. but the basic principle worked really well for me.

I might take this a bit further in the next days / weeks if time permits and if so will keep you posted.

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!