I’m still on vacation but am at least online after two offline weeks in Crete. The photo is by my husband, Hakan, b t w.

For me, reading is essential to the ultimate vacation, and this is no exception. I’ve tried to stay away from software development literature, but I was not totally successful. When you’re working with something, I guess every book is somehow related to the subject. So, my head is packed with new interesting topics for this coming fall. And I’m starting off with the subject of risk. Is a risky project/task worth it?

A basic principle of agile is to try to get as much business value for the least resources. This would mean that you would pick story A of the following user stories:

Story Cost Business value A 10 10 B 20 10 C 10 5

But what happens if you take risk into consideration?

Story Cost Business value Risk A 10 10 10 B 10 20 20 C 10 5 30

What would you pick? A safer story with less business value or a riskier one with higher potential?

My basic instinct tells me to pick story A, and I’ve also felt somehow that the agile principles are backing me up on this. But would happen if we always pick the less risky stuff?

In Blue Ocean Strategy, W C Kim and R Maubourgne describes the differences between a red ocean and and a blue ocean when it comes to competitive situations and businesses. The principle is described very well in the current (July 2010) Wikipedia article, so feel free to take a detour if you prefer before going back here. To summarize; the red ocean is a business where the competition is dense and you need to fight for your position. If you have found a blue ocean, you’re competitors cannot truly compete with you. Of course, most blue oceans are temporary, but the successful organizations find new blue oceans when their current ones turn red. But what has this to do with my product backlog?

The answer is the question, in some ways, but you could also call it Innovation. How can you find a blue ocean? Well, it’s probably not by deselecting all the high risk items, is it?

David Andersson also points to this in his brilliant Agile Management for Software Engineering. If you’re shy of innovation, you will never be able to implement lean and agile values in a long term successful way. Implementing The Theory Of Constraints require a successful selection of both risky and non risky items. He also points at the importance of measuring the right stuff when it comes to high risk things: if you only measure the factual outcome, people will become shy of innovation and only pick the sure wins. This is probably the best way to stay in a red ocean. (And if you have not yet gotten this book, be sure to read it.)

But what are risky projects, items, tasks? It is very important to know why they are risky? Is it a risky technology? Are we unsure of the potential income? Are there special circumstances in the current project? David Andersson points at the importance of knowing WHY something is risky, but not deselecting for example all tasks with high technological risks. I’ve for example worked with a client who only worked with old versions of tools in order to lower the risk. Yes, the risks were lower but he lost out on innovation. But I’ve also worked with clients who ran for all new technology and had to be one of the first on all new versions. This is of course not good either. Now we’re not talking about risky user stories: we’re talking about misplaced focus. We won’t find the blue oceans because of new technology, but it can help us get there.

So, when my vacation is over in about two weeks, I will look differently at risk. Is there a potential blue ocean hiding there or can I get over another constraint while handling it? But now I’m heading back to my vacation.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Ein guter Teamleader hält sein Team immer bei Laune, ist doch klar! Und dank der Scrumlies wissen wir jetzt auch, wie man die Sache richtig angeht! ;-)

Das war nun Woche Vier der Summer School, Halbzeit also. Nächste Woche behandeln wir das Thema “Scrum & Vertragswesen” das wir am Montag mit einem spannenden Leitartikel von Marcus Antonius Hofmann, Rechtsanwalt aus München, einleiten werden.

Ein schönes Wochenende, wir sehen uns nächste Woche!

Today I invented a phrase (at least I think I invented it because I haven’t heard anyone else say it): “Avoidable Heroism.”

I invented it in response to a question, “Should my team work on the weekend to meet a commitment made under their control?”

Now, I don’t know the background behind this question. Maybe it’s perfectly reasonable for them to work on the weekend. Maybe they have no agreement about sustainable pace. And, it raises a few questions in my mind. How often does this happen? How far from the commitment are they? When was the first, best opportunity to re-negotiate the commitment? How did it slip by? What else is happening that affects their ability to commit and deliver?

Avoidable heroism happens on teams when the system pressures the team into committing to “stretch” iteration goals (rather than evidence-based goals) and someone (or more than one someone) has to work nights and weekends to meet the commitment.

Avoidable heroism occurs when unit test coverage goes down, team members focus on cranking out quantity of code rather than quality code and “forget” TDD, so that at a certain point a team member throws themselves on the technical debt grenade and begins to clear away the debris.

Avoidable heroism ensues when team members hand the new code to the testers on the last day of the iteration, rather than including them as part of the cross-functional teamwork from the first day.

And so on.

In the 1980’s (yes, I know that was before many of you were born), Tina Turner sang an anthem, “We don’t need another hero!”. Make it your own, your team anthem.

N.B.: I hope someone out there who’s into writing anti-patterns will collaborate with me on documenting this one.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Unser Kunde, ein bekanntes und erfolgreiches WEB 2.0-Unternehmen, sucht am Standort in Berlin einen Product Owner (m/w).

Verantwortung: Du bist für die Entwicklung eines Teilbereichs verantwortlich. Dabei nutzt Du Markt- und Nutzeranalysen, um tragfähige Produktkonzepte zu entwickeln und bisherige Funktionalitäten auf Basis interner Analysen kontinuierlich zu verbessern.

Du übernimmst die inhaltliche Führung eines dedizierten Entwicklungsteams, mit dem Du, der Scrum-Methodik folgend, neue Funktionalitäten für die Plattformen umsetzt. Du bist Ansprechpartner für externe Entwicklungspartner sowie interne Kunden aus den Bereichen Marketing, Sales und Software Development.

Du solltest sehr gutes technisches Fachwissen mitbringen und ganzheitlich am Social Media Phänomen interessiert sein.

Deine Kompetenzen und Erfahrungen:

