Next Monday in Mannheim, Germany we will discuss Scrumbut in our open monthly "Scrum Stammtisch". This months topic is the consequences of leaving out elementary elements of Scrum. I'd like to know what [people] think...As perhaps the first person to ask people to take the Nokia test in public, I feel a little bit responsible for the creation of the term "ScrumBut." Is it OK to change Scrum? Certainly there are situations where necessary, and others where it's not OK (and probably some overlap between the two!), so here is my take on changing Scrum:
The core of Scrum is really very small. Inspect and Adapt. At regular intervals. Everything thing Scrum is designed to enable effective inspection and adaptation at regular intervals.
To me, Scrum represents a solution to the challenge of solving complex problems based on those simple principles. It's a reference implementation. You'll never do it exactly like it is in the book, but especially at the beginning, you should try to get as close as possible to the book.
As you get good at Scrum, your inspections and adaptations may take you away from the book. When is that OK?
I have two tests for good changes to Scrum:
- Does it cause you to inspect and adapt more often than Scrum-by-the-book? If yes, it's probably a good change. If not, then probably not.
- Is your change the result of an agreement, either among the Scrum Team or between the Team and its stakeholders, to improve performance? If yes, it's probably a good change. If not, i.e. you are accommodating some endemic problem or inability to change, then you are probably being tempted by the Dark Side and should tread cautiously.
I think (1) is a stronger, more reliable test than (2). And I think if (1) and (2) both pass, well that's a sign of impending Awesomeness!
What's you take? When is it OK to change Scrum? How do you check that the change is OK?
Ich hatte letztens das Vergnügen, drei Stunden Einführung in RUO und IVD Regulatorien zu bekommen. RUO steht für “Research Use Only” und IVD für “In Vitro Diagnosis”. Diese strengen Richtlinien der FDA (Food And Drug Agency) beschreiben, was ein Hersteller vorweisen muss, damit die FDA seine Produkte auf dem amerikanischen Markt zulässt.
Ich kann hier gar nicht auf all das eingehen, was gefordert wird, aber ich habe zwei Zahlen für euch: Für ein RUO-Produkt – also eines, das nur für Forschungszwecke herangezogen werden darf – müssen ungefähr 2500 Seiten Dokumentation an die FDA geschickt werden, auf denen sorgfältig festgehalten wurde, wie dieses Produkt funktioniert. Ein IVD-Verfahren verlangt ungefähr 10.000 Seiten Dokumentation.
Das aber in Wahrheit Merkwürdige: Wer ein IVD-Produkt einreichen will, muss nachweisen, inwieweit dieses Produkt im Vergleich zu einem bereits bestehenden Produkt besser ist. In irgendeinem Faktor. Es wird also nur etwas Neues mit etwas Altem verglichen. Wer etwas noch nie Dagewesenes erfindet, muss sich also mit der FDA darüber einigen, wie man damit umgehen will.
Okay, das ist noch alles irgendwie verständlich. Es geht um das Leben von Menschen und da müssen Fehler so weit als möglich vermieden werden. Aber jetzt wird es noch faszinierender: Angenommen, man hat die Zulassung und will etwas am Gerät verändern – sagen wir, das User Interface der Adminoberfläche eines computerunterstützten Produkts. Dann könnte es passieren, dass alle 10.000 Seiten erneut eingereicht werden müssen. Ach ja, das Ganze kostet ca. 250.000,- US Dollar.
Sicher, wer will entscheiden, ob es nur eine kleine, unbedeutende Änderung ist, oder eine mit schwerwiegenden, vielleicht noch nicht absehbaren und möglicherweise tödlichen Folgen. Aber was sich damit natürlich wie von selbst erledigt, ist Innovation. Innovation findet, wie wir spätestens seit dem Buch „The Innovator’s Dilemma“ wissen wissen, am Rand – “in the fringe” – statt. Da, wo es noch keine großen Gelder gibt. Da, wo noch nicht klar ist, wie etwas funktioniert. Es zeigt sich im Kleinen.
Prozesse wie jene der FDA sind notwendig, keine Frage – doch wir brauchen intelligente Antworten darauf, wie wir diese Anforderungen erfüllen. Wir brauchen diese Antworten, weil wir auch in der Medizin noch viele Probleme lösen müssen.
“In vitro diagnostic products are those reagents, instruments, and systems intended for use in diagnosis of disease or other conditions, including a determination of the state of health, in order to cure, mitigate, treat, or prevent disease or its sequelae. Such products are intended for use in the collection, preparation, and examination of specimens taken from the human body. [21 CFR 809.3]” Mehr Information dazu hier
- Tuberculosis – The pandemic of the 19th century is back?
- Der Product Owner / Story Writing
- Mit Agil richtig dokumentieren
I find that real life examples can help people understand why you can't talk about kanban systems without talking about risk, and why you can't calculate WIP limits without understanding work item types, risk and classes of service. Consider the humble problem of "how many shirts do you need hanging in your closet?"...
In China, "Kanban" simply means "looking at the board." For a Chinese audience, Kanban is encapsulated in the cartoon on the cover of my Kanban: Successful Evolutionary Change for your Technology Business. They don't need to look further than the characters standing in front of the board. Hence, to a Chinese mind, our management approach is centered around a standup meeting. All well and good and why not?
However, a senior executive at one of our clilents felt that this perception was likely to undermine the true value and the potential impact of our teachings on his business. So he suggested that we give the wider collection of ideas, intellectual property and teaching tools, a different name. It so happens I'd been thinking along similar lines and introducing terms and branding in our business to lay the foundation for this. So here it is, "The Modern Management Framework." This isn't new. It's the collection of our existing class curriculum and consulting tools but presented altogether in one place for the first time and under one banner.
“Big Visible Charts” war einmal das Motto – Scrum-Teams wollten schnell ihre Informationen an jene mitteilen, die daran vorbeigehen. Ein wundervolles Beispiel für diese Variante der Informationsverbreitung findet sich hier. Die Idee war es, physisch und haptisch, schnell und ohne viel Aufwand Teams zu ermöglichen, effektiver zu arbeiten.
Dann kamen die Leute, die unbedingt die große, allumfassende Visualisierung über alle Projekte haben wollten. Sie setzen immer noch Entwickeln mit Produktion gleich und wollten per Mouse Click haben, was bis dato kein MS Projekt Ghantt-Chart konnte: Tagesaktuelle, verlässliche und korrekte Zahlen über den Entwicklungsfortschritt liefern. Sprich: Reporting bis zum Exzess.
Findige und geniale Entwickler wie zum Beispiel die Jungs von Atlassian bauten coole Tools wie Jira, Greenhopper, und einige andere entwarfen die wirklich abgefahrenen Lösungen wie Trello, VerisonOne, Mingle und wie sie alle heißen, damit sie die geforderten Informationen möglichst schnell und einfach liefern konnten.
Und was passiert jetzt: Es gibt Software-Entwickler, die ihr Geld damit verdienen, z.B. JIRA für Kunden zu konfigurieren, die Workflows anzupassen, und aus der simplen Idee von drei Spalten – TODO, INPRG, DONE – wochenlange Entwicklungsprojekte zu machen. Das ist zwar eine tolle Einnahmequelle und wir als Scrum Consulting Firma werden vielleicht sogar schwach und machen das bald auch – aber das war nicht der Sinn und die Idee hinter alldem. Was wir wollten, war ganz einfach: Wissensarbeit sichtbar machen, damit man darüber sprechen kann. Mehr nicht. Damit ein Teammitglied dem anderen helfen kann. Damit klar wird, wo es noch Lücken gibt und wo man sofort eingreifen kann.
Die Entwicklung geht aber leider in die – meines Erachtens – falsche Richtung. Scrum Entwicklungsteams werden automatisiert dazu gezwungen, über jede Story und jede Zeile Code Rechenschaft abzulegen. Ihre Chefs, leider oft auch die Product Owner, müssen das nicht. Warum eigentlich? Wieso wird von den Entwicklern diese Transparenz erwartet, nicht aber von denjenigen, die die Ansagen machen?
Meine klare Vermutung: Es würde zu deutlich zeigen, dass dort gar nichts produziert wird. Dort wird keine Leistung, keine Wertschöpfung erbracht. Erklären Sie doch einmal der nächsthöheren Ebene, was Sie den ganzen Tag in den 6 Meetings zu je 90 Minuten und in den 10 Telefonaten dazwischen produziert haben.
Wir haben in unserem Unternehmen die Beweiskette, den Nachweis, dass etwas passiert, umgekehrt. Ich muss klar darlegen, was ich tue. Ich führe ein Backlog, das sich alle in einem Confluence Wiki ansehen können. Dort stehen alle Aktivitäten (fast alle – ich vergesse auch mal was), die ich an einem Tag ausführe, und ich lege die Ziele ebenfalls öffentlich ab. Nicht weil ich sie vorgeben will, sondern weil wir sie nur dann diskutieren können, wenn wir sie immer wieder sehen. Man kann nur über etwas reden, das man offenlegt.
Und wisst ihr, was passiert ist? Es hat Schule gemacht. Jeder legt nun das, was er tut, ganz von selbst offen. Wir haben noch kein Taskboard – noch nutzen wir ein Wiki. Vielleicht nutzen wir auch bald mal JIRA intern ;-) - als verteiltes, skaliertes und multikultures Team. Aber nicht, damit mir meine Kollegen reporten, sondern damit sichtbar wird, wer gerade woran arbeitet und sich die Kollegen gegenseitig helfen können – egal, wo sie gerade sitzen. Internationalisierung, das remote Arbeiten und das ständige mobil Onlinesein lässt sich nicht mehr zurückdrehen. Wer diese Geschwindigkeitsvorteile nutzen will, darf Tools für die Zusammenarbeit über die Grenzen eines Büros hinaus nicht mit Reportingtools für das Management verwechseln oder sie dafür missbrauchen.
- Eindrücke eines Teilnehmers an CSM Training mit ScrumCooking
- Scrum Tools | Protonotes | Review
You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
If you feel like there’s a lot of time being idled away on the Ice Bucket Challenge and other wacky, brainless activities, we have a better idea to spend your time. In just 10 minutes you could do something really valuable for the agile software community.
But first I’m hoping to get just a tiny smile out of you by sharing something I wrote on our Product Blog earlier this week — just in case you aren’t subscribed there. If you are, just ignore this and go straight to the punch line.
I posed this question:
What’s the Best Way to Spend 10 Minutes?
Let’s think about this for a minute…
- Ice-bucket challenge someone
- Set a stapler in a Jell-o mold
- Crash someone’s Facebook by inviting them to Candy Crush
- Add a ‘Blue Screen of Death’ screen saver to your boss’s laptop
- Load a DVORAK driver onto a PC with a normal keyboard
- Clean those 24 sticky coffee rings off your desk
- Assign a bunch of fake stories to people
But if you really want to make a lasting and meaningful impact on the agile software community, please find 10 minutes to take the 2014 State of Agile survey.
“The annual State of Agile survey has become one of the most comprehensive industry surveys serving the agile community. The survey gives agile software professionals an extensive set of relevant statistics, peer guidance and validation that can be very helpful in making smarter decisions about their delivery process.”
- SD Times Editor-in-Chief David Rubinstein
Now in its 9th year, the State of Agile has helps agile practitioners, consultants, technology students, professors, bloggers and business people in all industries better understand agile methods and practices. The survey runs late summer through mid-September and VersionOne publishes the report in Q4 or early Q1.
If you take it, you get:
- Entered into a drawing for 1 of 9 SONOS wireless HiFi systems (each worth 600 bucks)
- Exclusive, early access to the data sample from 2,000-4,000 respondents in your industry
- Satisfaction that you helped others make informed decisions about their agile practices – in just 10 minutes
What are you waiting for? Take the State of Agile survey now.
I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says,
Management is Prediction
as a inference from Deming. When I read this quote,
If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming
I infer from Deming that managers must manage ambiguity.
Here’s where Glen and I agree. Well, I think we agree. I hope I am not putting words into Glen’s mouth. I am sure he will correct me if I am.
Managers make decisions based on uncertain data. Some of that data is predictive data.
For example, I suggest that people provide, where necessary, order-of-magnitude estimates of projects and programs. Sometimes you need those estimates. Sometimes you don’t. (Yes, I have worked on programs where we didn’t need to estimate. We needed to execute and show progress.)
Now, here’s where I suspect Glen and I disagree:
- Asking people for detailed estimates at the beginning of a project and expecting those estimates to be true for the entire project. First, the estimates are guesses. Second, software is about learning, If you work in an agile way, you want to incorporate learning and change into the project or program. I have some posts about estimation in this blog queue where I discuss this.
- Using estimation for the project portfolio. I see no point in using estimates instead of value for the project portfolio, especially if you use agile approaches to your projects. If we finish features, we can end the project at any time. We can release it. This makes software different than any other type of project. Why not exploit that difference? Value makes much more sense. You can incorporate cost of delay into value.
- If you use your estimate as a target, you have some predictable outcomes unless you get lucky: you will shortchange the feature by decreasing scope, incur technical debt, or increase the defects. Or all three.
What works for projects is honest status reporting, which traffic lights don’t provide. Demos provide that. Transparency about obstacles provides that. The ability to be honest about how to solve problems and work through issues provides that.
Much has changed since I last worked on a DOD project. I’m delighted to see that Glen writes that many government projects are taking more agile approaches. However, if we always work on innovative, new work, we cannot predict with perfect estimation what it will take at the beginning, or even through the project. We can better our estimates as we proceed.
We can have a process for our work. Regardless of our approach, as long as we don’t do code-and-fix, we do. (In Manage It! Your Guide to Modern, Pragmatic Project Management, I say to choose an approach based on your context, and to choose any lifecycle except for code-and-fix.)
We can refine our estimates, if management needs them. The question is this: why does management need them? For predicting future cost for a customer? Okay, that’s reasonable. Maybe on large programs, you do an estimate every quarter for the next quarter, based on what you completed, as in released, and what’s on the roadmap. You already know what you have done. You know what your challenges were. You can do better estimates. I would even do an EQF for the entire project/program. Nobody has an open spigot of money.
But, in my experience, the agile project or program will end before you expect it to. (See the comments on Capacity Planning and the Project Portfolio.) But, the project will only end early if you evaluate features based on value and if you collaborate with your customer. The customer will say, “I have enough now. I don’t need more.” It might occur before the last expected quarter. It might occur before the last expected half-year.
That’s the real ambiguity that managers need to manage. Our estimates will not be correct. Technical leaders, project managers and product owners need to manage risks and value so the project stays on track. Managers need to ask the question: What if the project or program ends early?
A number of years ago I worked with an EDI (Electronic Data Interchange) team that was troubled with a large level of WIP (Work In Process) and slow movement of work through a system with many external dependencies. Work was regularly blocked waiting for unresponsive peers from the other companies. Work would languish in partially completed states and eventually be abandoned, either because the business relationship changed or the team gave up and turned their attention towards more likely prospects.Looked like great place to apply kanban
These sounded like great problems to solve with the help of the Kanban Method and I was eager to get started. This thinking, however, set us on an educational but somewhat fruitless path. The results weren’t what we expected.Applied the Kanban Method
We mapped out the value stream, modeled it appropriately in a kanban, and used the kanban system for a while to get visibility into the process and gain understanding. That was a success.
The Kanban Method helped us confirm that each analysis, development and QA step in their value stream took little value-added time. Nothing unusual or out of the ordinary was happening in any of the stages. We weren’t worried about vacations or someone getting hit by a bus. There were no bottlenecks.
The kanban helped us discuss Lean concepts and apply them to our situation.Got some benefits but nothing real or substantial – no WIP reduction or lead time reduction
Our initial goal was to visualize the process, reduce WIP, simplify prioritization, and look for improvement in lead-time, especially through reduction in delay. We got the visualization and felt we didn’t need as much as we got. We more fully understood the amount of WIP, but limiting it would not enable any additional swarming. Perhaps we got the simplified prioritization, but that came more from understanding the system and lean principles than from the Kanban Method or the kanban (the board) itself.
We didn’t achieve the lead-time reduction. We couldn’t. The delay was outside of our control.Outside of our control
The root cause was that the team was waiting for external IT shops to complete their part of the equation. It took several rounds of interactions with multiple people outside our company to complete a job. After our team did a little processing, the work item went to sleep in a blocked state and (maybe, someday) would be woken up by the external IT shop if they should decide to respond to our pleading.
Our group would benefit greatly from setting up EDI with their numerous business partners, but the other companies had no incentive to do their part of the connection. (Perhaps you are thinking that we needed to give them a financial incentive. We explored many ideas that just didn’t fit into our sales or business model. Changing the business model was another avenue of exploration but let’s save that for another post.) The times that the external group did respond, it was likely because they had some slack time and/or thought the task was interesting or challenging.It didn’t matter anyway
It really didn’t matter anyway.
Every integration with a 3rd party is of high value to our business — worth the cost of abandonment of work on a large percentage of opportunities. Each successful company pushed through the process is so valuable that it more than covers the costs incurred with those that fail.
Therefore, it was more important to have many “at bats” or “sales calls” than it was to have a short lead-time. Well, maybe ‘important’ isn’t the right word. It’s very important to complete work quickly, but in this case, it’s achievable to have more sales calls. We couldn’t improve our lead-time no matter how important that is.
A better way to look at it is we had extra capacity and used that to push more companies through the process (or, to create demand). We reached equilibrium where a hit suspends additional tries at-bat, and more at-bats ultimately increase hits. Work with an engaged external IT guy competes with making more sales calls. More sales calls yield additional willing external partners.
Yes, that will build up significant WIP over time. Whether we control WIP or not, many of the external companies aren’t going to cooperate and finish the process. We will abandon a lot of work. We try hard to finish whatever we start, but we can’t tell which work will be abandoned before we start.
Ultimately, we considered the cost of being a low priority and deemed it worth it.Lesson learned
Until this experience, I didn’t fully understand the lean principle of Value trumping Flow and Waste Reduction, a lean principle. I was aware of it, but I only thought I understood it. I knew that sometimes we should accept uneven flow if it helps us get value, but I was thinking that would only ever be exception cases. I was thinking that the norm should be to optimize smooth flow. The implication I had missed is that smooth flow isn’t always a general prerequisite for value. Considerable waste and huge WIP and horrible flow might just get you the most value.
(Anyone can get value if you have flow. This kind of environment isn’t for sissies.)
Finally, I began to think about this situation with the EDI team as having options, rather than as a great place to apply the Kanban Method or Lean Principles. I began to see the options in the system trumping the considerable waste, huge WIP and horrible flow.
The moral of the story is that real options thinking, systems thinking and many other such concepts present or yet to come may be more appropriate in some cases than Lean/Kanban thinking. Lean/Kanban thinking is useful, but it isn’t all there is.
Somewhere in the last decade, I had a similar revelation about eXtreme Programming.
With every shiny new hammer, I find more things that look like nails.
So ein ScrumMaster-Job kann gehörig aufwühlend sein. Je nach Projektphase geht es zum Teil hoch her. Widerstand gegen die Veränderung, Unverständnis über das neue Vorgehen, Kollegen, die immer noch einen drauf setzen müssen. Da bleibt die gewünschte Anerkennung von außen oft aus und es fehlt die innere Balance, sie aus dem eigenen Herzen zu holen. Wo kommt sie dann her – die Zuversicht, dass alles gut wird und man auf dem richtigen Weg ist? Wie baut er sich auf, dieser Fels in der Brandung aka ScrumMaster?Hast Du es schon mal mit Meditation versucht?
Es gibt Schulen, die sagen, ein moderner Leader kommt ohne zu innerer Balance verhelfender Meditation nicht mehr aus. Beim Verweilen im gedankenlosen Raum der Leere tauchen sie auf – die unbequemen Sätze vom Chef heute, die ungelösten Probleme aus dem Projekt, die Reue über die harsche Antwort an den Kollegen. Dann sitzen wir da und irgendwann (mit der Übung wird es immer schneller) merken wir, was wir da gerade so denken. Jetzt wird uns bewusst, wo uns etwas aus der Bahn gebracht hat, auch wenn wir es zunächst geschafft hatten, es zur Seite zu schieben.
Es gibt viele Varianten von Meditation. Einige konzentrieren sich in erster Linie auf das Schaffen von Bewusstheit. Sind wir das nächste Mal in einer ähnlichen Situation, merken wir vielleicht schon im selben Moment: “Ach, das ist doch wie beim letzten Mal”. Und wenn uns das ein paar Mal passiert, schaffen wir es vielleicht irgendwann, uns anders zu verhalten. Jeder, der schon einmal eine Fremdsprache gelernt hat, kennt diesen Effekt. Man wird auf einen Fehler hingewiesen und wenn man ihn das nächste Mal macht, wird man unsicher. Irgendwas war hier, doch weiß man noch nicht so recht, welche Variante die richtige ist. Irgendwann weiß man Bescheid, sobald man sich die falsche Variante sagen hört und man kann sich sofort korrigieren. Und zu guter Letzt sagt man es dann gleich beim ersten Mal korrekt.
Was ich damit ausdrücken will: Verhaltensänderungen brauchen Geduld, und Meditation ist ein möglicher erster Schritt auf dem Weg dahin, indem sie uns hilft, uns jene Themen, die uns aus dem Tritt bringen, bewusst zu machen. Als zweiten Schritt braucht es die Entscheidung, es in der Zukunft anders zu machen. Und dann braucht es Geduld und Beharrlichkeit.
Und Meditation kann noch mehr. Neben der Bewusstmachung als Basis für die Veränderung hilft sie uns, gleich jetzt Frieden zu machen mit dem was ist und war. Der Raum ohne Gedanken ist ein guter Ort, um seine Wunden und Schrammen abzulegen. Man kann sie wie ein Paket einfach in die Leere geben. Ohne weiter darüber nachzudenken, taucht man selbst wieder in den gedankenlosen Raum ein. Dort verweilt man so lange, bis der nächste Gedanke auftaucht, der uns so sehr bewegt, dass er es schafft, uns aus der Leere hinaus zurück in unsere Gedankenkreise zu tragen. Und der Kreislauf beginnt von Neuem, bis das Herz Frieden hat und ruhig sitzen kann.
Wenn das Gemüt in gar zu großer Unruhe ist, braucht es eine explizite Bearbeitung der Situation. Hier hilft oft ein Gespräch mit Freunden oder der Familie. Bei beharrlichen Themen empfiehlt sich die Zusammenarbeit mit einem Coach und mit Selbstcoaching-Methoden, wie z.B. einem Tagebuch. Um kurzfristig Dampf abzulassen hat sich ebenfalls Sport sehr bewährt.
Liebe ScrumMaster, was sind Eure Rezepte bei innerer Unruhe, bei mangelndem Gleichmut und verschwundener Gelassenheit, oder gar dem Verlust der Freude und Begeisterung für Eure Arbeit?
- Führung in Scrum | der Manager | Verhalten | Teil 2
- Summer School Weekly Cartoon: Teamführung
- 25. und 26. März | offenes CSM Training in Berlin
Eine Situation unlängst in einem meiner Kundenprojekte: Die aufwändig in mehr als 5 Monaten entwickelte Software-Lösung befindet sich im großen abschließenden Test durch alle Fachbereiche. Es ist ein zeitintensives Verfahren, da viele Stakeholder involviert und jede Menge Testfälle abgearbeitet werden müssen. Ein in der Mitte des Integrationstest gefundenes und zunächst klein aussehendes Problem entwickelt sich während der Analyse zusehends zum „Show-Stopper“. Wichtige Plausibilisierungsprüfungen für den Geschäftsprozess finden wegen einer falschen Logik keine Anwendung. Das To-Do ist schnell klar: Die Methode muss umgeschrieben und verbessert werden, die Anpassungen sind überschaubar.
Was zunächst einfach klingt, gestaltet sich auf den zweiten Blick äußerst problematisch. Die Anpassung muss in einem zentralen Baustein der Geschäftsprozesslogik angepasst werden – das hat große Auswirkungen auf die Geschäftsprozesse. Die Software und Prozesse sind nur sehr mangel- und lückenhaft mit Unit Tests und automatisierten Testskripts abgesichert. Änderungen könnten großflächige Nachtests aller Geschäftsprozesse bedeuten, welche die Produktivsetzung der IT-Lösung um Wochen verzögern wurde. Gute Ideen sind nun gefragt …
Nach einem hektischen und diskussionsreichen Brainstorming hat das Team einen vermeintlich vernünftigen Weg aus der Misere gefunden:
- Die betroffene Methode soll in einem ersten Schritt umfangreich durch zahlreiche Unit Tests an den Schnittstellen abgesichert werden.
- In einem zweiten Schritt wird die Methode überarbeitet und mit Hilfe der Unit Tests auf deren gleiche Funktionsweise getestet.
- In einem dritten Schritt sollen einzelne Testfälle des Integrationstests stichprobenartig wiederholt werden.
Müsste ich eine Analogie für diese Vorgehensweise finden, würde ich die Operation am offenen Herzen wählen. Auch in der Medizin wird versucht, das Herz so gut wie möglich vom Rest der Organe bei gleichzeitiger Beibehaltung seiner Funktion zu isolieren. Beide Vorgehensweisen bergen Risiken, aber sie sind deutlich geringer als bei einem rigorosen Vorgehen ohne vorherige Absicherung bzw. Isolierung.
Wenig überraschend ist, dass die nachträgliche Absicherung der Methode deutlich aufwändiger ist, als wenn sie gleich von Beginn an testautomatisiert aufgebaut worden wäre. Gerade dieses Beispiel hat mir wieder gezeigt, wie wichtig es ist, bestehende Funktionalität gewissenhaft abzusichern, um Änderungen im Code vornehmen zu können. Denn diese Änderungen werden kommen, ganz gleich ob durch Fehler oder neue Anforderungen bedingt.
Respond to change … Start code test-driven!
- Unit Testing: Still Widely Informal / Methods and Tools
- Test Driven Development (TDD) und Scrum | Teil 1
- Certification Test is Postponed
More and more companies realize that focusing on cost savings alone is no longer good enough in today’s fast-paced world. In a competitive landscape where customers have many more options and smaller startups can easily disrupt giants, we need to shift to a value-focused mindset to remain competitive.
Value management in a portfolio context refers to strategic business value (more than the aggregate value of a collection of user stories.) Portfolio-level agility is about optimizing the delivery of that business value.
We introduced the concept of value management in "Portfolio Management for the Fast-Paced World":
“Value management asserts what value is, so we can look at the entire Lean perspective of 'concept to cash' in a value stream. This supports both a more traditional scoring model and benefits realization, as well as approaches like Lean Startup’s Build-Measure-Learn cycle. This pillar represents the portfolio demand -- the demand for development work. “
Value management is a hot topic and we'll be writing about it in the coming months. It’s also an area in which the industry has few experts so engaging with those experts wherever you can is a great way to advance your expertise.
Here's the expertise you should gain if you’re accountable for defining value:
- Adopting methods to detect business opportunities
- Defining market sizing
- Forecasting revenues in new markets
- Understanding existing customer alternatives to get their job done
- Building lightweight business cases
- Picking the “right” things to build from the many possibilities
- Measuring post-delivery value by understanding net lifecycle profits
The problem is that in a fast-paced world, there’s no time to do all those things at a level of detail prescribed in traditional product management curricula. Just as new principles of capacity planning are called for, Value management needs new ways to keep up with the accelerated rate of business. Product management practices must evolve to meet the modern needs of value management.
Agile and Lean practices are popular because they keep pace with the rate of today’s business. Applied to product management, these practices help us retool our product management practices with lighter-weight processes. For instance, minimum viable business cases help us adopt incremental funding methods to redirect funding where more value can be delivered. By the time you write a traditional business case, the opportunity may be gone. Instead, think of applying the continuous cadence planning principle to value management.
In product companies, the product manager role has historically been responsible for defining value as a set of features. In IT, line of business managers and business analysts have been the more common roles, although IT groups could greatly benefit from taking a product lifecycle approach to their work. (Topic for another blog….)
As value receives a bigger focus in organizations looking for greater business agility, various levels and dimensions of value come into play and more roles get involved in value definition. For instance, product manager and product owner are two distinct roles, each having an integral contribution to defining value: product managers define the right features to build, and product owners define how to build the features right. Together they can “Build the Right Thing" and "Build the Thing, Right”. Other roles involved in value definition include business leaders, who track which markets are worth doubling down on; and portfolio managers, who balance longer-term value with shorter-term wins.
The Scaled Agile Framework® (SAFe) has pushed the industry to take a big step forward by making a clear distinction between the product manager role and the product owner role, addressing a pitfall we documented several years ago: when development first adopts Agile practices, there's a propensity to reallocate existing product managers to the product owner role, inadvertently equating the two roles. Merging these two roles causes an organization to lose sight of the evolving business value Agile teams are expected to deliver to their business stakeholders. Prioritization then focuses on what we can do rather than what we should do, and that undermines an organization’s ability to match demand and supply, which maximizes value delivery. Thank you, SAFe, for distinguishing between the two product roles!
However, SAFe and other scaled Agile practices still come up short in guiding organizations on how to define value, and gain the expertise listed above. That’s why we’ve added Building the Right Thing to our Agile University offerings.
The class is taught by expert Linda Merrick from Rally partner Pivotal Product Management. Linda has over 29 years of product management expertise, with a deep understanding of Agile product management. Her class covers the various roles and dimensions of value definition and helps you build the capabilities your organization must acquire to reliably define value, so that development efforts are spent on building the right products and applications. For IT environments, the class also offers practical advice for taking a product approach to IT, a key factor for IT groups delivering business value.
As you enjoy the end of the summer, don’t pass on the opportunity to bring these capabilities into your organization. You may find yourself better equipped to answer the question, “What should we focus on next year?” Our next Building The Right Thing classes take place Sept 9 in gorgeous Boulder, Colorado, and Oct 14 in (not bad either) Raleigh, North Carolina. Take the opportunity to visit our Rally offices during the class breaks!
Wondering how innovation fits into value management? Browse our interactive Enterprise Lean Startup overview.Catherine Connor
It was a normal day. I was reading articles, blogs, emails, Tweets, stories and a host of other types of information. While perusing an item, there was an interesting link and I clicked into another Web location. When I arrived, the newly presented topic was not what I expected so I navigated away from the site. Little did I know, this interaction was most likely recorded by Google Analytics as a “Bounce.”
Google states that, “Analytics helps you analyze visitor traffic and paint a complete picture of your audience and their needs.” Things like Page Views, Average Time on a Page, Entrances and Exits are tracked for behavior. However, the most interesting metric could be the Bounce Rate.
“The Bounce Rate is the percentage of single-page sessions (i.e., sessions in which the person left your site from the entrance page without interacting with the page).” In other words, they were attracted to a specific page and when they arrived, they left the site without interaction. The lower the “Bounce Rate,” the longer they interacted with the page and the site. According to Google, “If you could only choose one metric to look at, Bounce Rate might be your best choice.”
So how does this relate to agile development and agile success? Similar to a Web page or site interaction, a team with a high “Bounce” rate will not be as productive as one that is stable and has stayed together through more than just a short introduction. When people are added or removed on a regular basis, there is not time to understand the full scope of work or the people involved in it.
Medinilla states, “The principle of assigning projects to teams assumes that some team stability is needed. If you are changing team composition every 2 weeks, you are essentially managing a resource pool in disguise. On the other hand, if you are using agile development’s definition of a ‘team, ‘which is more than a group of people commissioned to do the same job, you’ll need some time for the team to ‘glue’ or, as some experts call it, ‘gel together.’” (Medinilla, 2012) It is this unnecessary change, or “Bouncing” that causes confusion, demotivation and poor results in the area of agile success.
There are many benefits to making an agile team stable, one of which is learning. Alistair Cockburn (2006) asserts, “Novices don’t stay novices forever. People who are novices on one project become experienced by the end of the same project… This ability to learn along the way helps many projects. Within a single project’s timeframe, the people learn new technology, new problem domain, new process, and how to work with new colleagues. Often an agile team struggles through the first 2 increments, becoming stronger and stronger until successful results at the end are almost a given.” Bouncing from team to team and project to project doesn’t allow enough time to learn technologies, domain knowledge, processes and characteristics of people.
To help track the Bounce Rate of your agile team, Ekas & Will (2013) have recommended a metric: “Validate that you have a whole team; track the team membership each iteration, beginning with the first iteration; and review it regularly. Confirm that the whole team starts together and finishes together… if the goal is to have stable, dedicated agile teams, then having an indicator immediately available to confirm that this happens can be a big incentive.“
For example: A team of 5 people starts Iteration 1 with a whole team and completes it with the same 5 people so the Team Bounce Rate is 0%. Iteration 2 starts with 5 but ends with 4 so the Team Bounce Rate is 20% and the Team Bounce Rate trend after 2 iterations is 10%. Compare this trend to velocity or throughput after each cycle for evidence of them being connected.
Success with agile development can be measured as a form of bouncing. Both people and process can be affected by it. Just as when a reader will try a certain link and bounce back out before truly understanding the main points of the page, so time is a factor in allowing teams to come together properly.
Give your teams a chance to gel. Give them a chance to learn. Give them a chance to be successful and maybe the bounce rate will turn into a jump for joy.
Cockburn, A. (2006). Agile Software Development: The Cooperative Game. Upper Boston, MA: Pearson Education.
Ekas, L., & Will, S. (2013). Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”. Upper Saddle River, NJ: IBM Press.
Medinilla, A. (2012). Agile Management: Leadership in an Agile Environment. Heidelberg, Germany: Springer Science & Business Media.
Guest post by Johanna Rothman of Rothman Consulting Group
You have some agile teams who are successful. Good for you!
Now you have a strategic project that will require many agile teams to create a program. You know you need people in several locations. You know you need a cross-functional business team to make sure you address the needs of Marketing, Sales, and even Legal. How the heck can you make this happen?
In the agile project management literature, there is a notion of program management. A program is a collection of projects with one business objective. Each project might have its own deliverables. But the real value is in the program. The sum of all the projects is greater than any of the parts.
How do you scale from an agile project to an agile program without a lot of hierarchy?What is the Most Efficient Network in Your Organization Right Now?
When I talk to people about scaling agile, I ask this question:
If you want to move information in your organization fast, what do you?
What is the most efficient way to move information in your organization? People often smile and answer, “The rumor mill.”
People in your company have informal networks. They talk to each other. They help each other. They connect to each other in any number of ways which managers don’t know about. You can use these connections to help agile programs succeed.
“When I discovered that one of the testers needed a little help building an automated test framework, I took 15 minutes and did a screen-share. I showed her how I had started our framework for our testers. It wasn’t exactly what she needed, but it was a start for her.
She understood where I was going. She took that framework, improved on it for her team, and got them going on their own framework. It took me 15 minutes. That’s all. Now, they have their own framework, which is different from ours. That’s okay. Our testers got a show-and-tell the other day from their testers. Our testers came back all excited about the refactoring they could do. I knew it would pay off. – Senior developer
This anecdote is an example of small-world networks and communities of practice in action.
In large organizations, people have mailing lists that are the start of communities of practice. In this example, a senior developer answered a question for a tester. He spent a small amount of time coaching someone in another area of the program. The return was tremendous. “His” testers are now improving on their testing.
In small-world networks, people want to work toward a common goal. Many of them share connections, but it’s not necessary that everyone connect to everyone else. If enough people have connections to many other people, that is good enough.
In large organizations, between the project mailing lists, the functional group mailing lists, the project and program blogs and wikis, and whatever else the agile program uses for communication, there is often a way for people to connect with one another.
The small-world network helps people solve problems rapidly. But that doesn’t help people learn what the status is. How can you organize to learn the status in an agile program and elevate risks? Even if the technical folks can solve their technical problems, you still need a way to organize to see the big picture.How You Organize the Technical Teams in an Agile Program
The software program manager coordinates the delegate project/program managers of the feature teams. As you can see, some of those teams are small programs themselves.
Sally is an agile program manager for six feature teams. Her teams all collaborate on a significant feature set. They work together on a backlog. Once the product owner decides that the team has done enough for that backlog, the feature teams might work on other features. They might exit the program entirely. It all depends on what the program needs. In an agile program, you want to take advantage of your ability to replan based on feature team availability, and backlogs being “done enough.”
Joe, Tim and Henry have single-team projects. In order to show status and elevate risks, Joe, Tim, Henry and Sally would come to the program team meeting, along with the program product owner, the deployment person, and anyone else you need from the technical side of the program.
If you have a program architect, that person would participate, also. Teams embed architects in an agile program. However, you might need to discuss the risks at the program level with an architect. It all depends on your risks and challenges.
A program team meeting is a problem-solving meeting, not a micro-commitment meeting. Since the technical people can solve problems, you don’t need a daily standup for the program team. You do need to elevate risks, and see product backlog burnup charts, among other metrics, to see if the program is on track from the technical perspective.
That’s just for the technical team. What about cross-functional business interests? Cue the Core Team.Agile Program Management Works Across the Business
Back in the ‘80s, I facilitated a cross-functional Core Team across the business. We had a person each from Sales, Legal, Marketing, Training, Finance, Marketing Communications and Hardware. We needed to release within a particular market window so we didn’t miss a specific opportunity. I bet this sounds familiar to many of you. We had inter-dependencies up the wazoo.
I didn’t know about agile. I didn’t know about Kanban. I knew about the value of monthly deliverables, and asking people to commit to small, do-able actions. I knew they each had their “own” work to do. I knew that the program’s work was their work, too. But I suspected they wouldn’t see it that way.
At the beginning of the program, eight months before our projected launch, I asked them to meet biweekly for an hour. We had an action-item list at the bottom of our agenda, which you would recognize now as a Kanban board. Everyone had just one item, and the item only took a few hours to accomplish.
By the six-month mark, we met weekly. By now, we understood how to work together across the organization. The Hardware guy understood how to work with the Marketing guy. (These guys are all generic guys. Some of these “guys” were women guys.) The legal guy was happy because we were not going to ship an empty box. So was I!
Best of all, the product came together, as planned. Not as estimated—not even close. But because we worked our inter-dependencies each week, and replanned as we saw our deliverables, and kept our action items small, we were able to release the product in our market window.
We worked in a cadence, kept our WIP (work in progress) limits small. We replanned. We used what we now know as Lean and agile approaches.Agile Program Management Scales Out, Not Up
Note that the teams don’t try to solve everyone’s problems. The technical teams solve the technical problems. They integrate all the time. They provide good data and insight to the technical program team.
The technical program team solves the risks and understands where the program-level problems are. The program team doesn’t have to solve the technical problems, unless the technical teams are stuck. The technical teams can always ask for help.
Because agile program management uses small-world networks, and is not a hierarchy, this approach scales out well.
The core team solves the cross-business problems. They do not attempt to manage the project portfolio, unless that problem is also in its purview. In small companies, it might also manage the project portfolio.
Program management is not new. Applying agile and Lean methodologies to program management is a new twist on program management.
To read more, see Agile and Lean Program Management: Collaborating Across the Organization, https://leanpub.com/agileprogrammanagement.About Johanna Rothman
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She has been in the software industry for over 35 years—and she never fell for the waterfall promise. She’s the author of eight books about management and project management. Her most recent book is Manage Your Job Search. Her upcoming book is Agile and Lean Program Management: Collaborating Across the Organization. Read more of her writing on www.jrothman.com and www.createadaptablelife.com.
I see Craftsmanship as the answer to an issue that has been rising in importance over the past several years. Agile, as a development methodology, has hit the mainstream. While in many ways this is a good thing, there are some drawbacks. The majority of attendees at the major conferences are now project managers, while in the past they were developers, or at least a fair mix of both. This has helped socialize the ideas around agile development and is a good thing, but we also need to seek balance in the Force. This has given rise to the Software Craftsmanship movement, which is focused on the Art of Writing Software, and what is required to create great software, especially in the agile world. In a previous post, I mentioned how important Craftsmen are to the agile world. But how does one become a Craftsman?
First, lets take a look at the state of affairs of our industry, job-wise. It is pretty well known that being a software
developer is a lucrative career, but the numbers are still somewhat surprising. According to the U.S. Bureau of Labor Statistics, the median salary for software developers in the United States is around $93,000. The statistics further show that the number of jobs in the software development field will grow by 22% in the next 10 years. This is significantly higher than the rest of the job market. So how are we going to fulfill these needs with high-quality developers?
Obviously, we need to train a lot of really talented people. We need them to be able to create software well, and also to be able to work well together. Currently, the primary source of education in software development is via the universities and colleges. Unfortunately, not only is this failing to provide enough programmers for the jobs, it is also failing to provide the high level of quality and experience we will need.
Now, universities are great for a lot of things. They provide a strong level of theory and understanding of the underlying science and logic. What they don’t provide is real-world experience and practical applications of knowledge. This needs to come from somewhere else. My suggestion is to turn the clock back a few hundred years, and turn your team room into a workshop. Let’s populate that workshop with Craftsmen. We may not have all of the Craftsmen we need to begin with, so we need to build and grow them. This can be done by applying an apprenticeship program and using the craftsmen’s model for further career development. Let’s take a look at how this would work.
Let’s begin with the idea of hiring apprentices. An apprentice is someone who may or may not have a formal education in software development. What she will have is the desire to learn. The question remains, “What will she learn and how will she learn it?” For starters, we will focus on five main areas:
- Crafting Code – The art of using one or more programming languages to create clear, well-factored code. We want our apprentices to be polyglots by the time they become journeymen, so we will do this in more than one language.
- Applied Principles – Well-written code isn’t enough. An apprentice needs to understand principles like SOLID, and know how to apply them.
- Technologies and Tools – While programmers need to be able to practice activities like Refactoring by hand, they also need to know how to use certain tools, as well as which tool to choose for a particular task.
- Work Habits – Programming is about more than just showing up, slinging some code, and going home to play Mine-Craft. Especially in an agile software development shop, we need to be able to build muscle memory around the activities that make good programmers great, such as TDD, Continuous Integration, etc.
- Soft Skills – The days of the socially inept programmer are over. Software apprentices will learn how to work in a team, how to communicate with others, and other soft skills that tend to be forgotten in the traditional learning environment.
An apprentice will learn these foundational areas through working on real projects, under the tutelage of a mentor. Ideally, that mentor might be a Master Craftsman, but if one isn’t available, then experienced, well-versed Journeymen will make good mentors as well. At the beginning of her apprenticeship, the apprentice might do some basic things like creating and maintaining the continuous integration environment, some bug fixing, or other tasks. Over time, she will work with her mentor and other Craftsmen on real-world activities and projects, continually adding value to the team. When the apprentice has demonstrated her ability to move on to bigger and more challenging projects and tasks, it’s time for her to be recognized as a Journeyman. We will explore more about the life of a Journeyman in another article. In order to become a Journeyman, the apprentice must show her expertise by doing, not by taking tests. Real work pieces that evidence her abilities in various areas and languages, coupled with having paired with everyone on the team, will determine an apprentice’s ability to move on.
Guest post by Mike Cottmeyer of LeadingAgile
When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.
The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working, tested increment of the product… and is, therefore, what defines the basic requirements for a Scrum team.
When you put analysts, designers, developers, and testers into a single workgroup; let them work across skill-set boundaries, self-organize to balance load; and have them collectively produce a working, tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.
Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness. You have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.
Why Scrum Breaks?
The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real-life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.
When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.
It’s my assertion that these planning dependencies are what result in teams going through the motions of Scrum without realizing value Scrum promises. Last month I did a talk at Agile 2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.
That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.
The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.
SAFe (Scaled Agile Framework) and Value Streams
I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile 2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise-level scale. Scaling Scrum is the topic du jour.
Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean (Leffingwell) has written since he released Scaling Software Agility, I have a ton of respect for his work, and I agree with the basic patterns he has introduced.
(At) this conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.
At LeadingAgile, we typically coach an explicit value stream in the middle-level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.
It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier; it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.
Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.
SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.
We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.
We believe this concept is methodology-independent and will make any methodology you choose better in the long run.
Why SAFe Breaks?
Scrum isn’t trying to break dependencies within the team; it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working, tested increment every couple of weeks.
SAFe isn’t trying to break dependencies within these larger value streams, either. It is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work, and stabilize throughput while producing a working, tested increment every PI.
There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?
If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.
If SAFe is ultimately going to struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about ‘SAFes of SAFes’ or ‘SAFe Product Owner Teams’ or ‘SAFe Portfolio Solutions Teams?’
I suspect we might. I think we might also see evidence of this already.
Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already, given how well SAFe is doing in the market.
If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon, and are people talking about this?
Ken and Jeff Got it Right
Back in 2006 Ken Schwaber put up a slide where he illustrated a team-of-teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely coupled teams (and at that time, that was NOT my reality).
A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that, “teams were never expected to self-organize across class boundaries.” They were implicitly saying that encapsulation was the expectation for a Scrum team to form.
Jeff Sutherland, as we speak over at Scruminc.com is talking about Object Oriented Design (OOD) in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.
I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum nowadays don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.
When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put into place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago, but that is seldom implemented.
I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum.
SAFe is a Compromise
I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.
That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.
At this point in the evolution of my thinking, I find myself in a place where I don’t believe the scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.
We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.
Refactoring Your Enterprise
The only real, long-term sustainable approach to Scaled Enterprise Agile is to take the long, hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.
The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peaceful harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery (DAD), and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.
With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future state starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like which help us get there, while still running our businesses effectively.
If I think about it… that was really what my talk last week was about. It’s up on my blog, and was recorded by the conference, but that might take some time to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend
Guest post by Venkatesh Krishnamurthy, Advisor and Curator, Cutter, Techwell, Zephyr
Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project. I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets. Here are the key ones:
- The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
- Team has neither time pressure nor delivery timelines
I thought to myself that this is not a self-organizing team, but a directionless team.
As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams. I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).
I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.
One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine. As Joseph puts it, building self-organizing teams is like preparing soup. I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.
The below table illustrates the mapping:
- A self-organizing team needs a leader, the right amount of pressure apart from the right set of constraints/goals to succeed.
- The true test of the self-organizing team is their collaboration ability during war time and not during peace time.
- There is a difference between a team organizing themselves and a self-organizing team. Don’t ignore the “self” part.