When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them.

Whenever I use John Deere as an example of a fantastic Agile adoption, I always get looks of surprise. That’s quickly followed by an ‘a-ha’ moment when I share that today’s

From my visit to the test farm in Des Moines - note all of the hardware on top of the tractors

tractors are run by more lines of code than the early space shuttles. Yesterday, ComputerWorld published a great article about John Deere’s Agile adoption, characterized as a ‘big bang’ across their 800-person development organization within a year. It’s definitely worth the 5 minute read.

By 2050, there will be 9 billion people on the Earth.

In 50 years, the world population will require 100% more food. Seventy percent of that food is expected to come from efficiency-improving technology. John Deere considers these their user stories, and they strive to use technology to help solve these global problems. If the ComputerWorld article is worth 5 minutes of your time, then Chad Holdorf’s in-depth talk is worth every bit of 25 minutes to hear John Deere’s bigger vision and how they inspire teams to tackle it at John Deere.

You can work with John Deere too.

I’ve been honored to work with Tony Thelen, director of John Deere’s Intelligent Solutions Group, and Chad Holdorf, their Agile Coach, throughout this transformation. And I share their passion for connecting engineers to solve these potentially disastrous problems. I’d like nothing more than to see some smart folks go to work for John Deere.

With my son in a John Deere plow.

Tractors and Agile? Absolutely. I can’t think of a better example of how software is shaping the world we live in – every single day. Congratulations Tony and Chad and best of luck on your social mission.

Ryan Martens is founder and CTO of Rally Software, a hopeful Citizen Engineer and a recovering Entrepreneur-in-Residence at the Unreasonable Institute. You can follow him on Twitter @RallyOn.

Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who cleans the table and loads the dishwasher. Any of us can do that job. We do not, however, rotate who cooks dinner. My wife is a far better cook than anyone else in the family. We want the cooking to be the best it can be, so we don’t rotate that job. If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster.

However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster.

Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.

With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team’s self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (The Agile Marathon in the Proceedings of Agile 2006)

So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:

• Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.
• It’s hard to train enough people to do the role well.
• Some people will use their time as ScrumMaster to try to push through changes to the process.
• Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

This video tells the story of a project that was in a bad shape after a first waterfall attempt and 2 months of Scrum that failed to deliver any working code. This talk shares the technical practices adopted and how they evolved but mainly focuses on what it took to make the project work in a big organisation with the typical command-and-control mindset It discuss attitude and culture of people on the team and how our values worked against the values exhibited by other teams. Video Producer: http://agilece.com/

<Adapted from my article in CM Crossroads article titled, “Making Beautiful Music Together”>

Have you ever watched a jazz combo? The performance starts with the leader counting off the rhythm, then stepping away. Then the drummer begins to lay down a beat. Even at this stage, the audience can feel a groove hit the room. Soon, the piano joins and adds both melody and harmony to the piece. Energy is flowing from the chords as the team starts to see and feel the direction of the piece. Now it’s time for the other instruments to join in the fun. A typical combo will have a couple of different instruments, maybe a sax and a trombone or some other combination. Whoever starts off will state the melodic theme for the song, although sometimes the whole group does this together. After that, everyone gets the chance to do a solo, in which they improvise on the main theme, key off of past experiences and apply their musical knowledge. It’s not uncommon for jazz musicians to jibe each other, making jokes and comments while they are playing. The energy in the room builds and builds as the musicians play together, sometimes one at a time, sometimes in tandem. When you watch a jazz combo really swinging, it can be hard to tell who his having more fun – the audience or the musicians.

This metaphor works quite well to understand what makes a small team desirable, and how to be successful with such a team.  In the agile software community, we have asserted over and over again that we need small, cross-functional teams. And yet, what really is cross-functional? Can cross-functional really work? The more traditional view of software creation involves the need for separate, functionally focused teams who are experts in their domain. The teams only interact as they are passing work items from one to the other. When development is done, the teams hand off work to test. Test will find defects and hand them back to development. And the dance continues in this light forever.  The jazz model demonstrates that this can, in fact, work.

