I had to think a bit on what to have be #1.  Was it something on Acceptance Test-Driven Development, one of the serious trim-tabs of software development?  Or be the underlying reason that drives Lean and Agile?  I ultimately picked How Delays Induce Work (don't worry about the title of the article that is brought up being different) because it is the underpinnings of Lean.  When how delays cause...

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

with Joe Justice &Peter Stevens Scrum beyond Software: Applying Scrum to Manufacturing and Management. Joe Justice with
WIKISPEED 100mpg Prototype Are you enjoying what Scrum Project Management is doing for your software delivery teams? How about sharing some of that success with your sales, marketing, and public relations staff, and your HR, legal, and finance teams? And your hardware development and manufacturing managers?

Learn all about how your entire company can achieve 10x typical  velocities with Peter Stevens, the pioneer of Scrum in Switzerland, and Joe Justice, the founder of Team WIKISPEED. Join us for a special event in Zurich:

May 28 and 29: Certified ScrumMaster Training for Management and Beyond

Read the detailed information (here)!
Sign up for the course (here)
And be sure to join us for a beer on Thursday to talk about WIKISPEED, Stoos and Making the whole company Agile... (find out more here)

I have long published upcoming Scrum Breakfasts either on my blog or in my newsletter. As the community gets bigger, it is hard to keep track of what is happening. So I will now publish here everything I am aware of. If it proves to be a popular feature, I will expand on it, maybe make a real calendar...

Do have an event which belongs here? Let me know by submitting your event here.


Updated on April 22, 2013

Want your event on this list? Click here.
Lean Startup
Zurich - 22.4.2013 TBD:
discuss how to Build your MVP Register
map swissICT Scrum Breakfast
Bern - 24.4.2013 Ralph Jocham:
Agile Portfolio-based Release Trains Register
map Stoos Network
Zurich - 25.4.2013 Kurt Schär:
Gegensätze als Erfolgsfaktor Register
map swissICT Scrum Breakfast
Zurich - 8.5.2013 Jiri Lundak:
Einmal agil, für immer agil? Register
map swissICT Scrum Breakfast
Basel - 15.5.2013 Rainer Hiss:
Projekt-Priorisierung auf Basis eines Kanban-orientierten Pipeline Boards Register
map swissICT Scrum Breakfast
Lucerne - 16.5.2013 Philipp Engstler:
Agil surfen - eine Organisation reitet die Welle Register
map
Want your event on this list? Click here.

Wenn wir davon ausgehen, dass Produktentwicklung zu jedem Start mit Erwartungen, Annahmen, Befindlichkeiten und schlichtweg Vermutungen konfrontiert ist, dann Reden wir von Hypothesen. Wie prüft man Hypothesen? Richtig, durch Experimente, und das möglichst schnell und kostengünstig – denn man erkennt das Wichtigste erst nach dem Start.

Was machen wir in Unternehmen, vor allem im Enterprise? Da wird versucht, die Kosten von Hypothesen im Vorfeld möglichst genau einzugrenzen, um die möglichen Experimente gegeneinander abzuwägen. Diese Unternehmen agieren also meist risikoavers. Da in der Software-Entwicklung schmerzlich gelernt wurde, was es heißt, falsche Schätzungen abzugeben, entstehen für Schätzungen teilweise enorme Kosten. Die Kosten entstehen, weil genau eruiert wird, was alles sein könnte, und dafür benötigt man viele Details, die später selten noch etwas wert sind. Es wird Eindeutigkeit provoziert und geschätzt und zwar genau dort, wo Mehrdeutigkeit im Spiel ist. Die Dinge, die geschätzt werden, haben selten etwas mit dem zu tun, was letztlich später umgesetzt und noch später akzeptiert wird. Ein weiteres Problem, das damit einhergeht: Die Anforderer lassen jeden Gedankenblitz von der Software-Entwicklung schätzen, stören so die Menschen und halten sie von ihrer eigentlichen Arbeit ab.

Warum ticken Unternehmen so risikoavers? Meine These: Es fehlt an Vertrauen, Fachkenntnis und Mut zu klaren Entscheidungen. Klar sind die Themen auch komplex, allerdings entzerrt man Komplexität nicht durch das Denken alleine, sondern vielmehr durch das Tun und Anschauen – zu viel mehr taugt unser Verstand auch nicht. So ist es auch leichter, Verantwortung abzuwälzen und anderen Schuld in die Schuhe zu schieben. Schließlich hat sich ja die Software-Entwicklung verschätzt und nicht etwa der Vertrieb oder das Marketing entschieden, dass das Feature sinnvoll und wichtig ist.

Schätzungen sind teilweise wichtig, das möchte ich nicht anzweifeln, aber klar einschränken. Wenn ich für mein Produkt den gesetzlichen Termin kenne, wenn ich weiß, dass ich nur ein gewisses Zeitfenster für mein Produkt habe, wenn ich schnell etwas auf dem Markt ausprobieren möchte, dann benötige ich selten eine genaue Schätzung. Dann mache ich es, oder unterlasse ich es – je nach Konsequenz.

Was ist nun mit der anderen Sachlage, z. B. bei zwei ähnlich wichtigen Features oder Produkten, die ich auf den Markt bringen könnte? Warum sollte ich hier auf eine Schätzung verzichten? Zum einen weil ich meine Entwicklung ausbremse, indem ich sie störe und ihr Gedanken wie Flöhe in den Kopf setze. Zum anderen hilft viel Information nicht viel, sondern erschwert die Entscheidung. Zudem ist die Zeit der großen Produkte ziemlich vorbei und es ist wesentlich wichtiger geworden, schnell auf dem Markt zu sein und seine Ideen zu testen, als fertig ausgereifte und vollends fertige Produkte nach Jahren auf den Markt zu werfen. Auch hier werden die risikobereiten Unternehmen mehr und mehr belohnt. Unternehmensstrategien stehen auf dem Kopf und so macht Agile das.

