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.

Once again we are going to Kiev for Agile Eastern Europe Conference which will run this Autumn (8-9th October). Last edition was a great event and we expect this year to be even better. It’s enough to look at the speakers lineup, to be sure that Agile Eastern Europe once again will become a really international event:

• Mary POPPENDIECK (USA)
• Henrik KNIBERG (Sweden)
• Danko KOVATCH (Israel)
• Marc LOFFLER (Germany)
• Paul KLIPP (Poland)
• Anda ABRAMOVICI & Sudhindra RAO (USA)
• Robert DEMPSEY (USA)
• Vasco DUARTE (Finland)
• J.B. (Joe) RAINSBERGER (Canada)
• Mack ADAMS (Canada/France)
• Robin DYMOND (Canada/USA)
• Yves HANOULLE (Belgium/France)
• Monika KONIECZNY (Poland)
• Andrea HECK & Tibor VIDA (Germany & Hungary)
• Allan KELLY (UK)
• Dr. Johannes MAINUSCH (Germany)
• Sergey DMITRIEV (Norway)
• Piotr ZOLNIEREK (Poland)
• Sergei ANDRZEEVSKI (Russian Federation)
• Andrea PROVAGLIO (Italy)
• Pawel LIPINSKI (Poland)
• Nikita FILLIPOV (Russian Federation)
• Pavel GABRIEL (Belarus)
• Artem SERDYUK (Ukraine)
• Mikalai ALIMENKAU (Ukraine)
• Timofey YEVGRASHYN (Ukraine)
• Michael NORTON (USA)
• Pawel BRODZINSKI (Poland)
• Francois BACHMANN (Switzerland)
• Jurgen APPELO (Netherlands)
• Zsolt ZSUFFA (Hungary)
• Gwyn MORFEY & Laurie YOUNG (UK)

We are proud to be once again to support the conference as a Bronze Sponsor, so if you use tinyPM, think about using it, want to talk about the tool, it’s capabilities and your need, then Kiev will definitely be a place where you can push us to the wall and ask all the hard questions.

If you haven’t decided yet to come, go on and REGISTER now!

• Tweet This!
• Post on Google Buzz
• Add this to DZone
• Share this on Facebook
• Share this on Reddit
• Digg this!
• Share this on LinkedIn
• Share this on Technorati
• Share this on del.icio.us
• Share this on FriendFeed
• Add this to Mister Wong
• Submit this to Netvibes
• Add this to Ning
• Stumble upon something good? Share it on StumbleUpon
• Add this to Wykop!

It's fast, it's fun.  It powers your planning.  It tames your tickets.  It's the upgraded Agile Planner, our AJAX interface for adding tickets, building stories with tasks, and scheduling them into milestones, iterations, or releases.  For more details, please watch the video, or just select the “Agile Planner” link in the Tickets tool menu, and try it.

During the last year, many users have told me that they use the agile planner every week with their team.  So what is NEW in the Agile Planner this month? 

* It’s fast.  Drag and drop is smooth.  All tickets are loaded into local memory for instant access.  New layouts for “Milestone | Detail” and “Story | Detail” remove EVERY CLICK between mousover and seeing the detail edit form.

* Open tasks and subtasks to unlimited depth, in the Story/Feature column.  This “hierarchical ticket view” was one of our most requested features, with over 300 votes.

* Enter a list of tasks with the same attributes, using a new pop-up UI.

* In-place editing of estimates.  Just click on the number and edit.  The estimates add up correctly for complete features or milestones.

Incremental development is important

The Agile planner will help you with roadmapping, which I described in my article "Save the best for first".  It's a simple way to get what you want, fast, using incremental development.  We write down everything we want to do, and then we sort it by priority, and we try to find the minimum set of high-priority stuff that will get us a great release as soon as possible. 

A whole industry has grown up around incremental development, represented by Agile, minimum releasable product, lean startups, and even behemoths like Linux, which started as a student project. 

