Viewing entries tagged
lean enterprise

Are Scrum Members compatible with line Organization?

2 Comments

Are Scrum Members compatible with line Organization?

Scrum changes working culture of the team members fundamental, or as Henrik Kniberg from 

Spotify.com

 said: „Scrum Teams are designed to feel like a mini-Startup“.

But is this still compatible with traditional line Organization?

All companies I know, that run Scrum, still have a line organization. Idea of line organization is 

to link organizational units, with the help of managing relations, to a hierarchical organization system. In other words e.g. all Scrum Masters are part of a Scrum Master line, developer of a developer line, etc. By today there are

 a lot of  organization types known and hybrid implementations possible too. Don’t take the models in following graphic to serious, but it shows up „modern" implementations :-).

BZCJ685CQAA3TA_.png-large

But isn’t that hierarchical thinking incompatible with the self-organized multifunctional approach of Scrum?-Do we really need a managing role that has the last word and decides e.g. about strategy, salary, etc?

May be we find a solutions thinking about, what Henrik said

:

 How we’d organize a mini-startup, where all employees are company owners?-I personally like to be part of a team, where all are equal partners, similar to a Scrum Team. Of course the roles have to be shared, somebody has to take over product owner hat, another scrum master hat, etc. Depending at personal interests this could be fixed- or rotating roles. Critical decisions would be taken as team, well known in Scrum as team commitment. While base for decision would be worked out in team as well, as we do with a story. Planning meeting would help to structure our tasks in mini-startup, we would set Team goal for next time boxed sprint and would review result, but also continuously improve ourselves through retrospective’s.

If our mini-startup is getting bigger, we split team in two to minimize overhead. From my point of view 3 things would be important during scaling:

  1. Product Owner is working with both teams
  2. New Team members getting equal partners too
  3. Teams are building guild’s depending at topics

Now you’d say Product Owner is getting manager of mini-startup, but this is not true. He’s still equal partner to team members, but he has other focus. Decisions are still taken in team or by team representatives depending at topic. The more we scale organization the more important Guild’s will become. Those would be the glue to keep independent teams together, to exchange best practices and to take decisions within guild’s topic.

Wouldn’t that be more compatible company organization for Scrum Teams?-Or how you’d design your agile organization?

2 Comments

Comment

How Scrum can evolve other industries

ted1f Siehe wie Joe Justice die Methodiken der agilen Software Entwicklung auf die Autoindustrie adaptiert und damit eine unglaubliche Performance erreicht hat.

[youtube=http://www.youtube.com/watch?v=x8jdx-lf2Dw&w=560&h=315]

Comment

6 Comments

#BeyondScrum - #LeanEnterprise oder wie #Scrum das #Research & #Development verändern kann

Die Einfachheit als auch die Effizienz von Scrum hatte mich inspiriert in einem isolierten Team den Research- und Development Prozess (R&D) anzupassen. Gerne teile ich mit Euch meine Idee und erste Erfahrungen aus der Initierung und ersten Sprints. 
In vielen kleinen und mittleren Unternehmen besteht kein eigentliches R&D Departement. Die Mitarbeiter sind mit Delivery- oder mit Maintenance Aufgaben ausgelastet und eilen von Sprint zu Sprint. Neues anzugehen ist schwierig zu planen und wenn einmal Leerzeiten auftreten, bspw. zwischen Projekten oder aber auch in Projekten selbst, fällt es den Verantwortlichen schwer diese sinnvoll auszufüllen. Auch ist irgendwie jedermann und niemand verantwortlich für R&D und somit läuft dies heutzutage meist sehr unstrukturiert ab.
Inspiriert von Scrum lag die Lösung für mich auf der Hand, den R&D Prozess mittels einem nebenläufigen R&D Prozess abzulösen. Idee ist parallel zum Delivery Stream ein weiteren R&D Stream aufzusetzen, welcher aber über eine etwas längere Laufzeit aufweist. Nun werden periodisch in einem R&D Produkt Backlog zusammen mit dem Management, den Line Managern aber auch den Mitarbeitern Themen erfasst und priorisiert. Ist der R&D Sprint einmal gestartet und geplant kann sich nun jeder bei Leerzeiten, je nach seiner persönlichen Präferenz, aus dem R&D Sprint Backlog bedienen. Einzige Bedingung ist, die gewonnenen Erkenntnisse zu dokumentieren und im Sprint Review Meeting allen vorzustellen.
3466df87fb89d32b308c22110b80c986
Vorteile des R&D Streams mittels Scrum sind:
  • R&D ist in der Verantwortung von allen und jeder kann Inputs einbringen (Top down & Bottom up)
  • Leerzeiten werden sinnvoll genutzt, d.h. generieren sogar noch erwiesen Business Value
  • R&D ist instutionalisiert und steht nicht im Konflikt mit Delivery

Vom Management, aber auch seitens Mitarbeiter wurde dieser Prozess sehr gut aufgenommen und die Erfahrungen sind bisher durchwegs positiv. Einerseits sind sich die Mitarbeit die Selbstorganisation gewohnt und können sich somit auch mit Themen befassen die sie persönlich interessieren. Andererseits können die Mitarbeiter so aktiv auch die Unternehmensstrategie beeinflussen und neue Inputs einbringen, ohne das Delivery zu vernachlässigen. Gleichzeitig profitieren durch die konsequente Dokumentation und Präsentation der Erkenntnisse auch die anderen Mitarbeiter und somit letztlich auch das Unternehmen.

6 Comments