• Abgeschlossenes Studium im wirtschaftlichen oder technischen Bereich
• Mind. 4 Jahre Erfahrung im Internet Product Management oder in einer Agentur ausgeprägtes technisches Verständnis, insbesondere zu Frontend-Themen
• Tiefes Verständnis von Business Modellen im Internet
• Sehr gute Kenntnisse gängiger Analyse-Tools und damit einhergehend ausgeprägte analytische hervorragende Kommunikationsfähigkeiten und diplomatisches Geschick
• Hohe Durchsetzungsfähigkeit sowie hohe Belastbarkeit Scrum-Erfahrung von absoluter Vorteil

Bei Interesse bitte melde dich bei André Häusling von www.scrumjobs.com: andre.haeusling@scrumjobs.com

Dieses Posting ist eine Anzeige.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Was macht eigentlich ein “gutes” d.h. effektives Team, z.B. ein Scrum-Team aus? Sicher sind es viele Faktoren, die vorhanden sein und zusammenspielen müssen. Ein wesentliches und erwünschtes Element “guter” Teams ist sicher das, was man allgemein als Teamgeist (manchmal auch Wir-Gefühl) bezeichnet. Teamgeist wird immer wieder regelrecht beschworen, und es wird an die Teams appelliert, doch (mehr) Teamgeist (im Sinne einer eher moralischen Kategorie) zu zeigen.

Jedoch, Teams haben keinen Geist, schon gar nicht in der Initialphase. Sie entwickeln, gestalten und pflegen ihn ganz handfest als permanenten Prozess und, wenn vorhanden, als positiv erlebtes, emotionales Phänomen. Teamgeist ist zum einen ein interner Zustand, der aus fundierter Kollegialität souveräner Individuen ent- und besteht.

Zentrale Basis für diesen erwünschten Prozess ist ein erfahrbares Wachsen von Wertschätzung, Respekt, Vertrauen, Zuverlässigkeit, Disziplin, Sicherheit und Aufeinander bezogen sein. Diese Teamgeist-Basis entwickelt sich durch gemeinsames Handeln, durch das gemeinsame Erbringen von Leistungen und konkreten Ergebnissen und zum zweiten durch dauerhafte kollektive und individuelle Erfolge und Erfolgsfeedback. Aber Achtung: oft wird dabei der individuelle Erfolg zu Gunsten des Teamerfolges geringer geschätzt oder bewertet.

Die Anerkennung individueller Leistungen und Erfolge im Rahmen der Teamleistung (durch die übrigen Teamkollegen) stärkt die individuelle Souveränität und damit die Komponenten Wertschätzung, Vertrauen ineinander und gegenseitiger Respekt. Im gemeinsamen Tun und Erfolgserleben realisieren sich Zugehörigkeitsgefühl, Zusammengehörigkeitsgefühl, Solidarität, Loyalität, Akzeptanz von Heterogenität, Dialogprozesse und Bereitschaft zu offener Auseinandersetzung und es gestalten sich Teamidentität und Teamgeist.

Teamgeist stabilisiert sich des Weiteren durch Zuschreibungen aus dem Team-Kontext.  Wenn einem Team direkt oder indirekt zurückgemeldet wird, dass es als spezifisches Team x/y wahrgenommen und erlebt wird, entsteht Identitätsfeedback. Dieses führt zur Klärung des Selbstbildes und zu einer für den Teamgeist zwingend notwendigen Grenzziehung nach außen. Laterale Teamführung, d.h. Teamführung ohne direkte disziplinarische Macht, sozusagen ”Führung von der Seite her”, unterstützt gezielt die beschriebenen Variablen zur Entwicklung von Teamgeist (z.b. im Daily Scrums, Retrospektiven, Impedimentprozessen, in der Kommunikation von Erfolgen nach außen, usw.) Sie macht Stolpersteine und Blockierungen für Teamgeist-Entwicklung (wie mangelnder Kontakt, zu wenig oder unangemessene  Kommunikation, nicht geklärte Konflikte, Egoismen, zu wenig Anerkennung, blindem Kollektivismus, etc.) transparent und unterstützt Teams dabei, sie gezielt zu bearbeiten.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

In der Woche über Leadership und Teams in Scrum eine ganz besondere Case Study. Der “Fall” ist in diesem Falle nämlich kalt. Diesmal nicht der aktuelle Blick auf die eigene Firma, sondern ein Resumee über Leasons Learned. Wir sprechen mit Jodok Batlogg über seine Erfahrungen mit Teams und Organisation als Leiter einer grossen Entwicklermannschaft, die mit ihm als CTO erfolgreich auf Scrum umgestiegen ist.

100728_case study jodok batlogg

Wir sind gespannt auf die Kommentare zu diesem Thema.
Trifft so agil denken  auch bei euch wunde Punkte?

Jodok, nochmal ein herzliches Danke für deine Zeit,
ich bin schon neugierig auf dein nächstes Wirkungsfeld!
Katrin Dietze, Hands on Design. Webteam

During last couple of years we have been talking a lot about agile as a whole and specifically about SCRUM, and how that help in offshore project environment to remove most the challenges introduced by the traditional waterfall environment.

While we were talking a lot about agile project concepts, engineering also has evolved a lot to support these concepts such as improved continuous integration and automated test process which eliminate most the problems of multiple team work integration and iterative releases, Cruise control's webpage which really help to get one good picture about all what's happening in multiple sites, New tools such as TFS, VS2010, and some opensource tools are also in high demand nowadays.

So obviously, We are on right track... agile is a way to go in off-shoring..the fact may hurt some of our offshore waterfall folks, but that's how it is.. one can argue that most the agile methods are good for collocated teams due to its concepts such as white board discussions, frequent meetups , open culture, transparency etc. .
After working with large offshore teams in India, Martin Fowler said "working offshore agile feel the pain much more than those using plan-driven approaches. But it's still less pain than the plan-driven methods themselves!" He said it best !