Warum kann ich auf Schätzungen und Details verzichten und wie mache ich das?

Zuerst: “Warum kann ich auf auf Schätzungen und Details verzichten?” Weil die Bauchentscheidung oftmals die bessere Wahl ist. Wenn ich Sie frage, welche der zwei Features oder Produkte Sie als Nächstes haben möchten, dann haben Sie sich, unabhängig von Schätzungen und ROI-Geschichten, von Business-Value-Berechnungen und strategischen Gesichtspunkten, höchstwahrscheinlich bereits entschieden und das ist gut so. Nahezu jeder, der sein Geschäft gut kennt, kann abwägen, kann aus dem Bauch heraus entscheiden, was er für das Unternehmen als wichtiger betrachtet. Wichtig ist das Zeitfenster und die Reihenfolge, in der das Feature zum Zug kommt.

Gehen wir einmal davon aus, dass Sie die durchschnittliche Durchlaufzeit von Features oder Produkten in ihrem Unternehmen kennen. Also kennen Sie die Anzahl der benötigten Tage von der Idee bis zur Fertigstellung. Im nächsten Schritt begrenzen Sie die Anzahl der gleichzeitig laufenden Entwicklungen. Als nächstes bestimmen Sie einen wiederkehrenden Zeitpunkt, einen Rhythmus, um die nächsten Themen zu priorisieren und an die Entwicklung zu übergeben. Letztlich geben Sie klare Regeln aus, wie priorisiert wird, bspw. durch genau eine Person, einen Kreis von Experten oder rotierende und gewichtete Verteilung nach Bereichen – viel ist möglich, fair und transparent sollte es sein.

Jetzt priorisieren Sie zu den bekannten Zeitpunkten nach Ihrem Regelwerk die nächsten Produkte oder Features und übergeben genau so viele an die Entwicklung, wie Plätze in der Entwicklung frei sind (Limit work in progress).

Was hat das mit Scrum zu tun?

Erstmal viel! Scrum begrenzt das System, vermeidet Überlast durch den Sprint und anhand des Commitments des Teams. Der Sprint stellt den Rhythmus dar und gibt klar vor, wann geliefert wird und wann neue Features und Produkte an die Entwicklung übergeben werden. Der Product Owner entscheidet autonom über die Priorisierung der nächsten Features und arrangiert so die Reihenfolge der Features/Produkte, die als Nächste zu entwickeln sind.

Einsprüche

Höre ich da ein fernes Schreien, ein: “Nein, dann sind wir nicht ausgelastet und wir verschwenden Kapazitäten!” Tja, dann ist das so. Jetzt stellt sich die Frage, wovon lassen Sie sich lieber steuern: Von dem, was sie haben oder von dem, was Sie brauchen und möchten? Ich schätze, das ist Ihre Entscheidung. Das eine ist die eigene Aufstellung zum Selbstzweck, das andere die Ausrichtung am Kunden als Zweck des Unternehmens.

Höre ich da ein nahes Schreien, ein: “Wir benötigen doch Klarheit für den ROI!” Tja, dann ist das so. Jetzt stellt sich die Frage, für welchen ROI: Aus all unseren Priorisierungskosten versuchen wir rational eine Beurteilung herauszufiltern, die Folgendes erzeugt: Zu viel Informationen zum zu frühen Zeitpunkt, falsche Zahlen und ein falsches Gefühl von Sicherheit. Wir priorisieren anhand des Verstandes mit Hilfe von Hypothesen, die teils aus echten Fakten hergeleitet werden, teils aus Nonsens und beides vermischt sich, unteilbar, nicht unterscheidbar. Von der Idee hin zum Ergebnis haben unsere Gedanken das zuerst Gedachte mehrfach verändert und das bei jeder involvierten Person. Wäre das der ROI, den Sie berechnen möchten? Ist das der ROI, den Sie berechnen?

Related posts:

1. Scrum History | Ken´s Talk über Qualität
2. Case Study, we are sorry
3. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight

I have been in software development for almost 43 years now.  This doesn't mean I'm smarter than anyone, it just means I'm older, er, I mean I've seen a lot..  One thing I've seen repeatedly is arguments and discussions about how to do things.  Re-entrant code in the 70s, structured code in the 70s as well.  4th generation languages in the 80s, object-oriented code in the 80s and patterns in the...

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

When I took my first Certified ScrumMaster course, I was taught that one of the responsibilities of the ScrumMaster is to educate. The role of educator is an increasingly important one, as we see more and more organizations adopting Scrum at the e...

First, I am guilty and struggle to loose weight that I need to loose. Having had our 4th child, sleep seems to trump the early morning work-out. However, most of the time it is because I lack discipline to prioritize … Continue reading →

Im ersten Teil des Blogs habe ich mich auf die Abbildung der relativ betagten theoretischen Grundlage des gruppeninternen Führungsverhaltens auf die ScrumMaster Rolle bzw. Prozessverankerung in Scrum konzentriert. Heute steht die Führung an der Grenze zwischen Gruppe und Organisation im Mittelpunkt.