In a jazz combo, each member of the team has a specialty. The members play individually, but often together  they create a tapestry of music that becomes much greater than the sum of the individual contributions. A small development team works best this way. We have some set of programmers, testers, documentation specialists and some representative of the business working together. Team members gain their energy from each other. They try new things and get feedback right away from anyone who wishes to listen and share.

The team members don’t need to just focus on their own areas either. A tester can very easily and effectively form a duet with a programmer. They will play off of each other with their ideas. The tester will write a test to express some piece of functionality that the software will have. Then the programmer will answer with the code that will cause the test to pass. So we write another test based on this back and forth interaction. In music this interaction is known as “call and answer,” and it is especially effective with the testing and programming cycle, as it provides a rapid, tight feedback loop.  Communication is instantaneous, allowing for more freedom of action. More often than not, a programmer will pair with another programmer. This duet is very effective and powerful as well.  The programmers can build off of each other’s knowledge; ideas that might “seem like a good idea at the time” are instantly reviewed by a peer.  This type of pairing turns code review from an intermittent, reactive process into a continuous, proactive activity, and should be embraced as often as possible.

Let’s explore some of the roles that are important in a development team. Usually there’s some sort of coach or leader. In the Scrum world, you might hear about the ScrumMaster. Each of these names is meant to describe someone who is both a part of, and to some extent outside of, the team itself; in a jazz combo, this is the director’s role. Not every combo has a director, but many do. Sometimes that director is part of the team, only directing long enough to initiate and introduce a number to the audience. In software development, the director represents the team to the stakeholders, and helps plan the meetings, stand-ups, and the like – essentially counting off the beat. If the rhythm seems to be getting lost, the director can help the team identify this fact and help with corrective actions.

A team also needs an individual who has the ability to identify what needs to be developed. In agile development, this role belongs to the product owner. Now consider a jazz combo’s basic rhythm section… The drummer lays out the shape of what is to develop; the bass takes this one step further, presenting the progression of chords that identify the order in which the chords (which make up the actual harmonies and melodies) will be played. Lastly, the piano comes in with the rich, fully realized chords. Accordingly, the product owner has to play all three roles of the rhythm section, explicitly: identifying the work to be done or the shape of the upcoming work. Ordering the work in order of priority sets the rhythm.  Elaborating the story in terms of acceptance criteria provides the chord structure. And lastly, the constant interaction with the team throughout the development cycle provides the fulfillment of the intention as laid down by the acceptance criteria previously mentioned.

In Part 2 of this post (coming Monday, 1/30), I’ll talk about what other roles are integral to every agile development team and explain how keeping the teams small and cross-functional makes it easier to react to change.

Pour démarrer rapidement avec iceScrum dans le but de le tester, une façon simple est d’installer le « bundle » (il y a encore plus simple : allez sur iceScrum Cloud).

Pré-requis :

• Machine Virtuelle Java (JVM) 1.6 ou supérieure : JDK installée, avec les variables JAVA_HOME ou JAVA_JRE présentes et indiquant le chemin (vers la JDK pour JAVA_HOME)
• Navigateurs internet : InternetExplorer 7+, Firefox 3+, Safari 3+, Chrome

Installation :

1. Téléchargez la dernière version du bundle.
2. Décompressez-le dans le dossier de votre choix.
3. Ouvrez ce dossier.
4. Dans le fichier config.properties, changez : grails.serverURL = http://[url_to_icescrum]/[context_name] (par défaut c’est http://localhost:8080/icescrum)
   
5. Exécutez le fichier « start.bat » sous Windows ou lancez « start.sh »  dans un terminal sous Unix/Linux (et Mac). Vérifiez les droits d’exécution (sous Unix, faire un chmod u+x *.sh dans les répertoires bundle et bundle/server/bin) et l’ouverture du port 8080.
6. Dans votre navigateur, tapez l’URL : http://[host_adress]/[web-app] (par exemple, http://localhost:8080/icescrum).
7. Il ne vous reste plus qu’à vous enregistrer : cliquez sur le bouton « S’enregistrer », remplissez le formulaire et validez. Vous pouvez maintenant créer un projet.