Agile is full of arguments......:-)You know that if you are a member of yahoo "Scrumdevelopment" group ;-). The latest arguments in agile world are mostly based on KANBAN.
If I explain simply, Kanban is a very lean approach to software project development. In SCRUM we said "we cut the waste". In Kanban we cut them big time. We see some agilists moving rapidly in to Kanban, but some are little conscious about the benefit it can bring in. Jeff Patton said in his blog "I'm seeing agile people behave as strangely about Kanban as traditional process folks behaved about Agile." Having said that, lets look at what Kanban will bring to all of us who are in the offshore project context. I will discuss few points here.

1. Scrum is all about time alerts – Kanban is all about event alerts.

In offshore/ distributed team context , the biggest challenge we have is to eliminate the isolation, get team members work closely with the remote teams, still have the onshore team commitment to meet up with the remote teams frequently even when they are distributed. SCRUM comes handy in this as it brings disciplines such as specific sprint planning meeting at the beginning of each sprint, daily scrum meetings (even via remote communication facilities) in every 24 hours, and retrospective after every sprint. So almost all are committed to participate these events.
But Kanban has more of a loosen up approach to it. Simply there is no time box approach, no sprint planning. They fix a limit for WIP stories. Kanban uses push and pull theory, when the WIP items becomes lesser they pull from the backlog and fill the stack.

kanban folks argue..why having daily meetings..? just raise your hand when you feel you are not in sync with your team.. lets meet up.. Why do you have to meet up daily and talk about what you have done yesterday what you will do today like a prayer. ..?
But we know in offshore context, this is not going to workout.. it will lead team mates to think.. ok .. Im having this issue.. but I may ask it later.. who knows whether my onshore mate is busy right now.. may be he is at another meeting.. this guy will pass hours, days…. And there are lots of unspoken issues stack up with the offshore guy to ask the onshore guy when the time is right..
from onshore perspective.. again we are inviting the same old problem.. lets just send him an email..or this guy keeps waiting without asking questions…At last all these tiny issues will become a big issue to the project.
About the retrospective, now we know we need to have a retrospective by end of 10 day sprint or so. But with Kanban, its again an event based thing.. if you see that you had a serious issue when testing, call the team and have a retrospective, why you need to wait till end of 10 days to have it.. hmmm..
However, most Kanban practitioners accept that this doesn't work so well even with collocated teams.. So they are also moving towards having daily meetings to talk about the bottlenecks and what they do today in front of the Kanban story display. Not based on the sprint plan.

2. Comparatively larger user stories.

When it comes to offshore – onshore engagements, requirement understanding is more challenging.. smaller user stories make the requirements more clearer and easier to elaborate upfront. But in the same time, the larger stories also has its own benefits such as easier designing, planning and to keep the product backlog in shape. But I would advise the teams to go for smaller user stories simply because that eliminates many risks in requirements especially with the challenges in distant communication.

3. Do not estimate – or at least pretend you don't estimate :-)

How will it work? Yes it can work in the perfect world. you are going to run 100 m., you have no idea how long you will take to run.. but you will run as fast as you can. In scrum what happens is that .. you run for 10 min and see how long you could run with your maximum speed. It's a time box. Dont raise your eyes.. Projects without estimations happen in real world too. I have an example with one of our current projects at Exilesoft. The team work with this model with a very close work relationship with its onshore team in Norway. It works very well with the trust they have built with our team sitting in Sri Lanka for over an year now. But this needs very capable resources, so much trust on remote teams and lots of commitment from the customer to work with its distributed teams. Without that, this will result major issues and pain in business.

4. Burn-down charts – do we really need them?

Kanban practitioners argue about the velocity used in many other agile methods such as scrum. Velocity measured based on story points burn down rates and sprint deliveries can lead to some conflicting ideas among the stakeholders as well as within the members of the same team. So they say.. Concentrate on cycle time of a story. that's what matters.

How do they do that.. its simple. Its about noting down the entry time of the Story X, and done time of the Story X. this difference will show you the waiting and the production time of a story in the queue. What needs to be done is to reduce this cycle time as the team improves with the technology and skills by removing the bottlenecks.

What I see with burn-down charts is that burn down charts with some meaningful annotations has a real good advantage in remote team environments to communicate the progress of the current work sprint as well as overall as a product how we go with the development. It provides high degree of transparency.

Overall I see Kanban will work well with some of the current maintenance projects we have. Working on a unplanned backlog, limiting WIP number, monitoring cycle time and less focus on estimation will work well with these projects.

However, I see that Kanban together with some scrum and XP disciplines will also be a good combination. Its all about trying out these methods in offshore environment and seen the benefits, drawbacks and improving your offshore-agile practices.

No.. Im not saying that agile is the magic pill which will flush out all the problems in offshore software development. That's what Dave and I are going to discuss at Agile 2o1o on 12th August (large scale and distributed agile. )
Our topic is simple and straight "Why you suck at off- shoring even with agile " see you guys there and lets have an interesting discussion.

Accept has invited me to participate in their webinar series on Transparency and Innovation – this Wednesday, July 28, 2010 (10AM Pacific, 1PM Eastern).

Join us and join in!

The Importance of Innovation and Transparency

Cool, huh? :)

Accept is hosting a free 5-part series on transparency, and has invited me to be one of their speakers.

The other speakers are rock stars – Nils Davis & Alex Lobba [replay available], Tom Grant, Roy Wildeman, and Brian Lawley.

Each of us will be looking at the importance of innovation and transparency from a different perspective.  Combine that with encouraged audience participation, and we should really be able to tease out some powerful ideas!

Join Us at 10AM Pacific on Wednesday, July 28th, 2010

I’ll be talking about how transparency (of the needs of your customers) affects the entire product creation team – not just product managers.  Register today for free, and I hope to get some great questions from you.

 