Manz/Sims (1986, S. 148ff.) sehen als Grenzverhalten einer externen Führungskraft die Kommunikation zu dem und von dem Management (1), die Funktion als Bindeglied zwischen Arbeits-Teams in Bezug auf Kommunikation (2) und Unterstützung des Produktionsflusses (3), Training unerfahrener Teammitglieder (4), das Bereitstellen von Arbeitsmaterial (5), die Ermutigung zum Übernehmen anfallender (fremder) Aufgaben (6) und die Abstimmung mit anderen Teamleitern (7).

Aufgaben eines Teamleiters eines selbstorganisierten Teams nach Manz/Sims (1986, S. 148ff.) Aufgaben des ScrumMasters 1) Der Teamleiter informiert das Team über Entscheidungen oder Standpunkte des Managements und stellt sicher, dass das Management über die Bedürfnisse und Standpunkte des Teams informiert ist. Dieser Informationsfluss – ermöglicht durch den Teamleiter – sorgt dafür, dass sich Team und Arbeitssystem besser aneinander anpassen können. Der ScrumMaster als Change Agent sorgt dafür, dass das Management die Rahmenbedingungen für das Team ständig optimiert. Außerdem nimmt er dem Team die Diskussion oder den ggf. zeitintensiven Informationsaustausch mit dem Management ab. 2) Die Verbindung von Teams über den Teamleiter sehen Manz/Sims besonders in Organisationen, in denen aufgrund der Technologie starke Abhängigkeiten zwischen den Teams bestehen, als wichtig an. Zumindest sorgen die ScrumMaster im ScrumMaster-Team dafür, dass übergreifende Kommunikation sichergestellt ist und auch der skalierte Scrum Prozess den Austausch zwischen den Teams ermöglicht. Abhängigkeiten sollten jedoch durch Team und Produktschnitt so weit als möglich vermieden werden. Ist das zu Beginn noch nicht so, ist es Aufgabe der SM, darauf hinzuarbeiten oder die Organisation trotz Abhängigkeiten zu befähigen, zu funktionieren und zu liefern. 3) Hierunter könnte in Ergänzung zu 2 und 5 z.B. die Weitergabe von Output des einen an das andere Team oder die Optimierung dieses Prozesses verstanden werden. In Scrum ist das keine Aufgabe des ScrumMasters. Entweder stellen die Product Owner dies durch die Releaseplanung und Abstimmung der Produktinkremente sicher oder die Teams können untereinander dafür sorgen. 4) Das Training eines unerfahrenen Teammitgliedes durch den Teamleiter (nicht wie oben beschrieben durch das Team) kann nach Manz/Sims zur besseren Leistung des Teams beitragen, da die Teammitglieder die Teamaufgaben besser erledigen können. Training im Sinne des Scrum Frameworks und der agilen Prinzipien liegt beim ScrumMaster. Alles Fachliche kann in der Regel jedoch nicht vom SM abgedeckt werden. Hier würde der ScrumMaster dafür sorgen, dass das Team (siehe Blog Teil 1 zu dem Thema) oder evtl. externe Schulungen dafür sorgen, dass das neue Teammitglied arbeitsfähig wird. 5) Bereitstellung von Arbeitsmaterial Nicht der ScrumMaster, sondern der Product Owner sorgt dafür, dass das Team mit Arbeit versorgt ist. Er/sie liefert User Stories und somit den Input für den Produktionsprozess. Arbeitsmaterial wie Infrastruktur, Berechtigungen, Lizenzen, Schulungen und alles weitere, was das Team braucht, um den Input tatsächlich verarbeiten zu können, muss aber der ScrumMaster beschaffen. Die Bereitstellung im Sinne von Finanzierung ist jedoch eher an das Management geknüpft. Auch muss nicht der ScrumMaster alleine rausfinden, welche Arbeitsmittel benötigt werden – das Team kann und muss sich genauso beteiligen. 6) Teammitglieder sollten nach Manz/Sims durch den Teamleiter ermutigt werden, auch anfallende Tätigkeiten zu übernehmen, die nicht (genau) ihrem eigentlichen Profil entsprechen. Bingo! Der ScrumMaster sorgt dafür, dass das Wissen zumindest im Team verteilt wird und/oder dass Teammitglieder sich Wissen aneignen, das sie zum Übernehmen fremder Aufgaben befähigt. “Anfallende Tätigkeiten” passt daher so gut, weil zur Umsetzung der Prio 1 Story mit dem höchsten Business Value bestimmte Skills gerade nicht benötigt werden. Genau dann sollte der ScrumMaster dafür sorgen, dass die Teammitglieder nicht darauf warten, bis wieder eine “passende Aufgabe” kommt oder niedriger priorisierte Aufgaben vorziehen. Sie sollten neben ihrer Spezialisierung Skills aufbauen, die sie auch bei anderen Schwerpunkten nutzen können. 7) Dass die Teamleiter ihre Anstrengungen abstimmen und koordinieren, sollte zur Ergänzung und somit mehr Effektivität führen. Das ScrumMaster-Team sollte übergreifende Impediments oder Muster der Teams identifizieren und ihnen damit helfen, effektiver zu werden. Obwohl diese übergreifende Aufgabe nicht gänzlich auf die ScrumMaster verlagert werden sollte, sollte das ScrumMaster-Team die Anstrengungen bündeln und z.B. Vorschläge zur Optimierung machen. Außerdem sollten die ScrumMaster nicht getrennt voneinander bzw. in Unwissenheit die gleichen Anstrengungen unternehmen.