L’utilisation du bundle ne constitue pas une installation pérenne, elle doit être réservée à des fins de test.

Veuillez noter que l’utilisateur lançant le serveur Tomcat doit posséder les droits d’écriture sur dossier Tomcat.

Pré-requis

• Machine Virtuelle Java (JVM) 1.6 ou supérieure,
• Serveur d’application web Java compatible servlet 2.4.
• Navigateur : InternetExplorer 7+, Firefox 3+, Safari 3+, Chrome
• L’installation d’une Base de données n’est plus indispensable, iceScrum est maintenant livré par défaut avec une utilisation de HSQLDB (un gestionnaire de BD Java, sur fichiers)

Recommandations

• Votre conteneur web devra bénéficier d’une bonne quantité d’allocation mémoire pour iceScrum : au moins 512 Mo.
• Ajoutez au minimum ces options de paramétrage de la JVM (variable d’environnement JAVA_OPTS) : -Xmx512M -XX:MaxPermSize=512M.

Installation

1. Téléchargez la dernière version du WAR sur le site.
2. Copiez le WAR dans le répertoire racine <web-apps> de votre conteneur ou utilisez l’outil d’administration de votre serveur d’application pour réaliser le déploiement du WAR.
3. Dans le fichier config.properties, changez : grails.serverURL = http://[url_to_icescrum]/[context_name] (par défaut c’est http://localhost:8080/icescrum)
   
4. Dans le cas d’un serveur Tomcat, modifiez votre fichier server.xml de manière à ce que le connecteur catalina possède la configuration suivante :
   
   <Connector port= »8080″ protocol= »org.apache.coyote.http11.Http11NioProtocol »

   			   connectionTimeout="2000"
   			   maxThreads="500"
                  URIEncoding="UTF-8"/>

5. (FACULTATIF) Si votre conteneur est « récent » (Tomcat6, Glassfish, …), il se peut qu’il inclut des librairies utilisées dans le WAR. Dans ce cas, supprimez les fichiers suivants à l’intérieur du WAR (en utilisant un utilitaire d’archives ou en les supprimant du répertoire de déploiement) : el-ri.jar, el-api.jar, jsf-api.jar, jsf-impl.jar, myfaces-api.jar, myfaces-impl.jar
6. Démarrez votre serveur
7. Dans votre navigateur, tapez l’URL : http://[host_adress]/[web-app] (par exemple, http://localhost:8080/icescrum).
8. Il ne vous reste plus qu’à vous enregistrer : cliquez sur le bouton « S’enregistrer », remplissez le formulaire et validez. Vous pouvez maintenant créer un projet.

                                                                                                                            By Dominica DeGrandis The number of #kanban tweets continues to grow with the expansion of kanban use in areas outside of software development.  From the classroom to Portfolio Mgmt, we look at some examples this week. News According to HashTracking.com, Twitter hashtag “#kanban” generated 70,130 impressions, reaching an audience of 52,009 followers from 97 tweets within the past 24 hours (Jan.25, 2012).  Also displayed are the top ten peeps by number of tweets, followers and impressions.  Makes for interesting data points. Here’s a fun read about Kanban in the classroom with preschoolers.  If the teacher gets sidetracked, the kids remind her of the task she missed. http://blog.leankitkanban.com/2012/01/guest-post-using-kanban-in-the-classroom/ Jim Collins new book, Great by Choice, is a study on winning behavior when confronted by uncertainty.  Collins compares companies that win with companies that languish.  It’s a terrific read from a Kanban practitioner’s perspective due to the uncanny parallels between the behavior of winners and key Kanban concepts for coping with risk.  I was so intrigued; I wrote a blog post on it. http://agilemanagement.net/index.php/Blog/how_do_teams_continue_to_win_during_times_of_turmoil_and_uncertainty/ There’s been a lot of talk lately on Kanban for Portfolio Mgmt. Here’s a post on Kanban for Customer Portfolio Mgmt showing the board layout with Swift Kanban.  Intangible tasks are on a separate board which in some ways sounds appealing, but I’m wondering how they visualize priority between business tasks and intangible tasks. http://www.valueinnova.com/?q=content/kanban-customer-portfolio-management Events The Inaugural Cynefin, Agile & Lean Mashup (CALM) – London, UK Feb 16 -17, 2012 http://calm.eventbrite.com/ Agile and Beyond Conference - Dearborn, MI.  March 10, 2012 http://agileandbeyond.org/ Lean Kanban Southern Europe - Madrid, May 9-10, 2012 http://lkse12.leanssc.org/ Lean Software Systems Conference – Boston May 2012 http://lssc12.leanssc.org/program/   #mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block.   We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ Subscribe to Weekly Kanban Roundup Please contact dominica@djaa.com with questions.