Sometimes, a planning view can be one of the biggest obstacles to this process.  If you write a view of your project that shows a feature listed under a milestone or release, and subtasks for that feature, it starts to force you into thinking that you need to finish everything before you can release.  You start to forget that you are in charge, and that you can release a simple version before you release the complete version.  In the Agile Planner, we separate the your grand plan in the Story/Feature view, from the schedule in the Milestones view.

How can you use the Agile Planner?

Use it with a client or business owner to launch a project.  It’s fun to see a plan take shape, which builds the relationship.  If you run a good roadmapping session, you get a big head start on the implementation, which is the biggest revenue earner. 

Use it with your team to plan iterations.  Many Assembla users sit down as a group with the agile planner each week or each month.  I have seen distributed teams do this with screen sharing tools.

Distribute planning.  I like to create a top-level story, and then ask the developer to fill in more detailed tasks.  It makes the developer feel more confident, and it makes the work more visible.

Many of our users like to sort their tasks into a very specific order.  Agile Planner gives you that control.

 

Here's a quick video of the Agile Planner, so you can see it in action.

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.

There appears to have been a data center outage early morning, affecting a number of applications including Pivotal Tracker. This has caused connectivity problems for users in some locations, and it appears to still be persisting for some.

We're working with our hosting provider to get this resolved as soon as possible, this is our top priority.

This is the second data center outage this week. At the moment, we do not have enough information to know whether the outages are related.

Also, we have received reports that Tracker has been unreachable from certain parts of the world (including China) since the migration to a new data center last week. We've filed a request with Engine Yard to investigate, and hope to have this resolved soon.

Our apologies for the inconvenience these outages have caused. We'll post more information here as we receive it. You can also follow @pivotaltracker on Twitter for updates.

By Steve Miller

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile. This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

Team Composition

Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).

With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

• Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the Product Manager, CTO, in some cases the CEO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product. Before a sprint begins, the Product Owner communicates the goal of the sprint to the team and what features should be analyzed for the release. This does not mean that all the desired features will make it into the sprint, the team estimates and prioritizes items for the sprint (during the Sprint Planning sessions), and only the items that can fit in the sprint are done.
• ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspections happen, and ensuring everyone plays by the rules. The ScrumMaster coordinates and runs the daily sprint meetings. The ScrumMaster is not a task master, they are a leader that empowers the team members to deliver the assigned tasks and to help eliminate roadblocks that slow them down.
• The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation. The Team is responsible for staying focused on assigned tasks, soliciting help as they encounter road blocks, fully testing their code, refactoring code, logging their time daily (including estimated time remaining on each task), and for checking their code daily or more often if possible.

Our Experiences with Team Composition

In our experience, it is unrealistic to assume that The Team can handle quality assurance and documentation well. We have improved the team composition to include 2 additional roles:

• Software Quality Engineer - This individual is responsible for the quality of the sprint. In our experience, programmers do not test code with the same mentality as a Software Quality Engineer (SQE). Once specific requirements are defined, the SQE develops a set of test cases (manual or automated) to test each requirement fully. Before coding begins, the test cases are made available to the programmers on the team. The programmers are expected to run each test case before marking coding as being complete. Once a requirement is marked as being complete, the SQE is responsible for running the test cases again to ensure they all pass. The SQE also runs a weekly regression to ensure that legacy features are not compromised by the release. If the SQE has developed automated test cases for regression, those are run daily or more frequently, if needed. The SQE does not wait until the end of the sprint to begin testing, they test once a requirement is completed. By the end of the sprint, all testing has been done and regression has been run frequently.
• Documentation Specialist - The Documentation Specialist (DS) is responsible for creating User Guides, Administrator Guides and other training materials. In our experience, programmers do not always have the written communication skills to write documentation in a way that a laymen can interpret it, that is why it is important to have a separate resource for this function. Once a requirement has been fully tested by the SQE, the DS begins the documentation of that requirement. The DS does not wait until the end of the sprint to begin this, the end of the sprint includes all completed documentation.

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.

The folks at AlertGrid posted an article with instructions for configuring Assembla to send SMS messages to your phone whenver something important happens. They asked "Can Assembla send me SMS message when new milestone is created?" Yes, it can.