So weit, so gut. Es findet sich also eine Menge Theorie in Scrum und eine Menge Führungstheorie selbstorganisierter Teams in der Rolle des ScrumMasters wieder. Dem gerecht zu werden, ist in der Hektik und vor allem bei der Umstellung auf Scrum nicht immer einfach. Nichtsdestotrotz sollte es immer wieder die Richtschnur sein, an der die Tätigkeiten der ScrumMaster ausgerichtet und priorisiert werden. Viel von den Bereichen ist durch den Scrum Prozess berücksichtigt – wir müssen also “nur” darauf achten, dass es richtig gelebt wird und vor allem darauf vertrauen, dass es funktioniert. Der Weg zu Selbstorganisation auf einem hohen Level ist jedoch nur durch das Commitment aller, mit Konzentration, Zeit und Inspect and Adapt möglich.

Related posts:

1. 15 Minuten sind 15 Minuten
2. Der ScrumMaster: Status, Position, Rolle
3. Scrum – eine Revolution (4)

In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. Velocity is used in sprint planning to f...

with Ajay Reddy (instructor) Kanban is coming to New England!  Code Genesys, a Boston IT Solutions firm, has partnered with David J. Anderson & Associates to sponsor a series of workshops on the Kanban method throughout 2013. This Kanban Practitioner course teaches The Kanban Method. It begins by covering the basics on how to get started and focuses on the unique advantages Kanban brings to managing product development. Participants will walk away with a strong understanding of concepts such as key demand analysis, metric analysis, setting WIP, classes of service, SLEs etc.   By the end of the Workshop participants will:       Gain a basic understanding with the Kanban Game       Understand how to get started and start using Kanban in your team       Own a data driven approach to evolutionary improvement       Know where to look for & get help Class Schedule Day 1   Introduction to the Kanban Method   GetKanban Simulation   Kanban Mechanics     Work Item Types, Kanban System Design, WIP limits     Cumulative Flow Diagrams, SLAs, Little’s Law     System Thinking     Queue Replenishment, Cadence Day 2   More advanced topics     Classes of Service     Cost of Delay     Shared or Cross Functional Resources     Evolutionary improvement     Models for improvement     Bottlenecks, Variability, Metrics     Kanban in your organization     Organizational practices, Roll Out Plan Register today! Only $1500 per person Discount Code: About the presenter Ajay Reddy started his professional career as a software engineer, and spent many years leading development teams and larger IT functions. He now spends the majority of his time helping technology organizations improve performance by successfully adopting agile practices. Ajay is consistently recognized for quickly adding value to the organizations with which he works through his “active communications, persistent yet compassionate mentoring, and leading by example.” Ajay is an Associate of David J. Anderson & Associates, founder of Code Genesys (a Boston-based IT Solutions company), and managing partner of ScrumDo.com (a cloud-based project management tool for Scrum teams). Location:Boston, MA, USA Venue: TBD

with Ajay Reddy (instructor) Kanban is coming to New England!  Code Genesys, a Boston IT Solutions firm, has partnered with David J. Anderson & Associates to sponsor a series of workshops on the Kanban method throughout 2013. This Kanban Practitioner course teaches The Kanban Method. It begins by covering the basics on how to get started and focuses on the unique advantages Kanban brings to managing product development. Participants will walk away with a strong understanding of concepts such as key demand analysis, metric analysis, setting WIP, classes of service, SLEs etc.   By the end of the Workshop participants will:       Gain a basic understanding with the Kanban Game       Understand how to get started and start using Kanban in your team       Own a data driven approach to evolutionary improvement       Know where to look for & get help Class Schedule Day 1   Introduction to the Kanban Method   GetKanban Simulation   Kanban Mechanics     Work Item Types, Kanban System Design, WIP limits     Cumulative Flow Diagrams, SLAs, Little’s Law     System Thinking     Queue Replenishment, Cadence Day 2   More advanced topics     Classes of Service     Cost of Delay     Shared or Cross Functional Resources     Evolutionary improvement     Models for improvement     Bottlenecks, Variability, Metrics     Kanban in your organization     Organizational practices, Roll Out Plan Register today! Only $1500 per personEarly bird rate $1000 until April 26 Discount Code: About the presenter Ajay Reddy started his professional career as a software engineer, and spent many years leading development teams and larger IT functions. He now spends the majority of his time helping technology organizations improve performance by successfully adopting agile practices. Ajay is consistently recognized for quickly adding value to the organizations with which he works through his “active communications, persistent yet compassionate mentoring, and leading by example.” Ajay is an Associate of David J. Anderson & Associates, founder of Code Genesys (a Boston-based IT Solutions company), and managing partner of ScrumDo.com (a cloud-based project management tool for Scrum teams). Location:Boston, MA, USA Venue: TBD

Distributing Scrum projects isn’t easy. Agile values encourage face-to-face communication and frequent feedback between team members. But for those who seek the benefits of Agile – frequent releases, less waste, high emphasis on value – on larger, more complex projects, this video presents some technical practices that help retain the spirit of co-location in a distributed environment. Video producer: http://www.thoughtworks.com/

This is the third issue of James Brett‘s 5 Questions. Issue 1 featured Ron Jefferies, and Issue 2 featured Ken Schwaber. From the first issue of 5 Questions ”The ideas was to ask five specific questions to members of the Scrum community and post the their replies.”

Over the next couple of months I’ll be republishing all of James Brett’s 5 Questions as they appeared on his blog.

In issue 3 of the five questions series we hear from Mike Cohn.Mike is the author of some of the most successful IT books, including Agile Estimating and Planning, User Stories Applied and his upcoming new book Succeeding with Agile. A big thankyou to Mike for taking the time to squeeze these answers into his incredibly busy schedule.