The Gist of the Story We believe in Agile software development for teams. From small teams to a 4000 person development group, our clients have enjoyed success with Agile. They have been able to deliver more value to customers at a more sustainable pace and with greater employee satisfaction than ever they were before. That is what keeps us going. We believe in Agile in all its flavors:...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all.
Manage Both the Big Vision and the Small Batches

Keeping a balance between the development of product qualities that will fulfill the business case and the tactical execution of low-level features is perhaps the most important skill possessed by a Product Owner. The difficulty in simultaneously doing both of these things well often leads to an actual split in the role, where a “Strategic” or “Chief” Product Owner focuses on the big picture, and the “Tactical” or “Proxy” Product Owner works with individual teams attending to the details of execution. Tools like story mapping, product trees and personas are commonly applied at the big picture level by Strategic POs, while sketches, wireframes, process flows and various collaborative modeling techniques are generally employed by Tactical POs to help teams better understand and execute the details.
Strategic product ownership is focused on garnering feedback and testing the project's assumptions at the vision and business case level, while tactical product ownership should align the whole team against small batches of work within sprints to ensure the best execution possible at the detailed level.
Test the Project’s Assumptions
Business cases are often presented as foregone conclusions: Build the features, and they will come. However, there is no shortage of failed and unloved products to prove that this is nonsense. Projects are built upon more or less educated guesses of what the market and stakeholders need and desire, and it is the Product Owner’s job to test and refine these assumptions, thereby guiding change through objective data.
Techniques such as customer development in the "Lean Startup" approach focus on stating your assumptions in such a way that they can be tested, and then using feedback from these tests to adjust the project’s focus. The simple process of coming up with metrics that represent the product’s desired qualities and impact areas also can be of tremendous help when attempting to balance diverse needs across disharmonious stakeholders, as it forces a focus on overall project needs rather than individual features. In essence, the why must precede the how.
Use the Whole Team
When Scrum was first formulated, a joke cast the “team” as committed “pigs” while the Product Owner (along with general stakeholders) was dubbed a merely involved “chicken.” This is an unfortunate place to draw the line, because these two roles work best as a tight-knit partnership. Scrum teams already play an active role in design and feature elaboration, and the best products come from fully engaged teams, not ones that simply wait for their orders or ones design in a vacuum.
Collaborative modeling techniques, where designs are created and refined by small groups rather than individuals, are common in such environments. Finding the right balance between giving the team a “final, approved” design to develop vs. involving them deeply in the design process itself isn’t automatic or consistent across teams, but it is the only way to maximize both the efficiencies so often touted in Agile methods with product innovation, effectiveness and quality.
I hope you've found this post useful. If you have any other questions about how to be an effective Scrum Product Owner, share them in the comments and I'll do my best to answer all of them in future posts.
Subscribe to RSS Feed

TestLodge recently announced their latest feature that allows Assembla users to link their accounts to TestLodge's test case management tools. This integration makes many essential software testing features available to Assembla users without having to manually enter data for their tests and bug tickets multiple times. TestLodge created this custom integration using Assembla's REST API.

This first iteration from TestLodge offers the following features:
 

