Das Multitasking-Namensspiel

... oder: Wie lange dauert es einen Namen zu schreiben

Henrik Kniberg hat 2011 sein Multitasking Name Game beschrieben. Ein Spiel, das er bei seinen Trainings einsetzt, um den Teilnehmer die Folgen des Multitasking zu zeigen. Es ist für Gruppen von 10-20 Personen gut geeignet, lässt sich aber auch auf größere Gruppen skalieren. Die Übung dauert ca. 20 min., für das anschließende Debriefing benötigt man ungefähr noch mal die gleiche Zeit.

Da seine ausführliche Beschreibung bisher nicht auf deutsch verfügbar war, habe ich sie jetzt übersetzt und stelle sie unter diesem Link zur Verfügung:
Das Multitasking-Namensspiel.


Über Feedback zum Spiel und auch zur Übersetzung würde ich mich freuen.

The Business Model for an Agile Community - Part II

The Discussion - Part II

At the January meeting of our Agile Community called "Agiler Stammtisch" we continued our discussion about the Business Model. The question was: What would be the right Business Model for our Agile Community. We used the Business Model Canvas to talk about the different aspects of the model.
The first focus of the discussion was the value proposition. From there it switched to the Customer Segments. And then we improved both aspects and also added some Channels. From there we moved our focus to Key Acitivities and Key Ressources.

Business Model Canvas

Like in our first session we saw that the tool Business Model Canvas (BMC) had some positive effect on our discussion. We were a group of eight people and only three of them had attended the first session. So we had to discuss our aproach first. The BMC allowed us to start working, write down the first results and go on with the next aspect. It enabled us to consider the different aspects concurrently. By using Post-Its it was possible to rearrange the results on the canvas.
Another benefit of using the BMC is that you can even capture states of the discussion, where there is no final agreement. In our discussion we found that "networking" belongs to Value Proposition as well as to Customer Relationship. So we placed our "networking" Post-It on the border between Value Proposition and Customer Relationship.

Example: Customer Segments

What are the Customer Segments of an "Agile Community Gathering" like our "Agile Stammtisch"? First we found "coaches" and "practitioners". Then we realized that these segments did not have distinct Value Propositions or Channels and we removed and replaced them with "searching for help", "giving help", "interested in social contacts" and "searching for customers".
These Customer Segments connect to different Value Propositions, which increases the expressiveness of our Business Model.

Conclusion

Again we did not come to an agreement how the Business Model for an Agile Community should look like. But again

• we had a fruitful discussion with lots of good ideas,
• we have been able to consider the different aspects of a Business Model,
• we have been able to depict our findings during the discussion and
• we had fun.

Using the BMC helps to keep the discussion open, not to narrow down the discussion frame to early and to delay decission until the appropriate moment.
It is a tool that supports the agile approach: set up a BMC, change it whenever new ideas pop up, and use it as the information radiator of the current state of the discussion.

The Business Model for an Agile Community

Starting an Agile Community

Since two years I'm trying to have meetings of Agile people in the Rhine-Neckar region of Germany. We have met more or less monthly, have discussed our Agile ideas, have played games and have learned a lot from each other. So it was and still is a good experience to have these meetings.

But there is something that I would like to change: It is me who is inviting to the meetings, I'm trying to find a location every month. So, it's more or less "my duty" to make the meetings happen.

As an Agile person I made several attempts to change this: I invited other people to spread the word, to write some articles in our forum. I convinced some group members to do a presentation on our meeting. I even asked the team! And I have had some success: some of the meetings have been organized by other people and participants have written some blog posts about our meetings.

But there is still just a small team facilitating our meetings. In fact the things still depend very much on my efforts.

Some weeks ago I attended the yearly meeting of the German Scrum community "Deutsche Scrum" in Darmstadt. It was a two-day conference which included an Open Space. In this Open Space I hosted a session on the topic, how to establish a local community.

And these are the results, we have gathered during the Open Space session:

• do regular meetings (e.g. always on the second Tuesday of a month) so that people remember the date
• find a location, where you can regularly do it, so that people know where to go
• invite "rock stars" to attract participants
• always have a theme (a topic, a title) for the meeting so that people want to join
• be inviting and open to new participants so that they feel comfortable from the start
• ((and some more))