Bio. Mike Cohn is the founder of Mountain Goat Software (www.mountaingoatsoftware.com), where he teaches and coaches on Scrum and agile development. He is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development, and the upcoming Succeeding with Agile: Software Development with Scrum. With more than 25 years of experience, Mike has previously been a technology executive in companies of various sizes, from startup to Fortune 40. A frequent magazine contributor and conference speaker, Mike is a founding member of the Scrum Alliance and the Agile Alliance. He can be reached at mike@mountaingoatsoftware.com

Mike’s answers..

Q1. Can you describe what you would consider the top Scrum enabler in an organization?

People who want to do something better than they are doing it today. This could be a group that wants to build a product that is smaller or faster or cheaper than anyone else has ever done. Or it could be a group wants to continue to enhance their existing product or service faster, more efficiently, or with higher quality. Wherever this type of passion exists, it can be used to help Scrum take off in that organization.

Q2. Where do you see Scrum in 5 years time?

I’d like to see all of agile be the default way for doing software development. Five or so years ago a lot of the issues were around how can we plan if we’re agile and how can we do it with forty people on the project. Those issues are behind us and plenty of teams have shown us how to overcome those challenges.

Today I hear a lot of questions about how do we do Scrum on globally distributed projects, how do we do it on very large projects, how do we do it within the full organization and so on. Those issues, too, will be behind us in five years.

Q3. What has been your toughest Scrum challenge so far?

I think they’re all tough. Scrum teaches us though that we overcome the challenges by breaking large obstacles into small pieces and continuously making progress.

Q4. What makes you passionate about Scrum?

I’ve always been passionate about anything to do with software. When I spend all-day programming, I would spend all evening reading about programming or doing more programming. When I started managing or running departments, I got passionate about those aspects of software development.

I think I’m passionate about software development because it’s fun. It’s fun to create something, especially something as useful as a new piece of software can be.

Q5. What can we learn from you about Scrum?

The things that I learn from the teams I work with. All of the ideas I teach or write about are ones that I learned from working with different teams.

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

We have a team of 7 developers. We normally work in pairs and we generally have 3 stories on the go at any one time. The 7th dev, picks up any bugs or chores that come through, happily there aren’t always any.

Yesterday as the 7th dev I tried picking up a 4th story myself. Turned out it needed some discussion, turned out it threatened the very purpose of our product. 2 days of spikes and discussions with the whole team who all cared passionately about the implications of this story and all the other stories ground to a halt. Slack could have saved us a lot of cycle time.

In situations like this, we don’t need complex ways of calculating WIP or strict policies, we just have to keep our eyes on whats happening and listen for the screams of frustration when we’re not progressing.

We just need to stay at the Gemba with our eyes and ears open.

What is a Paradigm?

While there’s been some talk and research about project management paradigms e.g. waterfall, Project Management 2.0, ALM,  with the paradigm of agile prevailing at the moment,  looks like no one has spoken about the paradigm of project management tools.  What is a paradigm, in general? It’s a system of principles that unveils the essential qualities of a subject in their entirety. From this perspective, a paradigm of PM tools would be a spot-on framework for choosing a PM tool.  To make it more clear, a paradigm is something that allows a complete 360° view on any subject or matter. I’d say it’s not about the flat 360° view as in traditional geometry, but about a multi-spherical 360° view, as in the geometry of Lobachevsky. In linguistics, a paradigm is a complete set of all the forms of one and the same word realized  through declension and conjugation, esp. as in German or in Russian. A paradigm represents the system of approaches to unfolding a phenomenon. Musing about the cross-disciplinary nature of paradigms, how can we apply it to the project management tools, and how can this concept help software developers?

A multi-spherical abstraction

A Basic Paradigm: MS Project and Excel

I’m sure most of the readers have been facing the moment in their professional life, as they needed a tool for project management. Historically, most of us stem from MS Project and then Excel. MS Project served quite well as a clock ticker for the work that’s planned ahead and progresses exactly as planned. For waterfall, this narrow paradigm worked OK, assuming the project is flat and linear.

What changes in agile software development? The project management paradigm shift  means that nothing is ever going as planned. The PM tools should undergo a shift as well, from routinely tracking the progress the way it’s been planned, to dynamically sensing trends and registering hands-on performance indicators. Sounds like something familiar? Very close to stock trading, that’s right… and we’re still amazed at how many teams keep using Excel for agile project  management. Well, there’re some down-to-earth reasons behind this. Excel comes as a part of the MS software suite, and there’s no need to pay extra for it. One can put data to Excel, and even use it for planning, tracking and reporting. But there’s one essential flaw with Excel. It isn’t a shared collab tool, someone has to keep this Excel file, and while Excel shows statistical trends quite OK, as for stock trading, but it takes habit, skills and extra time to tune it as a decent trend-revealing tool for agile project management (and I’m not even talking about UX and visualization so far).

Excel used in stock trading

The Incomplete Paradigm: Beware Flaws in Assessment

There’re many project management tools out there. Tons of them. It’s not easy to navigate in this space, and when someone is looking to select a PM tool for their company, they  use some typical research methods… and bump against the same misconceptions.  Let me give a brief outline of some approaches that I consider counterproductive.