• Automatically create tickets in Assembla in the background when a test fails. Each ticket includes a description and steps to replicate, along with the expected result and actual result.
• Optionally, choose who the Assembla ticket should be assigned to, and set the priority.
• Associate an Assembla project workspace with a TestLodge project.
• View a test report that provides links to all created tickets.

About TestLodge TestLodge is a relatively new hosted tool that is designed to be a lot simpler than the traditional test management software by providing only the essentials to get the job done well. The system focuses on helping you create your test plans, input your requirements, create and manage your test suites & cases, and allow you to easily perform multiple test runs & generate reports.
Special offer As an introductory offer, TestLodge is offering a 20% discount for a limited time to anyone who makes use of the new Assembla integration. Simply sign up for your TestLodge account, then email TestLodge about the discount within a week of signing up.

Quitting smoking is one of the easiest or the hardest things that a person can do. For some who are not obsessed with smoking, quitting can be a cinch. For other, quitting can be like driving on a highway to misery and depression that smoking seems to be the only thing that keeps them alive and kicking.

This is why nowadays, there are a lot of people who are using electronic cigarette starter kits to get their daily dose of smokes without causing a long-term problem with their health and well-being. An electronic cigarette kit is a small device set that you can assemble and would somehow resemble a cigarette. It has all of the physical attributes of a cigarette, without the health risks that you can get from a conventional smoke.

However, just like any other electronic devices, it takes a good eye and a good sense of judgement to pick out an effective electronic cigarette kit that will make you eventually quit smoking for good. These devices should be treated with the same respect and the critical understanding of any other electronic device or gadget so that you will not miss your dose of nicotine and your habit while restoring your overall health.

Choosing your Kit

When you light up a cigarette, it’s just simple and quick; you get your cigarette, light up the butt of the cigarette with a match, a lighter or any other device and you can start puffing away. Smoking is a simple and pleasurable process for some people, which is why they take it in the first place.

Yet, it’s a different thing altogether when it comes to working with an electronic cigarette kit. You have to screw the filter to the cartridge and puff so that the device will activate. For some kits, it goes a little more complicated than that.

The bottom line then for choosing your starter kit is to choose the simplest one that you can find. If you find a cigarette kit that resembles almost the same habit as you would when smoking in a conventional manner, the more likely that you are going to stick with it and that quitting is a possibility for you. You can then have the chance of quitting more in a simpler form of an electronic cigarette than with one that has a lot of spare parts and small pieces that can go missing.

Purchasing your Kit and Pricing

There is no definite price when it comes to an electronic cigarette kit. There are expensive ones that can go for hundreds of pounds, while there are others that can be as cheap as a carton of cigarettes. Therefore, pricing is just a matter of preference and being resourceful. Just pick out the kit that has the best price for your budget.

As you can see, it’s not hard to buy an electronic cigarette kit. All you need to remember is that you can always go for the option of using the kit instead of smoking so that you can have a healthy life ahead of you, without becoming victim to the long-term problems of cigarette smoking.

Example 2: Using a Project Manager with Kanban, Silo’d Teams

This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.

This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.

The New York developers had a problem biting off more than they could chew. So nothing moved across their board. The Italy developers had a board where the work did move across the board. The teams took pictures of their boards every day and shared the work across a project-based wiki. That allowed the New York-based developers to see the work move across the Italy board. And, that encouraged the New Yorkers to call the Italians and ask some questions. That helped the New Yorkers to change the size of their work by working with the product owners.

Now, why did the New Yorkers have such trouble originally? Because the developers “knew better” than the product owners, so they changed the stories into architectural features when they had originally received them. (Now they don’t. They leave the stories as real stories.)

Release planning: Management in California plan with agile roadmaps. They have features planned specifically week-by-week for the next 6 weeks, and have more of a quarter-by-quarter approach after that.

Iteration planning: No iteration planning because they are using kanban.

Daily commitment: No daily commitment needed because they use kanban. They do have a checkin a few times a week with each other as a technical team to make sure they don’t create bottlenecks and that they respect the WIP (work in progress) limits.