Business Model Generation

And there was one additional hint we got from he organizer of a local "Lean Startup" group. He asked:
Did you ever try to discuss the Business Model of your Agile Meeting?
When you set up a Business Model, you think about the following:

• Who are your "customers"? 
• What are your "sales channels"? 
• Who are your "key partners"? 
• What are the "value propositions" you give to your "customers"?
• What is the "cost structure"?
• What are your "revenue sources"?

On our last meeting (second Tu. in December) we discussed about our "Business Model". After a short introduction to the "Business Model Canvas" http://www.businessmodelgeneration.com/canvas we tried to set up the Business Model for our Agile Community. The tool we used, the Business Model Canvas, was helpful to widen the discussion. We tried to include all of the nine aspects of the canvas.

We did not manage to discuss all the aspects, but we think that we are heading into the right direction.

So we decided to go on with this approach at our next meeting. And I think you already know, when it will be:

On Tu. 8.January 2013 (the second Tu. in January) at Wirtshaus Uhland in Mannheim (the same location as last time).

Current State of the Discussion

This picture is a snapshot of the current state of our discussion at the end of our last meeting:

Key Partners:

• University Institutes
• other Agile groups: Karlsruhe, Rhein-Main

Key Activities:

• Find "Rock Stars"
• visit companies
• prepare and announce a theme

Key Resources:

• Agile "Stammtisch" once a month

Value Propositions

• discuss real-world problems with likeminded people
• exchange information on research findings
• get to know new things
• drink beer, without time pressure, in a pleasant conversation
• wrapping-up Agile events, where - as always - was not enough time
• Stammtisch with preparty: e.g visit a company with a small group, then report at the Stammtisch

Customer Relationships:

• ((empty))

Channels:

• ((empty))

Customer Segments

• People interested in Agile practices, who have time (or want to take time) in the evening
• Practitioners from big companies
• Practinioners from small companies
• Researchers
• Consultants

Cost Structure:

• Freetime investment

Revenue Streams:

• finding new contacts (for consultants)

((To be continued after the next meeting, stay tuned, or even better: join us in Mannheim))




 

ALE Bathroom Parties

As I said earlier, I like to meet people face2face. On the other hand, I like to get information on Agile. This is why I try to attend Agile conferences like ALE 2012 or smaller meetings like Scrum Days or the meetings of groups like Deutsche Scrum.

To get information on Agile there are other possibilities: You can read blogs, study all kinds of personal and commercial web sites, and attend to virtual events on the Web.

The ALE network has started to have a regular weekly virtual Open Space called xALEc every Monday evening and a web conference called ALE Bathtub Conferences every some months.
In these web events you can hear and talk about agile ideas and concepts.

Unfortunately attending such a web conference does not serve my wish to meet people face2face. So what can we do to add this local meeting aspect to the pan european web conferences?

It's easy, just sit together with some other agile people, get a projector or a big TV screen and attend the ALE Bathtub Conference in your living room.

We once did this on Dec. 6 2011, when the Scrum User Group Rhine-Neckar attended ALE Bathtub IV in Heidelberg. We have been about 5 people listening to the speakers and having discussions about the topics. It was real fun.

Now we want to invite you to do similar meetings on Tu. Nov.27 2012 when the next ALE Bathtub Conference ALEBathtub VI will be held.

Join the ALE Bathtub VI as a team and do your own ALE Bathroom Party. Stay tuned for the registration on Twitter from @bathtubconf and invite to your ALE Bathroom Party on Twitter with the #ALEBathtub tag. You may even say hello to other ALE Bathroom Parties through the web at the conference.

See you at ALEBathtub VI

Think globally, meet locally

I like being together with people I like.

I like to have discussions.

I like to think about the "right" way to do business.

And I like the agile way of getting things done.

These are some of the reasons why I spend my time reading about Agile and Lean, why I'm helping companies to become more agile, and why I have started a Scrum User Group in the Rhine-Neckar region of Germany about two years ago.