First, it’s following a direct pitch. Remember, what happens when someone throws a link at you and says “this tool is just what you need”? By “someone”, I mean people who send haphazard intrusive pitch messages either directly to your email, or in social networks, etc.  Normally you’ve got work that needs to be done right now, and you don’t want to interrupt your flow and switch to studying how this tool works, although it might promise a whole new world of  miracles. Next, you have no idea if the person who throws the link  is aware of your needs. It’s easy to throw a link at someone, but it’s not easy to decide for another person if that’s what they need. OK, you might be tempted to open the link to take a look, and invest some time in studying what it’s about. After taking a quick look, you decide that  the pains from using your old tool do not outweigh the trouble and time that you need to invest in exploring this new tool, and you stay with what you have. That’s why following a direct pitch is the least likely way to find what you need (and from the marketing standpoint, the direct pitches are rarely successful).

Second, it’s PM tool assessment sheets. I’ve worked with the leads and clients for quite some time, and what I’ve always been amazed at, that even until recently people have been using those cranky assessment sheets, that should be filled “yes/no” for random standalone aspects which would never put together the complete picture. Like, what changes if we put checks in all the boxes that say “collaboration”, “issue tracking”, “scheduling”, “portfolio”, “resource”, “document management”?  Such assessment sheets are clueless. They still give no clear picture of how the tool works, and whether it will address whatever needs and pains of this very company. The feature requirements as in those sheets  remind me of the flat geometry confined to the 2D surface. Somehow, they never have such bullets as “good data visualization”, “speed to change contexts and retrieve any data”.  That’s an apparent disconnect, where the task of selecting the project management tool is given to an administrative employee, and the real stakeholders, the people who will be working with the tool are left out of the initial screening stage. Well, might be that their process has the stakeholders engaged later, but why not then take a step of extra care to save the stakeholder’s precious time and add a few human requirements?  Like, how human-friendly the tool is? Is it easy-to-use? Still, as much as I’m a wordsmith, I have to admit that no words in no assessment sheets will replace the actual feel and sight of a project management tool in action. The complete paradigm of PM tools is supposed to cover all the facets of multi-dimensional chaotic project management, including the human aspect. How about introducing the criteria of learning curve – simplicity/complexity – user background vs. ease-of-use? One can’t make an accurate assessment of those qualities from “yes/no” sheets.

The third most common misconception is related to all the buzz around agile, agile training, agile consultants, “we-should-do-agile-coz-everyone-is-doing-it”, etc. It’s about hearing of the agile adoption, and rushing to get an agile PM tool, instead of taking care of the process first. This is the same as the phenomenon known as Gear Acquisition Syndrome among musicians, when instead of actually playing music people focus on acquiring lots and lots of music gear.

How much G.A.S. is enough?

I believe that if a company is building their agile dev process from within, they acquire their unique corporate expertise which is an asset in itself. It’s this unique expertise that finally helps them run projects with success and use the tools they need. Same with the GAS syndrome: you don’t know if you like this guitar until you play it. You can watch how a local  pro makes it out with the instrument in the show room (that’s what consultants do), or you can  try and play yourself to get the actual feel.

The Human Paradigm: Comfortable,Visual,Multi-Contextual

So, we’ve covered the basic paradigm of Excel, passed over the hurdles of the assessment sheets and the functional requirements – what else then do we need from a PM tool? We need it to be human-friendly.

A human-friendly data/information capture and delivery by a PM tool means two things: it’s visual, and it’s multi-contextual. I can’t think of anything that goes beyond this final layer.  A parallel layer would be  learning curve vs. ease-of-use, regardless of user background. That would complete our paradigm: a sophisticated PM tool needs to be pleasant to work with and simple enough so people can learn how to use it just by themselves, with no outside help.

There’s more about comfort and ease-of-use than we’d normally think.  Positive emotions facilitate cognition and reduce cognitive burden. When people  spend their time working with the PM tool that hinders their flow in one way or another, they get tired faster, and their higher cognitive powers “expire” faster. It’s not just a matter of pure design aesthetics or pleasant emotions. It’s about conditioning people to work more comfortably and successfully with software tools. We like nice architecture and pleasant interiors, so why should it be any different in the project workspace? The visual and omni-functional PM tool brings in a totally different quality of work for everyone involved, and I wonder why this human aspect tends to be overlooked by many. I’ve written more on the impact that software has on the human emotions (read, well-being and productivity) in the article Do You Speak Human, Software? 

Disclaimer: I didn’t mean to pitch any specific tools, or provide  reviews and recommendations, although it’s kind of more than obvious which agile PM tool is my favourite :)  My goal was to outline the paradigm to be used in the assessment of PM tools, and challenge some established patterns of thinking. When going off the beaten track, chances are high you’ll hit the bullseye of  your target board.. or process (couldn’t resist the pun :)

Du bist von Scrum überzeugt und versuchst, dein Umfeld dafür zu begeistern. Du willst deine Kollegen dazu bewegen, es mal für drei Sprints auszuprobieren – mit allem, was dazugehört: Backlog, Taskboard, Product Owner, ScrumMaster, DevTeam.

Deine Kollegen sagen nicht nein, aber vor Begeisterung sprühen sie auch nicht gerade. Und schon während der erste Sprint anläuft, merkst du: Verdammt. Wir bleiben im Sand stecken. Zu viele Kompromisse werden eingegangen, auf zu Vieles wird gleich von Anfang an verzichtet. Das Daily findet nicht täglich statt und dauert dann gleich eine halbe Stunde. Im Planning werden komplett neue Backlog Items vorgestellt. Das Team weiß nicht so recht, worauf es sich committen soll. Es ist selten zusammen zu sehen, weil jeder anderen Projekten nachlaufen muss. Und bei der Retro zur Scrum-Einführung heißt es dann: Scrum ist grundsätzlich gut, aber wohl nichts für unser Unternehmen. Wir brauchen einen weniger strengen Ansatz, der sich mit unserer Wirklichkeit besser verträgt.