At one point, both the New York and Italy developer teams created automated tests so that the testers could catch up and stay caught up with regression tests. They add a story like that every couple of weeks, and they are paying down their automated testing debt.

The Project manager keeps an eye on the WIP, work in progress. Project manager also shepherds the product owner into keeping the queue of incoming work full and properly ranked. The product owner is notorious for changing the incoming work queue all the time. Project manager makes sure the team does retrospectives and is a little unclear how to do them in such a distributed team. The project manager is not so sure their retrospectives are working, and has started an obstacle list, to make sure the team has transparency for their obstacles.

Measurements: cumulative flow, average time to release a feature into the product.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

The new version v6.50 of freeware tool Sprintometer for Scrum and XP project management has been released on Jabuary 21, 2012. Everybody knows Sprint Burn down chart used in Scrum projects but very often managers need to know situation with the whole agile project and specifically they are interested in Project Burn down chart. New version of Sprintometer allows this! How it works: go to tab called ‘Scope Chart’ on project level and enter percentage for already estimated sprints in relation to the whole project scope. Sprintometer will automatically generate Burn down ...

My PMI-ACP Book is coming along nicely and today RMC released some more content including sample questions and walked through explanations of the answers. Visit the RMC Site to access it and also sign up for future previews and special... Mike Griffiths

A widespread myth I've noticed in Agile software development is, No documentation in Agile or Documentation is wasted effort. Particularly during a transition from Waterfall to Agile, we appreciate the benefits of adopting typical Scrum practices, such as short iterations, timeboxing, daily scrums, retrospective, and so on. We also try to get away from the tasks and activities that we found monotonous before Agile adoption documentation, writing proper code comments, etc. But is it really correct to completely stop documentation and code comments?

I was at home a couple of Sundays ago, watching a Chelsea vs. Liverpool football match (soccer, for those Americans reading) a match Liverpool ultimately won. It was during the post-match analysis that I was struck by some parallels between what Chelsea is going through and my own current client engagement to move from Waterfall to Scrum.

I was at home a couple of Sundays ago, watching a Chelsea vs. Liverpool football match (soccer, for those Americans reading) a match Liverpool ultimately won. It was during the post-match analysis that I was struck by some parallels between what Chelsea is going through and my own current client engagement to move from Waterfall to Scrum.

I've always wondered -- not just as a developer but as a human being -- why I needed to follow the orthodox methods of typical hierarchical reporting. There was always some middle man confusing the conversation. You can define many roles in a typical hierarchical organization, and

Es kann nicht oft genug gesagt werden: Natürlich ist Scrum ein Framework, um Organisationen, Product Development und Team zu managen und zu führen. Selbstverständlich kann ein Framework nicht Lösungen für jede Organisation, jede Abteilung oder jedes Team haben. Selbstverständlich muss jede Organisation best practices entwickeln, die nur in ihrem Kontext funktionieren. Die besten Beispiele dazu sind die Firmen, die heute nach Jahren sehr erfolgreich mit Scrum, KANBAN oder anderen agilen Methoden und Ideen sind.
Doch den ersten Schritt vor dem zweiten zu tun, also die Anpassung vor der Meisterschaft der eigentlichen Ideen ist meist, nein immer verkehrt. Ein Kind lernt auch nicht das Rennen, Springen, Klettern bevor es das Krabbeln, das Stehen, das vorsichtige wackelige Gehen und dann das sichere Laufen meistert. Das dauert – und ist mit etlichen Fehlschlägen bezahlt. Fehlschläge, die oft wehtun, die frustrieren und die das Kind immer weiter bringen.