Thanks!

 

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Soziale Netzwerke wie Facebook, XING, Linkedin und StudiVZ sind entstanden, weil eine Handvoll Leute begonnen hat, eine Vision sehr schnell umzusetzen. Sie waren erfolgreich und sind gewachsen und gewachsen. Plötzlich stehen diese Organisationen im Spannungsfeld von traditionellem Management und innovativer Führung. Entstanden aus einer Idee und einem Impuls heraus waren sie sehr erfolgreich, haben Neues ausprobiert und dabei alle Regeln über Bord geworfen. Mark Zuckerberg (Facebook-Gründer) scheint sich an Regeln absolut gar nicht halten zu wollen, wie ich seine Äusserungen zum Thema Datenschutz interpretiere.

Sind die social networks erfolgreich und haben ihren ersten Proof of Concept erfolgreich hinter sich, dann kommen die Investoren. Mit Ihnen kommen dann die traditionellen Business-Regeln und mit ihnen die traditionellen Kontroll-Systeme. [1]

Plötzlich sehen sich die Menschen in diesen Organisationen mit einer neuen Anforderung konfrontiert: es wird erwartet, dass man plant und Erfolge garantiert. Die Firmenspitze muss sich nun vor ihren Investoren rechtfertigen.

Dabei ist das in einem Spiel, das niemand beherrscht, in einem Business, das es vor zehn Jahren noch gar nicht gab, mit Technologien, die von den Menschen in diesen Organisationen gerade erfunden werden, doch im Wahrheit vollkommen illusorisch.

Gelingt es diesem Druck zu entkommen – bei Facebook hatte Zuckerberg sich geweigert zu verkaufen und blieb selbst an der Spitze – schlägt das Pendel dann zu innovativer Führung aus. Ein Führungsstil, der nicht von jedem gemocht wird, ist dieser doch oft sehr diktatorisch. Doch der Vorteil liegt auf der Hand: Hier werden Dinge ausprobiert. Zuckerberg verzichtet auf Roadmaps und kreiert neue Paradigmen für seine Architektur. Einerseits liegt die Verantwortung so tief wie möglich, andererseits setzt er einige Dinge auch einfach durch.

Bei anderen sozialen Netzwerken, die nicht das Glück hatten den Investoren zu entgehen, schlägt das Pendel in Richtung traditionellem Management aus. Hier werden zwar Innovation gefordert, diese aber in Gremien und Lenkungsausschüssen kaputt geredet. Es werden mittlere Management-Ebenen eingezogen, konzernartige Strukturen geschaffen und klassisches Berichtswesen etabliert.

Das Problem ist also, so wie Dieter gestern schrieb, dass es Führung geben muss, soziale Netzwerke aber eine andere Form von Führung erfinden müssen, als es die klassischen Management-Methoden lehren, wollen sie weiterhin in der Lage sein, innovativ das Neue zu erfinden.

Gerade sie wären dazu ideal geeignet, denn sie sind aus dem Paradigma des Netzwerks entstanden. Sie haben die Infrastruktur erzeugt, die es benötigt, um kollaborativ über Distanzen hinweg zu arbeiten, haben dabei jedem Individuum im Netzwerk eine Stimme gegeben und Bewertungskriterien geschaffen, die es der Gemeinschaft erlaubt, den Einzelnen hervorzuheben und die Einzelleistung zu würdigen. Ihre Bewertungsmechanismen sind nicht hierarchisch und sie erzeugen Führung durch Gefolgschaft. So wird eine Page oder eine Person zu einen “Meinungs-Hub” und damit zu einem Führenden. Seth Godin nennt diese Leute die Begründer von Stämmen.

Wie sähe eine Vision für soziale Netzwerke aus?

Es müsste den Netzwerken gelingen, diese Mechanismen innerhalb ihrer eigenen Strukturen zu leben. Das könnte bedeuten, dass die neuen Features nicht von oben bestimmt werden, sondern sie von den Mitarbeitern und den Usern eingebracht werden. Welches Feature als nächstes käme, bestimmten dann die Mitarbeiter und sie würden sie, sähen sie realistisch aus, schnellstmöglich umsetzen und dem Netz aussetzen.

Wäre dieses Feature ein Erfolg, bliebe es im Netzwerk verfügbar, wenn nicht, dann baute man es später wieder aus. Würde dieses Feature so sehr nachgefragt, dass mehr und mehr Services dieses Feature benötigten, dann entschiede das Management ob es in die funktionale Social Network Plattform integriert würde. So führte die Firma die Community in die Richtung, die zur eigenen Vision und zur Community passt.

Leider ist die Realität eine andere. Die sozialen Netzwerke in Deutschland verlieren meiner Meinung nach ihre Innovationskraft. Sie werden zu sehr durch traditionelle Businessmodelle gebremst. Manager verlangen klare Roadmaps, Features sollen sich rechnen und dem Kunden soll das gebaut werden, was er verlangt. Team-Leader werden eingezogen, die ersten Hierarchien entstehen und Verantwortliche werden gesucht. Druck, nicht aus der Gruppe, sondern von oben wird erzeugt, denn nun müssen plötzlich Deadlines gehalten werden. Das Management beginnt Absprachen mit Managern zu treffen, ohne vorher mit denen zu reden, die es besser wissen. Entscheidungen werden zentral getroffen. Die sozialen Netzwerke werden intern zu etwas, was sie extern anprangern: eine langweilige, selbstgefällige, tayloristische Organisation.

Das kann man ändern und diese Bewegung aufhalten. Wir haben in den letzten drei Jahren gesehen, dass Firmen des frühen Internetzeitalters mit Scrum wieder die Fahrt aufnehmen können, die sie hatten, als sie begannen. Hier spreche ich von den großen Netzwerken und Portalen in Deutschland (alle namhaften deutschen Internet-Companies, setzen inzwischen auf Scrum – ob Facebook Scrum ausprobiert hat? Keine Ahnung!).