The key ingredients are

• the Assembla Webhooks tool, which will send events from the activity stream to other applications.  You select the type of events that you want to send (for example, code commits, ticket comments, or new/edited milestones).  Then, you configure the URL to get or post the information.
• The AlertGrid service.  AlertGrid will not only send you an SMS, but it will compare the incoming messages to workflow rules, and send the correct message to the correct people.  So, this adds an extra layer of intelligence to the notification process that you can use to filter out noise and find the most important events.

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.

The story of how using Scrum helped one team complete a project outside the world of software with a minimal budget, almost no direction, and even less time.

Ah, Marketing.  Enter a world of countless project requests, numerous stakeholders, limited resources and rapidly changing market conditions.

Sound familiar?  In fact, marketers face a lot of the same challenges as development teams, and Agile can be a powerful way to alleviate those common issues and intelligently plan our work.

In steps 1-5, I’ll explain how Rally’s marketing team conducts our version of Release Planning.  In steps 6-10, I’ll explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, though this method has worked for awhile now.

10 Steps to Successful Marketing using Agile and Lean Practices

1. We recognize that Marketing has challenges that are different from Development.

• There is no unique product owner.  For example, if we chose Sales, then we would always rank lead generation over branding, customer programs or analyst relations, and that could ultimately hurt our company. Therefore we have to use some best-guessing to prioritize our backlog and determine what is most important.
• We face hard event deadlines set far into the future.  Sometimes we have no choice but to commit to an event or sign a contract months ahead of time.
• Each team member has unique expertise, i.e. writing, event planning, PHP development and so forth.  So one shared backlog is inefficient.

Now that we’ve reviewed the challenges, we give ourselves permission to do what we need to do, have patience and adjust anything that isn’t working for us.

2. Conduct an ORID to learn from the past

Before planning for the next quarter, we hold a retrospective in the form of an ORID, “a means to analyze facts and feelings, to ask about implications and to make decisions intelligently”, a process created by the Institute of Cultural Affairs.  We gather as a team to share:

• Observations (O) – What do we know?
• Reflections (R) – How do we feel about this?
• Interpretations (I) – What does it mean for the organization?
• Decisions (D) – What are we going to do?

This strategic overview helps set context for us to prioritize our focus for next quarter.

3. Align ORID decisions with company strategy

At Rally, we conduct quarterly and annual planning using the Plan Do Check Adjust methodology as explained in Getting the Right Things Done.   As we look at the overall company direction and goals, we keep these in mind as we hold planning at our own level.   Ideally, our major commitments support and align with company strategy. This also helps inform our “stop doing” list.

4. Poll our stakeholders

As part of determining quarterly commitments, we poll our major stakeholders for their top requests.  We use a Google survey to rank these requests by importance, size each request and bring these epics into our release planning meeting, to be included as part of our ranked backlog.

5. Conduct Release Planning to prioritize and agree on quarterly commitments

Now that we have all of our inputs, we hold our quarterly Release Planning session.  We write each epic on a sticky note and look at all of the possible work we could do this quarter.  Then, we evaluate epics based on importance taking company goals, stakeholder wishes, market realities like conferences and our own passions into consideration. We decide what we can realistically commit to, and agree as a team.  We keep in mind that making and meeting commitments is a huge deal, and we try really hard not to over-commit.

Part 2 – Meet our Marketing Commitments

6. Create a task board

Since our marketing team is mostly co-located, we pin up several large sheets of paper to use as a task board.  This is where we review our commitments on a daily basis as a sanity check that our stories are prioritized correctly and that we are tackling the right work as the quarter progresses.

As a team, we write our quarterly commitments on the task board with the definition of done assigned to each one.  We also include our “foundational” work – recurring work like website updates, online ad campaigns, field events, press releases and other important work that we need time to do.

Note: this is not a Kanban board because we do not have a shared backlog nor do we have a team-wide WIP limit.  As we break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.

7. Hold iteration planning every 2 weeks