Habt ihr mal Eltern beobachtet, die dabei zusehen, wie ihre Kinder laufen lernen? Wenn nicht, sucht euch einmal ein Elternpaar, das ein 8 Monate altes Kind hat oder geht in eine Krabbelstube und schaut zu. Es ist sehr faszinierend zu sehen, dass diese Eltern nicht ein einziges Mal sagen werden: „Oh du bist zu blöd zum Laufen, das wird nie etwas. Du musst das so oder so machen. Wieso hast du denn den Fuß nicht nachgezogen? Jetzt schau aber mal her, ich zeig dir, wie es geht.“ Meistens hört man doch: „Bravo! Das machst du toll. Ja so geht’s. Man, hab ich dich lieb.“
Sie stehen da, freuen sich über jeden noch so kleinen Schritt und sie sind da, wenn das Kind fällt, nehmen es in den Arm und trösten es. Was sie auch tun: Sie sichern ab, sie geben dem Kind Halt, sie geben ihm einen Rahmen, sie passen auf, dass das Kind nicht zu nahe an der Treppe übt, räumen die Tischdecke weg, damit das Geschirr nicht mit runterkippt. Sie umsorgen, aber sie lehren nicht.

Positive Verstärkung bis zum Abwinken. Es ist schon manchmal peinlich anzuschauen. Als gäbe es nichts Wichtigeres auf der Welt. Ganz ehrlich, einige übertreiben es, aber … es ist POSITIV!

Eigentlich merkwürdig. Sind die Kinder im Vorschulalter und sollen malen, zeichnen oder schreiben lernen, ist es mit dieser Art des Umsorgens, des Förderns, des Daseins für Kinder vorbei. Plötzlich wird vorgemacht, ermahnt, gedroht, gestraft und von der positiven Verstärkung ist nicht mehr viel übrig geblieben. Ich bin sicher kein Einzelfall gewesen. Bei mir war das Diktate üben: Horror! (1)

Natürlich ist Laufenlernen etwas, das Kinder instinktiv machen. Sie lernen, dass sie zu etwas hingelangen, wenn sie sich auf den Weg machen. Eltern bestärken sie. Aber dass sie wirklich Laufen lernen, ist nicht gesagt. Ich habe als Kindergärtner während meiner Zivildienstzeit mit Kindern gearbeitet, die über den Boden robbend genauso schnell ein Ziel erreichen konnten, wie jene Kinder, die laufen konnten. Es ging auch gar nicht anders, denn diese Kinder hatten entweder körperliche Gebrechen oder waren einfach zu dick. Sie bekamen ihren Hintern nicht hoch. Es dauerte fast 12 Monate, bis die Muskeln stark genug waren. Tägliches Training – ja, da mussten Therapeuten helfen.

Scrum ist Hausverstand – den wir verloren haben

Wie ist das mit Scrum – geht das instinktiv? Nein! Wir haben zwar die Veranlagung, aber die Instinkte, die uns dazu führen würden, unsere angeborenen Strukturen auszubilden, werden durch Erziehung, Sozialisation, Kultur und Organisationen unterdrückt. Wir beginnen sofort, uns verbogen zu verhalten. So wie es Menschen gibt, die künstlichen Orangensaft dem geschmacklich eindeutig spannenderen Naturprodukt vorziehen, so haben wir verlernt, unseren anthropologischen Eigenschaften zu folgen.

Scrum und seine best practices sind, wie Ken immer sagte, “common sense”. Gerade den müssen wir aber erst zurückgewinnen. Wir müssen wieder lernen, dass frischer Orangensaft besser schmeckt als das Industrieprodukt.

Das geht nur, indem wir uns auf den Weg machen und dabei verstehen, dass das Erlernen neuer Fähigkeiten nur durch üben, üben und nochmals üben erreicht wird. So wie das Kleinkind über Jahre zum Meister des Laufens wird und irgendwann überhaupt nicht mehr darüber nachdenkt, dass es nicht laufen könnte. Dieses Lernen gelingt Erwachsenen aber oft nur, wenn sie verstehen, dass sie sich in einem Stufenprozess des Lernens befinden. In der agilen Community war es meines Wissens Alistair Cockburn, der als Erster den Begriff des ShuHaRi in unserer Bewegung einführte: Dieser Begriff kommt ursprünglich aus den japanischen Kampfkünsten, z.B. Aikido.(2) Dort herrscht das Prinzip Shu-Ha-Ri. Dieser Begriff besteht aus drei Silben, bei der jede für eine Phase des Lernens von Aikido steht. “Laut Masayuki Shimabukuro ist “Shu-Ha-Ri” wie ein Kreis in einem Kreis in einem Kreis.” (3)