Our Scrum User Group tries to meet every one to three months for a so-called "Scrumtisch", discuss all agile topics, play games and have a nice time. We are between three and 15 people coming together each time. A year ago (or so) an other group was founded in our region: "The Agile Round Table Heidelberg". We started to join the other group's meetings and they joined our "Scrumtisch".

During the last months we realized, that it takes a lot of effort to keep the momentum of such an event. You have to find the dates for the meetings, you have to invite the group, you have to attend it yourself. So we thought about combining our meetings.

In a small retrospective at our Scrumtisch yesterday evening we discussed, why it is so difficult to "keep the momentum". One reason we thought about, was that fixing a date for the next meeting was not an easy task.

And - what are we always telling our clients and colleagues - how agile people deal with this problem?

We are having regular meetings! Then you can have a long term planning, the date is in your calendar and the only question is: where will it be this time?

So, now we do the same: From now on ...

We will meet every second Tuesday of the Month

An other thing we discussed in our yesterday's meeting was how to name our combined meeting. "Scrumtisch" is not a good choice because not everybody is doing Scrum. Taking one of the group's name for the new combined thing would not be a good choice, too.

I'm a big fan of the ALE Network (the Agile Lean Europe Network), which brings together the European agilists (and some non-european as well).

And so we decided to have our future meetings under the umbrella of the ALE Network.

Our meeting is the ...

ALE Local Group Rhine-Neckar

So, if you ever come to the Rhine-Neckar region of Germany and it's the second Tuesday of the Month, come join us to have a beer, a glass of wine or water and make friends.

Agile Plagiarism

Once I wrote an article for the Scrum Alliance and it was published on scrumalliance.org on September 28, 2009 http://www.scrumalliance.org/articles/132-scrum-in-old-fashioned-software-environments. Not that I think it is the best article ever written, but I had to think about it and it took me some time to write it.

Then, more than a year later, with the date of February 15, 2011, the same article showed up on scrumedge.com, a commercial website http://blog.scrumedge.com/2011/02/scrum-in-old-fashioned-software.html. The plagiarists of scrumedge.com just copied many of the Scrum Alliance articles to their websites' blog.

I wanted to find out, how this could have happened, and I asked scrumedge.com on May 16, 2011. I got no reply.

Then I thought, perhaps ScrumAlliance, who are holding the rights on my article, have made some money with selling the article to scrumedge.com. So on May 20, 2011, I asked ScrumAlliance, whether they know that their articles are re-used. The answer from the Managing Editor of ScrumAliance.org on May 23, 2011 was:

"Thank you for bringing this matter to our attention. I can assure you they re-printed your article (and the articles of several other members) without our permission. It is against our policy to allow other sites to use our content without express written consent and proper attribution. I have contacted the company and asked them to take down our articles and will follow up with our legal department, should it become necessary."

On June 6, 2011 I once again asked scrumedge.com to explain why they mis-used my article. Again, no reply.

On September 5, 2011 I complained to ScrumAlliance, that apparently they have been less successful in this issue. On the same day I got the reply from the Managing Director of ScrumAlliance that she "will send to legal for further follow-up".

Since then another five months have passed and the articles are still on scrumedge.com.

And now I'm asking myself questions like these:

• Is it really so easy to do self-service with information on the web?


• Do the people of scrumedge.com have the right mindset for the agile way of working, like openness and respect?

What are your thoughts on this?

Regards
Christoph

StoryMaps - Let's talk about it

OpenSpace Session at ALE2011 Unconference at 7 Sep 2011 in Berlin
Conveyor: Christoph Oberle, christoph.oberle@online.de, @OldAgile

Participants
Eelco Rustenburg, Yves Hanoulle, Arne Roock, Mads Troels Hansen, Alexis Monville, Rachel Davies, Marco Bontempi, Antti Kirjavainen, Claus Malten, Ivan Kostial, Michael Lausegger, Franck Depierre, Christoph Oberle and some other

Summary
At the Agile Lean Europe 2011 Unconference in Berlin in the Keynote of Rachel C. Davies she mentioned the concept of StoryMaps. To learn more about this I proposed a session for the Open Space titled “StoryMaps – Let’s talk about it!” In this session we learned a lot about this method to structure UserStories in more than one dimension and about the process, how to use it. In addition we shortly discussed the way to find the needed UserStories starting from the Vision, using Goals and Personas. The methods shown here are used in the community for a while, but apparently nobody has described them together until now. As a follow-up of this session a StoryMap example was given by Eelco in another OpenSpace session at ALE2011.