Scrum bietet den idealen Startschuss für jede Firma hin zu mehr netzwerk-orientiertem Arbeiten. Scrum bot diesen Firmen aber auch einen eleganten Ausweg, sie konnten diese Form des Arbeitens auf die Entwicklungsabteilungen beschränken. Warum eigentlich? Warum haben Grafiker, Produkt-Designer und wie sie alle heißen, eigentlich ein Problem damit, ihre Abteilungen auch dem Netzwerk-Gedanken zu unterwerfen und die Basis ihrer Existenz, das Netzwerk, im eigenen Unternehmen zu leben?

Ich habe darauf keine klare Antwort, aber eine Vermutung: Es geht wieder um Macht. Das Netzwerk löst jede Form von traditionellem Machtverständnis auf. In den meisten Firmen wird die IT als Dienstleister gesehen. Unterwerfe ich diesen Dienstleister einem System, das mehr Kontrolle bei gleichzeitigem Machtentzug verlangt, ist das eine gewaltiger Machtzuwachs. Selbst aber die eigene Stellung in einem Netzwerk zu hinterfragen, ist nicht nur unbequem, sondern erzeugt einen originären Machtverlust. Hier liegt die absolute Schwäche eines jeden netzwerkbasierten Ansatzes, also auch der von Scrum. Scrum ist out-of-the-box nicht in der Lage, dem mittleren Management einen Gewinn anzubieten, der den Machtverlust ausgleichen würde.

Firmen, die mit Scrum beginnen, müssen daher über Scrum “hinausdenken” und sich  mit ihren Strukturen ganzheitlich auseinandersetzen.

Morgen lesen wir, was uns Jodok Batlogg zum Thema Scrum und Social Networks erzählt. Freuen wir uns drauf.

[1] Google, liest man die Google Story richtig, ist diesem Dilemma entkommen, weil die Gründer von Anfang an zwar das Geld genommen haben, sich aber nie reinreden liesen.

[2] Niels Pfläging nennt die modernen Firmen in “Führen mit flexiblen Zielen” so.

Sometimes teams get stuck at the point of “deciding what to do” in retrospectives. Team members may begin to point fingers and describe things that the ubiquitous “they” must do before the team can move forward or make improvements,. This may lead to a team-as-victim, “poor us, we’re stuck” syndrome, or blame and finger-pointing. “It’s their fault we’re in this mess!” Blame kills retrospectives and the perception of persecution stalls any hope of forward motion, so the retrospective leader has to shift this conversation, and fast! Team members also may perceive so much room for improvement they become paralyzed and can’t decide where to start improving their lot.

When victim-talk, blaming or overwhelm surfaces, I reach into my retrospective leaders toolbox and pull out a technique to help teams identify the kinds of action the team can take. I draw three big concentric circles on a whiteboard or flip chart page, making the middle one as big as I can and leaving space wide enough for sticky notes in between each ring.

Label the middle circle “team controls”, label the next ring “team influences”, and
the third “The Soup”. I borrowed the useful concept of “The Soup” from David Schmalz, meaning all those elements of organizational climate & culture, policies & procedures, and other systemic factors in organizations that have become so embedded in “the way we do things around here” that the team has little hope of shifting them without considerable help and political will on someone’s part. (James Shore explores “The Soup” in a post.)

When I have prepared the chart, I explain that everything that affects the team falls into one of these categories, and every action they take also falls into one of three categories:

In the middle, they have control so they can take direct action.

In the next ring, they have influence, so their action would be a persuasive, influencing or recommending action.

In the last ring, they may have no control or influence, but they can choose actions for how to respond collectively when they find themselves swimming in the soup.

I share a couple of illustrating stories for this one.

I invite team members, in pairs, to write the issues and challenges the team faces on sticky notes – one per note, of course. When they’ve finished, pairs bring their notes to the chart and stick each note in the appropriate ring. As a next step, the whole team takes a step back to look at the completed chart and identify what kinds of actions they can take for each note: direct, influencing, response. This activity leads naturally into planning specific actions that will have the greatest beneficial impact. In early retrospectives, it’s more effective when the team takes on direct actions to remove impediments or create improvements within its control. When the team has experienced success with direct action, it becomes easier to develop plans for influencing actions for impediment removal or choosing actions in response to systemic constraints.

The Circles of Control & Influence activity helps the team sidestep the “someone should,” “if only they would,” “only those guys can” “we’re doomed!” conversations (which generally go nowhere), and shows individual team members that they have more scope for action if they act as a team.

(This technique was adapted from Stephen Covey’s book Seven Habits of Highly Effective People, also described by Jim Bullock as CircleofInfluenceAndConcern )

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Die Case Study über P/Mod in München hat eine tolle Diskussion über Störungen, während des Sprints ergeben. Es freut uns, dass ihr die Summer School so rege verfolgt. Diese Woche beginnen wir das Thema Teamführung zu beleuchten. Dieter schreibt im Leitartikel über Führung in Scrum Teams. Boris wird im Branchenbericht über Führung im Sozialen Netzwerken schreiben, unser Case Study wird den StudiVZ beleuchten und wie immer bringen wir weitere interessante Aspekte zum Thema am Donnerstag. Ich freu mich schon jetzt auf das Cartoon von unserem Cartoonisten Joachim am Freitag. Das letzte Cartoon in Anlehnung an die drei Affen war ein echtes Highlight.

“Teamführung in Projekten – vorgesetzt oder selbst gewählt?” von Dieter Rösner

Verfolgt man die politischen Prozesse seit der letzten Bundestagswahl 2009 in Deutschland, kann man ein faszinierendes Phänomen zum Thema Führung wahrnehmen: Von den Medien und anderen