1. Die erste Phase, Shu, ist das genaue Nachmachen der Kampfbewegungen wie der Meister sie lehrt. Dabei wird vom Schüler die Korrektur durch den Meister dankbar angenommen und akzeptiert. Im Gegenzug schützt der Meister seine Schüler und motiviert sie zum weiteren Lernen, das die Basis für die zweite Stufe, Ha, ist.
2. In der zweiten Lernstufe Ha versteht der Schüler die Hintergründe der Regeln und Techniken und beginnt mit kleinen Anpassungen und Veränderungen.
3. In der letzten Stufe dem Ri ist der Schüler nicht länger Schüler, sondern wird selbst zur Regel. Er beherrscht die hohe Kunst und kann seine Fähigkeiten nutzen und situativ anpassen. Er ist selbst zum Meister geworden und stellt seine eigenen Regeln auf.

“Wie der Meister sie lehrt” – Selbstverständlich weiß der Meister, dass es unzählige andere Wege gibt, den Gegner zu bezwingen und dennoch entschließt er sich, dem Schüler nur eine Weise beizubringen. Genau das ist der Ansatz, den wir beispielsweise vorgeben, wenn wir Scrum bei Kunden einführen. Wir geben eine Art vor, das Sprint Planning durchzuführen. Eine Weise vor, das Daily Scrum zu machen und so weiter. Das schafft auf der einen Seite zwar eine Einschränkung, auf der anderen Seite führt es aber auch zu Sicherheit. Es führt zum Erfolg, weil der Scrum Coach oder auch ScrumMaster weiß: “So wird es sicher funktionieren.”

Die Aufgabe des ScrumMasters und des Scrum Coaches ist es dann, dafür zu sorgen, dass das Team diese kleinen Erfolge hat und diese sofort durch “Bravo!” zu verstärken. Er muss dafür sorgen, dass sein Team sofort POSITIVE Verstärkung bekommen kann. Wer dazu einen sehr bekannten Text lesen will, dem sei das erste Buch der One Minute Manager Reihe empfohlen.

Wer in Wien ist und Lust hat, mit mir mal diese Praxis vollkommen gefahrlos zu üben und sich nicht scheut dreckig zu werden, den lade ich ein, mit mir sonntags eines meiner Pferde zu versorgen. Da kann man zusehen, wie positive Verstärkung zu Erfolgen führt. Da sieht man wie Lernen im Zeitraffer-Tempo funktioniert. (4)

(1) „Young children do not have motivation problems. (…) We never see a 2-year-old who is depressed about how his talking progress is going on and so has decided to quit trying to improve. (…) But at age 6, all this changes. Children try to avoid having to learn, they fear failure, their educational goals are to please authority or do less work. (…) What has happened? The 6-year old has started school.” (Schank 1993/1994, p. 430) aus der Vorlesung “Pädagogische Psychologie” von Prof. Fischer LMU

(2) Alistair Cockburn (2000): Agile Software Development

Die Quellen darin sind:

• Kuroda, Ichitaro: “Shu-Ha-Ri” ;Sempo Spring 1994 pp 9-10.
• McCarthy, Patrick: “The World Within Karate & Kinjo Hiroshi”; Journal of Asian Martial Arts. V. 3 No. 2 1994.
• Private conversations with Nakamura, L. Sensei, Toronto, Spring 1994.

(3) Zitat und Abbildung Shu-Ha-Ri aus http://www.aikido-blog.de/shu-ha-ri-die-lernstufen-im-budo-aikido/

(4) Wer darüber noch mehr lernen will. Dem empfehle ich “Gregory Bateson: Ökologie des Geistes.”

 

Related posts:

1. Schuldzuweisungen verhindern Lernen
2. Hellseherei – oder die Planung des Unplanbaren
3. Scrum Alliance mal wieder führungslos – Donna Farmer geht