So viel Respekt vor Scrum ist merkwürdig. Ich kann gar nicht oft genug betonen, dass Scrum nur ein Rahmenwerk zur Entwicklung von Produkten ist. Vieles, sehr vieles wird in Scrum offen gelassen – zur Enttäuschung all jener, die eine Schritt-für-Schritt-Anleitung erwarten.

Diese Offenheit hat einen großen Vorteil. Denn der Scrum Flow, so wie wir ihn kennen, ist hinreichend formal, um Vielfalt zuzulassen. Im Vergleich zu anderen Methoden wie beispielsweise dem RUP (Rational Unified Process) kommt Scrum mit einer handvoll Regeln und Rollen aus. Und selbst die Meetings, die gerne als Zeitfresser dargestellt werden, nehmen zusammen gerade einmal 12% der Gesamtzeit eines Sprints ein (zumal Scrum dafür sorgt, dass die restlichen 88% dann wirklich für die Produktentwicklung frei bleiben).

Scrum deckt auf – für manche zuviel

Nehmen wir zum Beispiel das Daily: Ich vergleiche es gerne mit einem gemeinsamen Frühstück am Familientisch. Man sitzt zusammen, um sich für den Tag vorzubereiten. Wer bringt die Kinder zur Schule, wer holt sie ab? Wer geht einkaufen? Was steht auf der Liste? Wann kommt der Babysitter? Wann ist Abfahrt für das Konzert am Abend? Am Ende eines solchen Dailies sollte jeder den Fahrplan für den Tag im Kopf haben und entsprechend koordiniert starten können.

Schreibt ein solches Daily der Familie vor, wie sie zu leben hat? Nein. Es schreibt inhaltlich rein gar nichts vor. Alles, was sich verändert hat, ist der Rahmen: Man verabredet eine feste Zeit und einen festen Treffpunkt. Man versieht das Treffen mit einem Zweck: dem der Synchronisation und Kooperation.

Vielleicht geht man sogar etwas weiter und bittet die Familie, das Frühstück im Stehen abzuhalten, damit alle mit Augen und Ohren dabei sind. Und – Achtung: Jetzt wird’s radikal! Man drückt jedem Familienmitglied einen Stapel gelber Post-Its in die Hand, verbunden mit der Bitte, die jeweiligen Aktivitäten schriftlich festzuhalten und für alle sichtbar an die Kühlschrankwand zu pinnen.

Is that too much to ask for? Für manche Familien sicherlich schon. Die empfinden ein solches Meeting als eine Zumutung und klagen, dass einmal täglich viel zu oft ist. Aber eine solche Überforderungssituation stellt nicht die Tauglichkeit von Scrum, sondern die Kommunikationsstruktur der Familie in Frage. Denn entweder ist die Familie schon so gut aufeinander abgestimmt, dass ein formales Treffen gar nicht mehr nötig ist. Das kann durchaus vorkommen – so wie es auch extrem gute Teams gibt, die sogar eine Retrospektive entbehren können, weil sie den Veränderungsprozess laufend gestalten und in die Alltagspraxis integriert gaben.

Oder aber – und das ist der weitaus häufigere Fall – die Familie hat schlicht und einfach keine Lust mehr, zu kommunizieren. Und auch das mag eine legitime Entscheidung sein, die es zu respektieren gilt. Allerdings ist es dann blauäugig, das Rahmenwerk (Scrum) für das Scheitern verantwortlich zu machen und zu behaupten: Scrum passt hier einfach nicht zu uns. Ehrlicherweise müsste die Antwort lauten: Wir möchten uns nicht so oft ins Gesicht schauen müssen.

Related posts:

1. Eine Erleuchtung: Scrum als Coaching-Tool!
2. Ich bin aus jenem Holze
3. 10 gute Gründe, warum Sie € 99.- und einen interessanten Tag in Ihre Zukunft investieren sollten

My last customer event was to inaugurate my training room last October. It's time for another one!

Joe Justice will be in town this May to co-teach our CSM Course: Scrum in Management and Manufacturing (sign-up for the course here).

After the course, we will have a free public event.

Besides networking, Joe & I will talk about WIKISPEED, Stoos, applying Agile values to the rest of the organization, and the importance of beer in changing the world.

Space is limited, and we look forward to seeing you!

Here are the details:

• What: An evening with Joe and Peter on WIKISPEED, Stoos, Agile in the Organization, and Beer
• When: May 30, 2013
• Where: Training Room "zum Talgarten", Am Wasser 94, 8049 Zurich
• Doors open - 18.30
• Presentation - 19.30 or so
• Doors close - whenever 
• Admission is free but space is limited. Registration is required. If you register please come. If you can't come, please cancel. We request a donation of CHF 10.-- or more for project WIKISPEED.

Loading...

Back in 2008, I started the Scrum Breakfast community and quickly saw that it needed a home in the Swiss IT community. In 2009, the swissICT became that home in what became known as the the Lean Agile Scrum working group. The swissICT has been a great home -- Scrum, Agile, Lean and related practices have thrived! Today, a core team of 25 people organize five monthly breakfasts throughout Switzerland and a major conference once per year! (see swissICT event program)

I am pleased to announce a cooperation between my company and the swissICT. All swissICT members qualify for a 20% discount off the early-bird price to all my Certified Scrum courses in Zürich. Just include the discount code LAS-swissICT in your registration. (jump to the Scrum course program).