Two-Dimensional UserStory Splitting
Our first question was, who can tell, what StoryMaps look like.
They are two-dimensional arrangements of UserStories which somehow belong together.

Eelco presented this picture:

It shows the StoryMap for one bigger UserStory (or Epic). In the upper left corner the Epic is shown. In the horizontal dimension the decomposition of the Epic into functions is shown. So looking at the columns in the matrix, the Epic gets more and more “fully functional”, if you include more columns from left to right. In the vertical dimension the decomposition of the Epic according to some classification of the features is shown. E.g. the first row (or slice) could be named “working skeleton”. Here the UserStories for those features are shown which together define the minimum set to get a working prototype. The second slice could then be named “ready to go live”. Here those UserStories are put, that contain the features, which have to be added to the “working skeleton” to make it a shippable product increment. The third slice could be named “wow!” and contains those UserStories which would implement the exitors, the features which make the product competitive and exiting for the users.

With this decomposition of bigger UserStories into sets of smaller UserStories it is possible to get a common understanding about the functions, which are part of this bigger UserStory and about the features, which have to be part of the product increment. Especially the positioning on the vertical scale can be difficult and can be a fast method to surface different opinions about the need for some feature.

In the beginning of the development for an Epic the “working Skeleton” slice is the natural candidate for the first set of UserStories to be offered to the team by the PO. Then perhaps the “working skeleton” for another Epic plus some UserStories from the “ready to go live” slice of the first Epic can be offered to the team by the PO.

This means, after defining the StoryMaps for the Epics, the resulting UserStories are put into the (one-dimensional) Product Backlog (PBL) and prioritized by the PO.

This decomposition of bigger UserStories can be used whenever the size of a UserStory in the PBL is bigger than what can be handled in the sprint. After the decomposition, the resulting UserStories are put back into the PBL.








Silent Techniques for Positioning UserStories in the Map
To populate this two-dimensional representation with the UserStories silent techniques can be used (similar to the Magic Estimation method to estimate the size of UserStories, read here: http://campey.blogspot.com/2010/09/magic-estimation.html).

Example: For every function of the Epic the decomposition into UserStories according to features is done.

Then in a first phase of 1-2 minutes everyone puts his UserStories in the column of the described feature and chooses the row where he thinks the UserStory belongs. This is done silently without discussion.

In a second phase of 1-2 minutes everybody looks at the whole map and repositions those UserStories where he thinks they are not at their right position. The facilitator watches the process and sees, for which features a follow-up discussion is needed.

From Vision to Epics
The second question we discussed was “How do we find those Epics or bigger UserStories?”
What is the process to come from the Vision to the Epics?

Ulrika has drawn this picture:

At the top you see the vision. From this vision you define some goals that have to be reached and arrange it on the timeline (e.g. for the next quarters of a year).

The next step is to assign Personas to the goal and then find the UserStories which will reach the product goal for this Persona.

Those UserStories at the bottom of the picture can then be decomposed with the StoryMaps (see above).




Conclusion
We have got an overview about the concept of “StoryMaps”.

We agreed that it is a useful tool to have conversations about the decomposition of bigger UserStories with the stakeholders.

We have talked about methods for facilitation (silent techniques).

We put it into context with the process to create UserStories coming from the Vision.

We discussed the mapping from the (two-dimensional) StoryMaps into the (one-dimensional) Product Backlog.

It was a great session! Thank you for participating!

Addendum
In a private mail one of the participants told me about his experiences:

"... I could already use this approach with great success (means fruitful discussion). However we have used different dimension on Y axis, it worked very well - in our current situation the certainty (Clear, Clear BUT, To Be Clarified) was better description than releases.

What I find nice on this approach is the binding of user stories to certain features. Doing this one brings more information about the user story context without the need to write it down on every card. The whole discussion is than much more focused and always in particular feature context - not wild wide without end. :) ..."