“Experten” wird ein massives Führungsvakuum beklagt und die Führungsfunktion Nummer 1 – die Bundeskanzlerin – aufgefordert, “endlich Führung zu übernehmen”. Dies scheint aber irgendwie nicht zu gelingen.

Hier wird ein spezifisches Dilemma demokratischer Systeme deutlich: die starke Abhängigkeit der Führung von den Geführten, sprich den Wählern. Jede demokratisch gewählte Führung kann wieder abgewählt werden (und entnimmt den wöchentlichen Trendmeldungen ihre Einflussstärke). Daher ist sie mittelfristig bemüht, ihre Wähler “gnädig” zu stimmen (siehe Wahl in NRW) und verliert damit leicht die notwendige Führung aus den Augen. Wird aber nicht “gut” geführt, nimmt dies der Wähler auch wieder übel, und es kommt zu Vertrauensverlust und dem Abrutschen auf der Beliebtheitsskala, ganz zu schweigen vom Autoritätsverlust im Führungsteam (Regierung, siehe “Gurkentruppe, Chaosverein, Wildsau” etc.) – also ein echtes Dilemma politischer Führung in demokratischen Systemen. Ausgeglichen wird dieser “Schwachpunkt” durch das Agieren von Opposition, Medien usw., die hier als Regulativ wirken und größere “Katastrophen verhindern”.

Wo ist nun der Zusammengang dieser politischen Führungsthematik zu Teamführung bzw. lateraler Führung durch einen ScrumMaster?

Immer wieder wird die Frage aufgeworfen (z.B. auch in Scrum-Trainings), ob es nicht im Sinne von Selbstorganisation sinnvoller wäre, wenn sich Teams ihre Führung (oder den ScrumMaster) selbst wählen würden. Diese Frage ist m.E. mit einem klaren Nein zu beantworten.

Führung soll hier definiert werden als gezielte und legitimierte Einflussnahme auf Andere (Mitarbeiter) im Interesse eines übergeordneten Systems zu Bewältigung definierter Aufgaben und Leistungen. Eine gewählte Teamführung in diesem Sinne  kommt zwangsläufig in ein ähnliches Dilemma wie eine politisch-demokratische Führung, nämlich in starke Abhängigkeit von den Teammitgliedern. Die notwendige Führungsdistanz ist nicht oder nur bedingt zu gewährleisten und damit die Einflussnahme eingeschränkt. Es gibt keine legitimierten Regulative (siehe oben), die im Falle einer Führungskrise (z.B. Autoritäts- oder Vertrauensverlustes, Machtkonflikten usw.) die Situationen im Sinne des übergeordneten Systems gezielt und kompetent klären können. Beobachtbare Phänomene sind dann Chaotisierung, Verwahrlosung, Leistungsabfall, Auflösung.

Ein vom Management vorgesetzter Teamleiter (ScrumMaster) hat eine legitimierte Positionsmacht, ist nicht direkt abhängig vom Team (obwohl Teil desselben) und kann damit distanzierter Führung übernehmen und den situativ notwendigen Einfluss ausüben. Bei kritischen Teamsituationen sind die hierarchischen Interventionen der “Einsetzer” der Teamleitung das Regulativ, das im Interesse das Systems problemlösend handelt (oder handeln sollte). Zum Beispiel durch Stärkung der Leitung, Moderation oder durch Ändern der personellen Situation.

Vor- bzw. eingesetzten Teamleitern ist zu empfehlen, ihre Funktion und ihren Status  selbstbewusst zu vertreten und kein “schlechtes Gewissen” zu haben, auch in diesem Falle sind sie ein genuiner Teile der Selbstorganisation des Teams. Den Einsetzern ist zu empfehlen, sich ihrer Rolle als Regulativ bewusst zu sein und bei Bedarf gezielt und kompetent zu intervenieren.

I learned this week that I made the Top Women in Business Blogging list. They tell me my readers nominated me. Dear readers, thank you!
Online MBA Rankings

Tweet This Post

I'll be giving a Certified Scrum Master for Game Development course on November 2-3 in San Francisco before the IGDA Leadership Forum.

This two-day course provides the fundamental principles of Scrum through hands-on experience and interactive project simulation. During the course, attendees will learn why such a seemingly simple process as Scrum can have such profound effects on an organization.

Attendees learn to apply practical, project-proven practices that have worked for numerous video game projects

• The essentials of getting a project off on the right foot
• How to build a product backlog and plan releases
• How to help both new and experienced teams be more successful
• How to successfully scale Scrum to large, multi-continent projects with team sizes in the hundreds
• How to help producers, artists, designers and programmers work together effectively
• How to work with publishers and others outside the team who may not be familiar with Scrum
• Tips and tricks from an instructor with 15 years of game development experience, 7 years of experience applying Scrum to game development author of the book Agile Game Development with Scrum.

Participants who successfully complete the course and follow-up test, will become Certified ScrumMasters through the Scrum Alliance and receive a two-year membership in the organization where additional ScrumMaster-only material and information are available.

Registration
The course is being held just prior to the Leadership Forum on November 2nd & 3rd at the Airport Marriott (same location as the Forum).  Pricing details and registration can be found here.

More details for the course material can be found here.

Any questions? Contact me!

I’ve been working with Rebecca Wirfs-Brock on an agile architecture workshop. I’m working with Rebecca because she has such a depth of experience in architecture, as well as design. She’s working with me because of my project and program management experience. We’re pretty psyched.

We’re working through the issues of large programs and architecture, and, of course, we have encountered the develop by component vs. develop by feature debate. I’m closer to the develop by feature side of the house than Rebecca. She’s a little closer to the develop by component side. We’re not too far apart–we’re not polar–we’re not precisely at the same place. And, we may never be at the same place, because our experiences are different. We each have good reasons.