Every 2 weeks, we hold an Iteration Planning meeting.  Each team member has her own sticky note color, creates stories on those notes and manages her own prioritized backlog using T-shirt sizing to roughly estimate each story.  In this hour-long meeting, we begin by expressing appreciation for team members who gave exceptional assistance.  Then we hold a brief retrospective on what worked and what should change for the next iteration.  Finally, we each read out our prioritized stories for the iteration, putting them on the task board’s backlog.  This gives everyone visibility to what’s happening, identifies if someone is over-committed and lets the team swarm any epics with looming deadlines.

8. Conduct a daily stand-up

At the same time each day, we hold a stand-up meeting (with a consistent conference call #) that is at most 10-15 minutes long.  We form a semi-circle in front of our task board and share no more than 2 cross-cutting significant actions or take-aways from the day before, no more than 2 that we are planning to accomplish that day, and whether our work is blocked by any issues beyond our control.   As we start working on stories throughout the iteration, we move them from the backlog into their section of the task board to show what we are working on.  When the story is complete, then we move it to a place on the task board labeled “Done”.  Once the commitment’s Definition of Done is met, we check off that commitment and feel good about completing it.

9. Be patient as things change

It would be lovely if nothing changed during the iteration, but that just doesn’t happen.  The goal is ultimately to respond to change rather than cling to an outdated plan.  As new opportunities arise, new time-sensitive information appears and new requests are made, so our iteration work changes and that’s ok.  We try to just document what we’re working on and create new stories so that we can make intelligent prioritization decisions during the course of the iteration.

10. Retrospect, inspect and adapt

As we keep running our iterations and fulfilling our commitments, we are always looking for ways to improve them.   Ultimately, we’re using Agile to improve the quality of our work life by using objective, smart ways of planning how we spend our time. And we’re learning a lot from the journey.

by Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment? The London Scrum Groups 6 Good Scrum Tips

• Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
• Run Retrospectives. Its very important to take actions away from a retrospective.  Be realistic though, your never going to solve them all, so ask the team to priorities them.  If your doing the retrospective right your product owner will be there to help with prioritization.  If you find something very big lands at the top, split it down into stories.  Otherwise pick one or two that the team feel strongly about and turn them into stories.  Make sure these stories are included in the next game planning sessions and make it into the iterations.  If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time.  Commit to doing them and then deliver.
• Ask your team to Pair Code. The XP technique of two programmers working on the same task.  It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput.  Don’t be dogmatic, let the team decide how much work should be pair coded.
• Setup Self Directed teams. Self directed teams have been proven to be more efficient.  We discussed the role of a scrum master in a self directed team.  Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks.  The scrum master does not plan or allocate tasks.  The empowered team needs to work out what the tasks are and find out how to finish the stories.  The scrum master should spend his efforts removing blocks for the team, checking quality.  Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed.  We also decided that to be empowered you need to make the team multi discipline.  Include testers, user interface designers etc to remove hand off waste and increase team knowledge.  With role diversity comes better decision making.
• Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.  Delivering builds trust in the team and the process.  Classic ways to miss delivery include: Failing to produce a strong definition of done.  The definition should include the programming, integration, testing and setup tasks.  In fact everything required to get that task ready for delivery.  Another way to miss delivers is to fail to demonstrate at the end of the iteration.  You may think your done, but when the product owner sees the work for the first time they may request refinement.  If you have kept your product owner close then the demo is likely to be painless.  No power-point slides please, only real working software in the demo!  So commit and then deliver what you commit to.
• Co-locate your team. The group defined co-location quite tightly.  Co-location is not putting everyone in the same office.  Its putting the team members next to each other in the same space.  Intra team communication does not happen with the team scattered around an office.  You should be able to turn around and join the stand up meeting.  This closeness, speeds up the myriad of tiny important messages that pass around the team.  Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea.  If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightened, well fed and slightly merry.  Why not come along to the next one, we could use your input.

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.

Below is an excerpt from an email response I sent someone asking me about Kanban and Scrum and what they should do to determine which is more appropriate for their teams. This is just my personal opinion on this subject and I’m sure our trainers have MUCH better perspective to add! Kanban for software is an [...]

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.