The metaphor of technical debt is widely used in software project management in general and especially Scrum. This article written by Philippe Kruchten, Robert L. Nord and Ipek Ozkaya try to put this concept in perspective, discussing how it has become somewhat diluted lately with its extension to other areas than code or its associations with tools like static code analyzers. Using only tools to measure technical debt might lead to leaving aside potential technical debt items that are undetectable by tools like structural or architectural debt. They argue we need ...

“A four-hour remote meeting with four geographies spanning and nine time zones AND I walked out more energized than I walked in.”

- Brent, product line manager in our Kirkland, WA office.

We just had our quarterly portfolio steering meeting, where we take a holistic look at our strategies and roadmaps across the company and make adjustments.   As Rally has grown, we’ve added engineering locations all around the world, and so this meeting involved engineering directors and product line managers in Helsinki, Raleigh, Boulder, and Seattle.  

In the past, I’d asked everyone to come to Boulder for a day for this kind of work, but the carbon footprint for the meeting goes way up when you do that.  And, five people would have spent a day or more in travel time.  So this time we decided to do the meeting fully distributed.

A four hour distributed meeting?  Sounds horrible, to be honest.   And I was worried about how we’d stay focused and get our work done without someone developing deep vein thrombosis from extended sitting.  But with a few of the old tricks, and a couple of new ones, we were able to make it work.  

Start with good video/audio

We’ve invested in Lifesize high-definition video units, which help a lot not only in direct communication, but also indirect - you can see when someone’s standing up, pacing around, started eating lunch, or left the room on a break.  Seeing the view out the window helps the group come together, too.   We watched the sky turn blue and black behind Otto in Helsinki, which reminded us of how late he was staying for the meeting.   We saw the sun brightening the harbor near Seattle, which reminded us that people were just getting started with their day out there.

Make content available in advance

This kind of meeting has a lot of readouts.  We did 7-minute readouts from the owners of cross-cutting strategies, and 7-10 minute readouts of roadmaps for each product line.  Some of these were available ahead of time, and we were able to spend more time discussing the topic and less time orienting around new information.  

Meetings like this are like board meetings, and Brad Feld’s advice on creating a board package is really relevant here.  Next time I’ll probably put together a package and send it out (as faciliator) rather than simply asking participants to share their content before the meeting.  We’d have had much more time for discussion if we had done less reading out.

2 conversations at a time

When I’m facilitating an in-person meeting, one of the working agreements I often use is that we should have 1 conversation at a time.  But with this meeting, we tried explicitly having 2 conversations at once - the out-loud conversation, and a parallel thread in Flowdock.  This took some getting used to, but it had some benefits.

As each person read out on their area, I asked other participants to note #surprises, #puzzles, #risks, and #dependencies in Flowdock.   This led to the following:

1. Participants often saw their own personal reactions corroborated by others, leading to ‘+1’ comments, which made it easier to discuss uncomfortable observations.
2. We didn’t have to do small group reaction debriefs.  Often there is an emotional response to a presentation that leads to a ‘need to be heard’.  Flowdock enabled us to meet that need, and that meant no further discussion was needed on many of the items.
3. We had an electronic record of these items.  For #puzzles and #risks, this produced a set of things we could easily carry out of the meeting and go forward.
4. Michael Ball, our internal coach, started noting the agenda items in the flow as we started new agenda items, so we could group the reactions by agenda item.

Also, as a facilitator, time management was easier.  As we ran out of time on a topic, I didn’t have to worry about evaluating whether the discussion should continue.  I simply said, “Ok, we’re going to move on, but whoever’s interested can continue this conversation in Flowdock.” A few people would stay engaged in typing, but usually the majority of the group would focus on the next area.  For a meeting that’s more about strategic alignment than precise agreement, this worked well.

Keeping people engaged

Whenever I sit on a call for hours, and I try to stand up, I realize I should have taken a break sooner.  With big, distributed steering meetings it’s critical to do frequent breaks - we stopped for 5-15 minutes every hour.  Set a precise time to come back together so people can plan their calls, bathroom visits, or whatever.  

When I facilitate in-person meetings, I usually use what my colleague Stephen Younge refers to as a ‘digital hat rack’ - laptops and phones get stacked on a table by the door.  You can leave your phone on, and you can answer it if it rings, but you can’t be texting and reading email the whole time.  This leads to deep engagement, focus, and participants demand more progress and effectiveness.

But for a distributed meeting, we’re stuck with the electronics.  What I found as I glanced around the room in Boulder was that everyone had Flowdock up.  Some people had it full-screen.  Others had a split-screen - half email, half Flowdock.  The Flowdock desktop client beeps as new messages come in, and this helped pull people back into the meeting; it prevented them getting completely lost in email for the most part.

The reality is that the bar is much higher in a distributed meeting when it comes to facilitation.  You have to keep the meeting focused and interesting for everyone.  There’s a certain amount of positive human feedback that happens when you’re all in the same room - you feel good and productive simply because you’re working together, even when the meeting is unfocused.  

When the group is distributed, that part gets stripped away, and you really have to make sure the work is important, people are prepared, you have exactly the right people (not too many), and that you’re making good progress if you want people to stay engaged.  Flowdock was a great help in this.  

Brent wrote later that Flowdock created  “some great dynamics: there was a balance of power with each person having a voice; conversations were focused without friction so they seemed to use time better.”  Is that what you need in your next steering meeting? It might be time to give Flowdock a try.

Alex Pukinskis