You get tremendous benefits when you develop by component: high cohesion in the component and low coupling between components. Don’t underestimate the value of these. If you don’t pay attention to cohesion and coupling, eventually you can’t develop anything.

When you develop by feature, you get features. It’s hard to underestimate the value of working product.

But especially in a large system effort, with multiple teams, how do you do this right? Of course, it depends. You might have a combination of teams, in my preference after you have a little experience with some features. Maybe you develop some prototypes. Maybe you do something else.

We’re developing a simulation for the workshop. If you have encountered this problem in your system, please post a comment and let me know if you would like a simulation to explore this. (I am not under the impression this means you would commit to our workshop!) If you’d like to send me private email, that’s great too. We’re trying to develop a simulation that will mimic what happens at work.

Tweet This Post

I’m attending Agile 2010. Are you?

If you’re serious about adopting, grounding, or extending Agile mental models, values, principles, methods, and practices where you work, you’ll find answers to your current concerns, and stimulate new questions to consider, at Agile 2010. With 214 sessions ranging across 5 days and 16 thematic stages, you’re sure to find many colleagues who face similar challenges.

In Open Jam, the self-organizing area of the conference, you’ll find thought leaders whose deep curiosity and desire to learn leads them to sit with you and explore your situation. You’ll also find peers and colleagues who have been there and want to share their experience with you. You’ll have the opportunity to share your experiences with them as well. I’ll spend quite a lot of my time in Open Jam. Please look for me there and say, “hi!” Who knows, we may have a lot to talk about.

If you’re looking for outside support, you’ll find that too, among many sponsors and exhibitors who eagerly await the chance to discuss their approaches, services, tools and products with you.

Among the sessions on the “Building High Performance Teams” stage, you’ll find our FutureWorks Consulting session. (We’re proud to have been selected as the competition was fierce among nearly a thousand compelling submissions.) Sharon and I have developed a new presentation for the conference on a topic of critical importance to effective collaboration and team functioning: “Trust, Authenticity & Forgiveness: Workplaces Where People Thrive & Produce,”. I look forward to sharing it with you on Tuesday afternoon, August 10, from 1:30-3:00 pm.

Take advantage of this once-a-year opportunity to experience all the “tribes” of the Agile community coming together in Orlando, Florida, USA, August 9-13. Register now! If you’re involved in adopting or implementing agile in your organization, you can’t afford to miss it.

Diana

P.S. Sorry. You’ve missed Super Early Bird and Early Bird rates. The good news: there’s still time to save over 10% by registering with a Group Pack of 5. See you in Orlando!

Seth Godin is one of the most famous bloggers around and has authored numerous books on the subject of marketing.
I just ran into this old post of his, 'Ads are the new tip jar'. It's an interesting, but controversial concept.
At first the idea certainly appealed.
Bloggers, like myself, spend a lot of time writing unique content and promoting it, usually for little financial reward but because bloggers are sharers; people who get genuine pleasure from sharing knowledge and opinion, and helping others.
Advertisers are fighting for attention. The attention deficit, in this age of information overload, is a real problem for producers of content and advertisers alike.
Google say you mustn't ask people to click on your ads. It's strictly against their policy. But what if you ask, "Please click on my ads, but only if they're potentially of interest and relevant to you"? Isn't that what advertisers want?
In a follow-up post, "Beating the status quo", Seth apologises, but defends his original post which came under quite a bit of criticism.
Even in the world I work in, large media companies have similar problems with the monetisation of online content. Rupert Murdoch of News Corp (the world's second largest media conglomerate) is tackling the problem head-on (see 'Murdoch on Leading the Charging Charge').
At 79 years old, and with a net worth of about $6bn, I think it's amazing that he still has the energy to fight this battle for his companies. His views on the subject of paying for content have been well publicised and we are just about to see whether or not people are willing to pay, at least for news, as he puts up his pay wall on The Times web site.
The world's media companies, and perhaps even bloggers, are watching with baited breath to see what happens. If he's successful, it could change the economy of the internet forever. Or will people simply go elsewhere?
Kelly.

I just finished leading an in-house Scrum Product Owner course with a group of 6 actual or future product owners. One of their most pressing issues was what to do when the team does not meet its commitment. "My Team regularly commits to 20 points, then only delivers 10. What can I do?"

We briefly discussed the alternatives of shooting, firing or otherwise punishing team members for not meeting their commitment, but quickly came to the realization that such measures are likely to be counterproductive. If the team fears the consequences of not meeting a commitment, it will be very cautious about making those commitments.

Here are eight strategies for achieving the sprint goal:

1. Yesterday's Weather

If the team finished three backlog items ("stories") for a total of 10 points in the last sprint, then that is a good place to start for the next sprint. As a product owner, only accept a commitment to 10 points. As a team, only offer to take on 10 points. If the team runs out of work, it can always go back to the product owner and ask for more.

2. Smaller Stories

The larger the backlog item, the higher the complexity and the higher the risk. By breaking the story down into smaller stories, you decrease the risk of each individual story. If 3 of 6 stories go South, the Team has a problem, if the team does not succeed on 3 of 20, it's not such a big deal.

Current recommendations suggest that a team should commit to 10 to 20 stories per sprint. For two week sprint with 6 people on the team, that means each story (backlog entry) will need, on the average, about 3 to 6 Person-days to complete.

Reminder: each story must meet the INVEST criteria and have an acceptance test associated with it.

3. Prioritize large stories higher

Even if you are aggressively breaking down stories, some will be bigger than others. It's dangerous to have big, low priority items. When the team starts the story, the sprint should be nearing its end, so the story may not fit. Get the big ones out of the way first, then do the smaller ones.

4. Defend against Scope Creep

A common problem in the sprint is discovering "new" requirements during the course of the sprint. (Product owner says, "check our requirements document, chapter 4.1.3 for the details." Chapter 4.1.3 is where the skeletons are hiding. No-one has really studied the implications of 4.1.3 and it will surely have surprises which cause the effort to rise.

I have found the following strategy to be useful: The story has precedence over the requirements doc. It represents the instructions for this sprint, which is should create a small piece of the entire product. If I stumble on a requirement which is not clearly part of the story, I report that to the product owner, who then decides what to do with the "new" requirement (in backlog or not, prioritized high or low), and I continue to implement the story as previously agreed.

How do you identify what is in the story and what not? Two components define the story: 1) its title 2) how do demonstrate it to the Product Owner at the end of the sprint. If the functionality in question is needed to make the title happen and is visible in the 'how to demo' workflow, then it is part of the story, otherwise not.

Even if title is not a correctly formatted user story, the story should be a complete sentence. For example:

• Good: As a job hunter, I want to send my resume with my job application so that....
• OK: Send resume with job application.
• Much room for improvement: Attach resume.

The second component is "how to demo." This is a simple work-flow which the team will use to demonstrate the story and that they have met the requirements on the story, for instance: 1) chose a want-ad, 2) select "Apply," 3) select "Attach resume," 4), pick file from dialog 5) upload, 6) Send. At there very latest, Team and product Owner should agree on this work-flow during the Sprint Planning.

So the team is working on this story, reads chapter 4.1.3, and discovers 'E-Mails should be signed with PGP to assure authenticity." Sounds like a great, trust building requirement. Is it part of this story? No! There is nothing about digital signing, neither in the title nor in the 'how to demo'. Report this to the PO who can create and prioritize a new story, if appropriate.

5. Strict Prioritization

The backlog items are prioritized in the Product Backlog. This prioritization is carried over into the sprint backlog. A simple approach is to consider the top story 'Must have' and everything else 'Nice to have' until the top story is finished. The team members should always focus on getting the top story finished before looking at issues further down the priority list.

6. Early Acceptance

There is no rule which says the Product Owner must wait until the Sprint Review before definitively accepting a story. If the story is done after three days, then ask the product owner to accept it right away. This smooths out his workload and reduces the uncertainty on how many stories have been accepted.

7. Swarming / Pairing

Consider a team with 4 people, 4 stories each estimated at 10 days each, a 2 week sprint (10 working days), and in which each team member takes on 1 story and works on it large by himself. On the 9th day, each story is 90% done.

How many stories will be done at the end of the sprint? Hard to say. Getting stories done usually means coordinating with other people: a code review, an independent test, acceptance by the Product Owner. This can become a tremendous bottleneck and it is possible that no stories get finished, even if the work on each really was 90% done. The situation gets worse if the stories were underestimated. They don't need 10 days to finish, but 13. At the end of the sprint, nothing is finished and the burn-down chart remains unchanged.

Let us assume that this team applied Strict Prioritization and the entire team worked on one story at a time and that this did not affect the working time needed to complete the story. The first story would finish after 3 days, the second after 6, the third after 9 days. At the end of the sprint, the team has taken 30 points off the backlog. Not the 40 they had hoped, but better than the zero achieved with everybody working on their own story.

Can a team -- and in particular your team -- really apply swarming? Only one way to find out: Try it on a story or two and see how it works. More widely practiced is pairing, in which two team members work on a story together. This is almost always useful, because it stimulates knowledge sharing and prevents becoming too dependent on a single team member.

8. Throttling

The Product Owner cannot and should not tell the team to pair or swarm. But the P-O can still influence this process. Let us assume the team has 6 members. If the product owner only asks for 3 stories (sized according to the guidelines above), then the team is forced to ask themselves, 'How can we work together to solve this problem?'

I recommend this approach to teams that are just getting started, in combination with a few weeks of one week sprints. This helps them learn to do Scrum quickly and to work as a team effectively.

These strategies have worked for me. What other strategies do you use to help your team achieve its commitment at the end of each sprint?

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Auch die Scrumlies wissen, wie man gut im Team kooperiert: indem man Kommunikation groß schreibt … Und es dabei belässt :-)
Und jeder macht was er will, keiner macht, was er soll, aber alle machen mit.

Das war also nun die Summer School Woche 3 zum Thema “Kommunikation und Moderation”.

In der nächsten Woche beschäftigen wir uns mit Teamführung und Teamentwicklung. Der Leitartikel am Montag stellt die Frage, ob ein Teamleader von seinem Team gewählt oder ihm vorgesetzt werden sollte. Wir sind schon auf eure Meinungen dazu gespannt…

I’m proud and pleased to be on the list of LiquidPlanner’s Top Project Management Thinkers. I’m thrilled, too!

Tweet This Post

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Nach 3 Tagen rings um Medien und Kommunikation, nun die Case Study diese Woche – Scrum bei den Experten für (Marken)Kommunikation.

Die Münchner Agentur P//MOD – ein Ableger der renomierten Agentur Publicis, die sich vor allem mit digitalen Medien befasst, arbeitet seit nunmehr fast einem Jahr mit Scrum.

Klar, nicht so einfach, schliesslich kennt man Anwendungsbeispiele von Scrum viel eher aus der Softwarebranche. Dennoch funktioniert Scrum auch hier sehr erfolgreich. General Manager Joel Flammann hat sich trotz dichtem Terminplans auf einer morgendlichen Autofahrt viel Zeit für ein ausführliches Gespräch genommen – wie ich finde, wirklich aufschlussreich. Ein Muss für alle, die glauben, Scrum ist eben “bloß” der Gegensatz zu Waterfall in der Softwareentwicklung. Irrtum. Lesen!  100721_casestudy pmod münchen

Nochmal herzlichen Dank!
Katrin Dietze
Hands on Design. Webteam