So there you are, wrapping up another successful release planning session. Sprints are all laid out for the entire release. All the user stories you can think of have been defined. All the daunting challenges laid down. Compromises have been made. Dates committed to. Everyone contributed to the planning effort fully.
So why isn’t everyone happy? Let’s check in with the product owner: The product owner looks like somebody ran over his puppy. The team? They won’t make eye contact and they’re flinching like they’ve just spent hours playing Russian roulette. What’s up? Well, here’s the dynamic that typically plays out:
- The product owner has some fantasy of what they think they will get delivered as part of the release. This fantasy has absolutely no basis in reality, it just reflects the product owner’s hopes for what he/she thinks they can get out of the team (it’s just human nature). This is inevitably far beyond what the team is actually capable of. My rule of thumb? A team is typically capable of delivering about 1/3 of what a product owner asks for in a release. That’s not based on any metrics, its just an observation. However, more often than not, it seems to play out that way.
- The team is immediately confronted with a mountain of work they can’t possibly achieve in the time allotted – even under the most optimistic circumstances. It’s their job to shatter the dreams of the product owner. Of course, strangling dreams is hard work. Naturally enough, the product owner doesn’t give up easy. They fight tooth and nail to retain any semblance of their dream.
- After an hour, perhaps two, maybe even three or four (shudder), the battle is over.
I’m going to go out on a limb here and speculate that this is no one’s idea of a positive dynamic. But it seems to happen pretty often with agile projects. It sure doesn’t look like much fun. I’m pretty sure this isn’t in the Agile Manifesto. So how do we avoid this kind of trauma?
- The product owner needs to be a central part of the team. They need to live with the team, be passionate about the product, and witness to what a team does daily. Fail to engage in any of this and a product owner loses touch with the work the team does and loses the ability to gauge their capabilities. Doing all of this is hard. There’s a reason that the product owner is the toughest job in Scrum.
- The team needs to embrace their product owner as an equal member of the team. You have to let them in. Work together. Let go of the roles and focus on the work.
- Prepare for the release planning in advance. There is no reason for it to be a rude surprise. Spend time together grooming the backlog together. As a team.
- Don’t cave to pressure from upper management. Behind every product owner is a slavering business with an insatiable desire for product. Ooh, did I just write that?
Release planning doesn’t have to be a nightmare. OK, in theory…
Filed under: Agile, Scrum, Teams Tagged: Agile, management, Planning, product management, Release Planning, software development
There is a lot of interest in scaling Agile Software Development. And that is a good thing. Software projects of all sizes benefit from what we have learned over the years about Agile Software Development.
Many frameworks have been developed to help us implement Agile at scale. We have: SAFe, DAD, Large-scale Scrum, etc. I am also aware of other models for scaled Agile development in specific industries, and those efforts go beyond what the frameworks above discuss or tackle.
However, scaling as a problem is neither a software nor an Agile topic. Humanity has been scaling its activities for millennia, and very successfully at that. The Pyramids in Egypt, the Panama Canal in central America, the immense railways all over the world, the Airbus A380, etc.
All of these scaling efforts share some commonalities with software and among each other, but they are also very different. I'd like to focus on one particular aspect of scaling that has a huge impact on software development: communication.The key to scaling software development
We've all heard countless accounts of projects gone wrong because of lack (inadequate, or just plain bad) communication. And typically, these problems grow with the size of the team. Communication is a major challenge in scaling any human endeavor, and especially one - like software - that so heavily depends on successful communication patterns.
In my own work in scaling software development I've focused on communication networks. In fact, I believe that scaling software development is first an exercise in understanding communication networks. Without understanding the existing and necessary communication networks in large projects we will not be able to help those project adapt. In many projects, a different approach is used: hierarchical management with strict (and non-adaptable) communication paths. This approach effectively reduces the adaptability and resilience in software projects.Scaling software development is first and foremost an exercise in understanding communication networks.
Even if hierarchies can successfully scale projects where communication needs are known in advance (like building a railway network for example), hierarchies are very ineffective at handling adaptive communication needs. Hierarchies slow communication down to a manageable speed (manageable for those at the top), and reduce the amount of information transferred upwards (managers filter what is important - according to their own view).
In a software project those properties of hierarchy-bound communication networks restrict valuable information from reaching stakeholders. As a consequence one can say that hierarchies remove scaling properties from software development. Hierarchical communication networks restrict information reach without concern for those who would benefit from that information because the goal is to "streamline" communication so that it adheres to the hierarchy.
In software development, one must constantly map, develop and re-invent the communication networks to allow for the right information to reach the relevant stakeholders at all times. Hence, the role of project management in scaled agile projects is to curate communication networks: map, intervene, document, and experiment with communication networks by involving the stakeholders.
Scaling agile software development is - in its essential form - a work of developing and evolving communication networks.
Picture credit: John Hammink, follow him on twitter
What does aggressive decoupling look like?
Last post I talked about the failure modes of Scrum and SAFe and how the inability to encapsulate the entire value stream will inevitably result in dependencies that will kill your agile organization.
But Mike… as some level of scale, you have to have dependencies? Even if we are able to form complete cross-functional feature teams, we may still have features which have to be coordinated across teams or at least technology dependencies which make it tough to be fully independent.
But Mike… you talk about having teams formed around both features and components… in this case, it is inevitable that you are going to have dependencies between front end and back end systems. Whatever we build on the front end, has to be supported on the back end.
What if you looked at each component, or service, or business capability as a product in and of itself. What if that product had a product owner guiding it as if it were a standalone product in its own right?
What if you looked at each feature that might possibly need to consume a component, or service, or business capability as the customer of said service who had to convince the service to build on it’s behalf?
What if the component, service, or business capability team looked at each of the feature teams as their customer, and had the freedom to evolve it’s product independently to best satisfy the needs of all it’s customers?
What if the feature teams could only commit to market based on services that already existed in the services layer, and could never force services teams to commit based on a predetermined schedule?
What if feature teams could *maybe* commit to market based on services which were on the services teams near term roadmap, but did so at their own risk, with no guarantees from the service owner?
What if feature teams were not allowed to commit to market based on services that didn’t exist in the service, nor were on the near term roadmap, eliminating the ability to inject features to the service?
I think you’d have a collection of Scrum teams… some Scrum teams that were built around features and some Scrum teams that were built around shared services and components… each being treated as it’s own independent product building on it’s own cadence under the guidance of it’s own PO.
There would be no coordination between the feature teams and the services teams because each set of teams would be evolving independently, but with a general awareness of each others needs. The services teams develop service features to best satisfy the collective needs of their feature team customers.
I’m not suggesting this something that most companies can go do today. There is some seriously intentional decoupling of value streams, technical architecture, business process, and org structure that has to happen before this model would could be fully operational.
That said, if you want to have a fully agile, object oriented, value stream encapsulated organization, this is what it looks like. You not only have to organize around objects (features, services, components, business capabilities), but you have to decouple the dependencies and let them evolve independently.
The problems ALWAYS come in when you allow the front end to inject dependencies into the back end shared services. You will inevitably will create bottlenecks that have to be managed across the software development ecosystem. Dependencies are bad, bottlenecks might be worse.
If we can create Scrum teams around business objects, work to progressively decouple these business objects from each other, and allow the systems to only consume what’s in place now, and never allow the teams to dictate dependencies between each other… I think you have a shot.
Do this, and you really have agile at scale.
In my continued playing around with R and meetup data I wanted to group a data table by two variables – day and event – so I could see the most popular day of the week for meetups and which events we’d held on those days.
I started off with the following data table:
> head(eventsOf2014, 20) eventTime event.name rsvps datetime day monthYear 16 1.393351e+12 Intro to Graphs 38 2014-02-25 18:00:00 Tuesday 02-2014 17 1.403635e+12 Intro to Graphs 44 2014-06-24 18:30:00 Tuesday 06-2014 19 1.404844e+12 Intro to Graphs 38 2014-07-08 18:30:00 Tuesday 07-2014 28 1.398796e+12 Intro to Graphs 45 2014-04-29 18:30:00 Tuesday 04-2014 31 1.395772e+12 Intro to Graphs 56 2014-03-25 18:30:00 Tuesday 03-2014 41 1.406054e+12 Intro to Graphs 12 2014-07-22 18:30:00 Tuesday 07-2014 49 1.395167e+12 Intro to Graphs 45 2014-03-18 18:30:00 Tuesday 03-2014 50 1.401907e+12 Intro to Graphs 35 2014-06-04 18:30:00 Wednesday 06-2014 51 1.400006e+12 Intro to Graphs 31 2014-05-13 18:30:00 Tuesday 05-2014 54 1.392142e+12 Intro to Graphs 35 2014-02-11 18:00:00 Tuesday 02-2014 59 1.400611e+12 Intro to Graphs 53 2014-05-20 18:30:00 Tuesday 05-2014 61 1.390932e+12 Intro to Graphs 22 2014-01-28 18:00:00 Tuesday 01-2014 70 1.397587e+12 Intro to Graphs 47 2014-04-15 18:30:00 Tuesday 04-2014 7 1.402425e+12 Hands On Intro to Cypher - Neo4j's Query Language 38 2014-06-10 18:30:00 Tuesday 06-2014 25 1.397155e+12 Hands On Intro to Cypher - Neo4j's Query Language 28 2014-04-10 18:30:00 Thursday 04-2014 44 1.404326e+12 Hands On Intro to Cypher - Neo4j's Query Language 43 2014-07-02 18:30:00 Wednesday 07-2014 46 1.398364e+12 Hands On Intro to Cypher - Neo4j's Query Language 30 2014-04-24 18:30:00 Thursday 04-2014 65 1.400783e+12 Hands On Intro to Cypher - Neo4j's Query Language 26 2014-05-22 18:30:00 Thursday 05-2014 5 1.403203e+12 Hands on build your first Neo4j app for Java developers 34 2014-06-19 18:30:00 Thursday 06-2014 34 1.399574e+12 Hands on build your first Neo4j app for Java developers 28 2014-05-08 18:30:00 Thursday 05-2014
I was able to work out the average number of RSVPs per day with the following code using plyr:
> ddply(eventsOf2014, .(day=format(datetime, "%A")), summarise, count=length(datetime), rsvps=sum(rsvps), rsvpsPerEvent = rsvps / count) day count rsvps rsvpsPerEvent 1 Thursday 5 146 29.20000 2 Tuesday 13 504 38.76923 3 Wednesday 2 78 39.00000
The next step was to show the names of events that happened on those days next to the row for that day. To do this we can make use of the paste function like so:
> ddply(eventsOf2014, .(day=format(datetime, "%A")), summarise, events = paste(unique(event.name), collapse = ","), count=length(datetime), rsvps=sum(rsvps), rsvpsPerEvent = rsvps / count) day events count rsvps rsvpsPerEvent 1 Thursday Hands On Intro to Cypher - Neo4j's Query Language,Hands on build your first Neo4j app for Java developers 5 146 29.20000 2 Tuesday Intro to Graphs,Hands On Intro to Cypher - Neo4j's Query Language 13 504 38.76923 3 Wednesday Intro to Graphs,Hands On Intro to Cypher - Neo4j's Query Language 2 78 39.00000
If we wanted to drill down further and see the number of RSVPs per day per event type then we could instead group by the day and event name:
> ddply(eventsOf2014, .(day=format(datetime, "%A"), event.name), summarise, count=length(datetime), rsvps=sum(rsvps), rsvpsPerEvent = rsvps / count) day event.name count rsvps rsvpsPerEvent 1 Thursday Hands on build your first Neo4j app for Java developers 2 62 31.00000 2 Thursday Hands On Intro to Cypher - Neo4j's Query Language 3 84 28.00000 3 Tuesday Hands On Intro to Cypher - Neo4j's Query Language 1 38 38.00000 4 Tuesday Intro to Graphs 12 466 38.83333 5 Wednesday Hands On Intro to Cypher - Neo4j's Query Language 1 43 43.00000 6 Wednesday Intro to Graphs 1 35 35.00000
There are too few data points for some of those to make any decisions but as we gather more data hopefully we’ll see if there’s a trend for people to come to events on certain days or not.
Welcome to our August newsletter. Do you also have a dislike for time tracking? Joanne Perold does, and she explains why in this month’s blog post….more. Kanban Training We still have spaces available on our upcoming Kanban Foundation and Advanced courses. Scrum Sense will once again be teaming up with LKU-accredited Kanban Trainer, Dr. Klaus […]
The post News update 2014/08 – 5 Reasons to Kill Time Sheets appeared first on ScrumSense.com.
Traditionell fragen Projektmanager ihre Kollegen: “Wie lange dauert es, das zu entwickeln?“ Sie wollen Kosten berechnen, die Länge des Projekts kalkulieren und möglichst früh wissen, wie viele Ressourcen das Projekt braucht.
Diese Fragen deuten immer in die gleiche Richtung: Die Projektmanager wollen die Unsicherheit aus dem Projekt nehmen. Unsicherheiten gibt es in Projekten genug: Haben die Projektmitarbeiter genügend Ahnung? Bekommt man die Technologie in den Griff? Hat man am Ende für das gesamte Projekt genügend Budget? Findet man die richtigen Features für das Produkt? Wird der Kunde es haben wollen? Werden die Kollegen die geeigneten Lösungen schnell genug finden … und, und, und. Kurz, es wird versucht die Zukunft vorherzusagen und gleichzeitig weiß man ganz genau, dass das gar nicht geht. Denn jeden beschleicht das Gefühl, dass man bei einem Projekt ja etwas Neues macht – also etwas, das es vorher noch nicht gegeben hat, etwas, das noch nie gemacht wurde. Alle diese Fragen können also gar nicht beantwortet werden. Mit diesen Fragen bin ich immer in die Diskussion eingestiegen und habe mich dabei gewundert, wie man als Projektmanager überhaupt annehmen kann, diese Fragen zu Anfang eines Projekts klären zu können. Dann fragte mich letztens ein Zuhörer bei einem meiner Vorträge: „Ist es denn so? Ist es nicht vielmehr so, dass die meisten Projekte sehr wohl von Leuten gemacht werden, die genau das Gleiche schon einmal gemacht haben? Daher kann man doch sehr genau die Aufwände schätzen.” In diesen Fällen wisse man doch genau, wie lange etwas dauere.
Diesem Argument lässt sich nicht viel entgegensetzen, oder? Denn es ist korrekt: Wenn man mehr oder weniger immer das Gleiche tut, kann man auch Vorhersagen treffen. Auf diesem Prinzip basieren auch alle Ansätze der Schätzverfahren in Scrum-Teams. Wenn man zu irgendeinem Zeitpunkt genug Daten darüber hat, wie lange etwas dauert, dann lassen sich sehr wohl die Aufwände schätzen. Aber Moment: In diesem Fall befindet sich ein solches Team doch gar nicht mehr in einem Projektmodus. In diesem Moment, in dem es wiederkehrende Aufgaben vollbringt, ist es wieder in einem Support-, Maintenance- oder Bug-Fixing-Modus. Aber genau dann sollte man doch sofort vom Projektmanagement hin zu einem klassischen Verfahren der Prozesssteuerung und des Workflowmanagements zurückgehen und wo landet man da? Genau – beim Lean Management des Toyota Production Systems. Dann ist man besser damit beraten sich anzusehen, wie man in Call Centern, in Produktionsbetrieben, in der Logistik oder in Einkaufszentren arbeitet. Dort sollten Logistiker den Ton angeben: Denn Workflowmanagement wird seit 40 Jahren nach dem Pull-Verfahren und dem One-Piece-Flow-Verfahren optimal gesteuert. Es hat lange gedauert, bis sich dieses Wissen durchgesetzt hat, aber es war am Ende erfolgreich. Viele Manager, die Sales-Zahlen vorgeben, Absatzzahlen erfinden und Produktionsziele vorgeben wollen, wollten lange nicht wahrhaben: Der Empfänger des Produkts, meist der Kunde, bestimmt durch sein Kaufverhalten, wie viel ein Unternehmen liefern sollte, und nicht die Annahmen darüber, wie viel der Kunde möglicherweise kaufen wird. Das hat der Handel in den letzten 10 Jahren gelernt und man sieht es jeden Tag an der Kasse der Discounter, wie dieses Prinzip funktioniert.
Dieses Denken hat auch in die Software-Entwicklung Einzug gehalten. Die massive Hinwendung vieler Software-Entwicklungsabteilungen hin zu Kanban – die heute sogar in Tools wie JIRAs Ansatz zur Workflowsteuerung gipfeln – lässt sich so erklären, und sie ist folgerichtig. Wo nichts Neues entwickelt, wo keine Projekte gemacht und einfach das immer Gleiche immer wieder neu angepinselt und noch einmal verkauft wird, da gilt es tatsächlich nichts anders als effizientes Workflowmanagement zu machen. Support-Aufgaben hier, ein Bugfix da.
Es gibt Untersuchungen und IT-Leiter, die behaupten, 70% dessen, was entwickelt werde, wäre nunmal Maintenance. Aus meiner Beobachtung stimmt das. Es ist so – aber wieso? Ist das eine Ursache oder ein Symptom? Ich glaube, dass ist das Symptom. Wenn Software-Entwicklung so durchgeführt wird, wie in vielen Unternehmen heute noch immer und am Ende zu gigantischen Bergen technischer Schulden führt, ja dann schreibt man relativ schnell keine neuen Features, sondern ist ständig damit beschäftigt, das Alte anzumalen oder kleine, völlig unbedeutende Veränderungen vorzunehmen. Die wunderbare Präsentation von Salesforce.com zeigt sehr eindrucksvoll, wie das auch einem Internet-Startup wie Salesforces.com sehr schnell passiert ist.
Aber zurück zum Schätzen. In diesen Umfeldern ist es zwar prinzipiell möglich, Aufwände sogar relativ gut und valide zu schätzen, denn man hat ja eh immer das Gleiche zu tun. Aber es ist völlig unnötig, wie uns die Logistikindustrie gezeigt hat. In diesen Umfeldern hat sich etwas anderes durchgesetzt: Die sogenannte Flusssteuerung, die mit Hilfe statistischer Verfahren die Durchflussgeschwindigkeit und die Höhe der Inputschlange bestimmt, und basierend auf diesen Aussagen die Lieferzeiten sehr korrekt ermitteln kann.
Man braucht also gar nicht mehr zu schätzen, sondern man weiß, wann etwas geliefert wird. Diese Ideen hat Kanban für die Software-Entwicklung populär gemacht – es wurden Serviceklassen eingeführt und nun ist man sehr gut darin, mit diesen Verfahren und WIP-Limits die Auslastung von Teams zu steuern. Jedes Schätzen ist hier Zeitvergeudung und vollkommen unnötig. Erklärt man diesen Umstand, schauen mich Projektmanager oft ungläubig an. Die Prinzipien sind zwar einfach, doch leider liegen diese Erkenntnisse quer zu dem, was der gesunde Menschenverstand sagt und vollkommen quer zu dem, was in vielen Unternehmen zum Thema Auslastung, Workflowmanagement etc. gelehrt wird. Es hat 20 Jahre gedauert, bis in der Automobilindustrie die Ideen von Toyota wirklich angekommen sind.
Wenn also Schätzen in diesen Umfeldern nicht mehr notwendig ist, wie ist das dann bei echten Projekten? Also in einem Kontext, in dem etwas versucht wird, das noch nie zuvor versucht worden ist? Ich habe das große Glück, in den letzten beiden Jahren mit Kunden arbeiten zu dürfen, die solche Projekte durchführen. Dort werden tatsächlich Dinge getan, erforscht, erprobt, ausgetüftelt – also Produkte gebaut, die noch nie zuvor ein Mensch gesehen hat. Das ist ein bisschen so wie der erste Mondflug. Man weiß einfach nicht ob es geht. Die einzige Chance, in diesen Projekten zu Ergebnissen zu kommen, ist die Welt zu gestalten. Man erfindet einfach das, was man braucht. Seien es die Entwicklungsmethoden, die Tools oder auch die notwendigen Produktideen. Allerdings ergibt sich aus diesem Vorgehen eine prinzipielles und unlösbares Faktum. Nun kann man einfach nicht mehr voraussagen, wann man fertig ist. Sicher, man kann sich etwas vornehmen, auf ein Ziel hinarbeiten. Doch etwas zu versprechen wäre illusorisch.
Findige Designer haben für Dinge, die nicht zu komplex sind, eine relativ simple Methode gefunden, wie man dennoch Fortschritte dokumentieren kann und wie man sich zumindest auf etwas festlegen kann: Man gibt einen Zeitrahmen vor. Diese zeitliche Grenze erzeugt den notwendigen Druck, zumindest immer auf ein Ziel hinarbeiten zu müssen, sich also nicht selbst zu belügen und einfach ergebnislos vor sich hinzuarbeiten. Zeitliche Grenzen erzeugen den Fokus, man probiert nicht alles aus, sondern liefert mal den erstmöglichen Fortschritt, das erstmögliche Ergebnis. Kann man diesen Zeitrahmen sinnvoll strukturieren? Sicher! Es gibt Techniken wie Design Thinking oder Scrum, die Teams dabei helfen, genau diesen Zeitrahmen zumindest insofern zu strukturieren, dass das Finden von Ergebnissen wahrscheinlicher – nicht aber sicher – wird.
Doch jetzt das Paradoxon: Diese Methoden sind bekannt. Sie sind sogar so erfolgreich, dass die erfolgreichsten Firmen des letzten Jahrzehnts freiwillig erzählen, dass sie darauf setzen. Sie sind sogar in den Firmen bekannt, die bis dato ganz anders gearbeitet haben – dennoch wird stillschweigend noch immer vorausgesetzt, dass man wissen muss, wann zu welchen Kosten und mit welchem Ergebnis auf jeden Fall das geliefert werden soll, was man heute noch gar nicht kennt. Es wird also versucht, diese neuen Methoden in einem Kontext zu leben, der zugegeben hat, dass die Aufgabe unlösbar ist. Deshalb nimmt man die neuen Methoden und gleichzeitig verdrängt man die Tatsache, dass die Aufgabe unlösbar ist.
Aufwände zu schätzen ist in diesen Umfeldern schlicht unmöglich. Das ist jedem klar, und doch wird es immer wieder gefordert. Warum? Der Trugschluss herrscht, dass man mit Hilfe des Schätzens eines bekämpfen könnte: Die Angst, in irgendeiner Weise zu versagen. Es geht also anders ausgedrückt darum, das Risiko zu verringern. Als könne man durch das Schätzen gewährleisten, dass es zu keinem Verlust kommen könnte.
Doch Schätzen ist aus mindestens diesen vier Gründen ungeeignet, das Risiko zu minimieren:
- Aufwandsschätzungen werden zumeist optimistisch abgegeben. Damit wird das Risiko erhöht.
- Aufwände werden als Kostenfaktor gesehen. Damit ist eine hohe Schätzung zwar vielleicht ein Maß für Risiko, aber wirtschaftliche Interessen konterkarieren dieses Thema sofort.
- Wir wissen aus den Arbeiten von Eliyahu Goldratt, Autor von „The Goal“, dem einflussreichsten Buch zur Theory of Constraints, dass im Falle dessen, dass Aufwandsschätzungen zu groß waren, dennoch diese Aufwände aufgebraucht werden. Damit erhöht sich das Risiko, die Puffer des Projekts zu sprengen und wenn dann wirklich eine Schätzung zu gering war, bricht man die zeitlichen Grenzen. Das Projekt wird also riskanter.
- Aufwandsschätzungen sind abhängig von dem, der sie durchführt. Damit erhält man kein objektives Maß für das Risiko.
All das ist hinreichend bekannt. Dennoch erzeugen Aufwandsschätzungen und die sich daran ausrichtende Planung immer wieder die Illusion, das Risiko wäre gebannt. Was durch das Schätzen von Aufwänden also in Wahrheit geschieht: Das Risiko wird nicht eingeschätzt und bewertet, sondern es wird verdrängt und ignoriert. Wir haben geschätzt und gebannt.
Wie wäre es, wenn wir das Risiko benennen würden, ihm ins Gesicht schauen und es angreifbar machen? Wie wäre es, wenn wir von Anfang an sagen würden: Wir haben hier die besten Kollegen zusammengerufen, die wir haben. Wir lassen Sie das Vorhaben mit ungewissem Ausgang wagen. Wir wissen, dass wir nicht wissen können, wann wir fertig sein werden, doch wir nehmen uns Etappen vor, und wir überprüfen immer wieder, was es braucht, um das Ziel zu erreichen. Was wäre, wenn wir offen darüber sprechen würden, dass wir nicht wissen, ob die Technologie die richtige ist, und deshalb davon ausgehen, dass wir bei neuen Erkenntnissen die Richtung noch einmal wechseln können. Was wäre, wenn wir das Risiko dadurch minimieren, dass wir immer einen kleinen Schritt machen und überprüfen, ob wir auf Kurs sind?
Auch dann wäre es nicht nötig zu schätzen. Man schaut einfach, wie viel man ausgegeben kann und wohin man kommen muss, damit man die nächste Investition rechtfertigen kann. Venture Capitalists gehen so vor – und nicht nur diese. Jeder nutzt genau diese Strategie in seinem eigenen privaten Bereich. Man schaut, was man an Ressourcen hat und dann fängt man an. Ist das ideal? Nein, aber der einzige Ausweg für alle, die innovative Produkte auf den Markt bringen wollen.
Für alle, die sich der Unvorhersagbarkeit stellen wollen, habe ich ein Buch geschrieben: Wie schätzt man in agilen Projekten – oder warum Scrum-Projekte erfolgreicher sind.
I generally like it because it provides a reasonable structure in a collaborative, canvas style.
However, to make it more appealing to me, I'd like to adjust it to generalise to a non-UX designer perspective and also to reflect some slightly different assumptions of what I consider important for developing oneself and others. Specifically, I prefer a job crafting approach.
I've created a template on Google Drive:
I appreciated the opportunity to hear about DAD from the creators, Scott Ambler and Mark Lines. Mark gave a presentation on how this framework was implemented at Panera Bread. The next day, Scott provided more details on their framework.
One common opinion professed by many of the presenters was that there is no one size fits all with agile. There are no best practices. Everything has to be taken in the context of the organization where agile is being implemented. Experiment. Fail fast. Try again. Don’t copy what Spotify did just because it was so effective for them. You can start with a framework, but don't just follow a framework.
The topic of delivering value came up as well. Pat Reed/Walt Wyckoff from iHoriz did a good presentation on a value based framework for portfolio management. Pat stated that even now, 60-90% of features don’t deliver the value that was desired. Another presenter said we shouldn’t focus on shippable code but consumable code. It doesn't matter if it ships, it matters if it gets used. Only then is it bringing value.
There were other topics getting attention, including DevOps and #NoEstimates. The Coaches Clinic and Open Jam added to the value of the conference as well. I'm also sure there were topics I missed. With well over 200 presentations, it's hard to catch everything.
I think a conference like this is a great way to spark some new ideas and maybe help you get out of a rut with your day-to-day routine. Keep in mind that agile is all about inspect and adapt. If you successfully implement agile but then don't try to improve from their, you're doing agile but not being agile.
If you missed the conference and want to get a flavor for it, here are some resources:
Big Visible interviews with many of the conference speakers
Agile Alliance posting of keynote presentations from the conference
Projects at Work interviews with conference attendees
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.
You can get the Weekend Edition delivered directly to you via email by signing up here.
Scrum: a … http://t.co/Qqmr79Mofy
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims… http://t.co/gZVuHo07II
Scrum: a Brea… http://t.co/lGYeIvgakV
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims (Author), Hillary Loui…
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims (Author), Hillary Loui…
Scrum: a Brea… http://t.co/coeL64WC4f
Scrum: a Breathtakingly Brief and Agile IntroductionChris Sims… http://t.co/pGwOtGFkwD
Scrum: a … http://t.co/ptnU3LMm15
I’m going to be at Lean Agile Scotland again next month. I had to miss it last year, but I really can’t decline the opportunity to be at a conference named after me! I’m running a workshop on “Building a Learning Organisation the Kanban Way”. Here’s the abstract:
In a world of Big Bang Disruption, the need for learning organisations is greater than ever. Businesses need to develop people to be able to continuously solve problems as well as implement solutions. This workshop will introduce a canvas that can be used to apply Kanban Thinking. Participants will work through the canvas, learning how the different parts can help towards enabling continuous improvement.
I’m told there are still a few tickets left. And I have a discount code which will get you 10% off the ticket price. Just let me know if thats of any use and I can send you the details. I hope to see you there!
If you already use Agile Results as your personal results system, you have a big advantage.
Because most people are running around, scrambling through a laundry list of too many things to do, a lack of clarity around what the end result or outcomes should be, and a lack of clarity around what the high-value things to focus on are. They are using their worst energy for their most important things. They are spending too much time on the things that don’t matter and not enough time on the things that do. They are feeling at their worst, when they need to feel at their best, and they are struggling to keep up with the pace of change.
I created Agile Results to deal with the chaos in work and life, as a way to rise above the noise, and to easily leverage the most powerful habits and practices for getting better results in work and life.
Agile Results, in a nutshell, is a simple system for mastering productivity and time management, while at the same time, achieving more impact, realizing your potential, and feeling more fulfillment.
I wrote about the system in the book Getting Results the Agile Way. It’s been a best seller in time management.How Does Agile Results Work?
Agile Results works by combining proven practices for productivity, time management, psychology, project management, and some of the best lessons learned on high-performance. And it’s been tested for more than a decade under extreme scenarios and a variety of conditions from individuals to large teams.
Work-Life balance is baked into the system, but more importantly Agile Results helps you live your values wherever you are, play to your strengths, and rapidly learn how to improve your results in an situation. When you spend more time in your values, you naturally tap into your skills and abilities that help bring out your best.
The simplest way to think of Agile Results is that it helps you direct your attention and apply your effort on the things that count. By spending more time on high-value activities and by getting intentional about your outcomes, you dramatically improve your ability to get better results.
But none of that matters if you aren’t using Agile Results.How Can You Start Using Agile Results?
Simply ask yourself, “What are the 3 wins, results, or outcomes that I want for today?.” Consider the demands you have on your plate, the time and energy you’ve got, and the opportunities you have for today, and write those 3 things down.
That’s it. You’re doing Agile Results.
Of course, there’s more, but that’s the single most important thing you can do to immediately gain clarity, regain your focus, and spend your time and energy on the most valuable things.
Now, let’s assume this is the only post you ever read on Agile Results. Let’s take a fast walkthrough of how you could use the system on a regular basis to radically and rapidly improve your results on an ongoing basis.How I Do Agile Results? …
Here’s a summary of how I do Agile Results.
I create a new monthly list at the start of each month that lists out all the things that I think I need to do, and I bubble up 3 of my best things I could achieve or must get done to the top. I look at it at the start of the week, and any time I’m worried if I’m missing something. This entire process takes me anywhere from 10-20 minutes a month.
I create a weekly list at the start of the week, and I look at it at the start of each day, as input to my 3 target wins or outcomes for the day, and any time I’m worried if I’m missing anything. This tends to take me 5-10 minutes at the start of the week.
I barely have to ever look at my lists – it’s the act of writing things down that gives me quick focus on what’s important. I’m careful not to put a bunch of minutia in my lists, because then I’d train my brain to stop focusing on what’s important, and I would become forgetful and distracted. Instead, it’s simple scaffolding.
Each day, I write a simple list of what’s on my mind and things I think I need to achieve. Next, I step back and ask myself, “What are the 3 things I want to accomplish today?”, and I write those down. (This tends to take me 5 minutes or less. When I first started it took me about 10.)
Each Friday, I take the time to think through three things going well and three things to improve. I take what I learn as input into how I can simplify work and life, and how I can improve my results with less effort and more effectiveness. This takes me 10-20 minutes each Friday.How Can You Adopt Agile Results?
Use it to plan your day, your week, and your month.
Here is a simple recipe for adopting Agile Results and using it to get better results in work and life:
- Add a recurring appointment on your calendar for Monday mornings. Call it Monday Vision. Add this text to the body of the reminder: “What are your 3 wins for this week?”
- Add a recurring appointment on your calendar to pop up every day in the morning. Call it Daily Wins. Add this text to the body of the reminder: “What are your 3 wins for today?”
- Add a recurring appointment on your calendar to pop up every Friday mid-morning. Call it Friday Reflection. Add this text to the body of your reminder: What are 3 things going well? What are 3 things to improve?”
- On the last day of the month, make a full list of everything you care about for the next month. Alphabetize the list. Identify the 3 most important things that you want to accomplish for the month, and put those at the top of the list. Call this list Monthly Results for Month XYZ. (Note – Alphabetizing your list helps you name your list better and sort your list better. It’s hard to refer to something important you have to do if you don’t even have a name for it. If naming the things on your list and sorting them is too much to do, you don’t need to. It’s just an additional tip that helps you get even more effective and more efficient.)
- On Monday of each week, when you wake up, make a full list of everything you care about accomplishing for the week. Alphabetize the list. Identify the 3 most important things you want to accomplish and add that to the top of the list. (Again, if you don’t want to alphabetize then don’t.)
- On Wednesdays, in the morning, review the three things you want to accomplish for the week to see if anything matters that you should have spent time on or completed by now. Readjust your priorities and focus as appropriate. Remember that the purpose of having the list of your most important outcomes for the week isn’t to get good at predicting what’s important. It’s to help you focus and to help you make better decisions about what to spend time on throughout the week. If something better comes along, then at least you can make a conscious decision to trade up and focus on that. Keep trading up. And when you look back on Friday, you’ll know whether you are getting better at trading up or if you are just getting randomize or focusing on the short-term but hurting the long term.
- On Fridays, in the morning, do your Friday Reflection. As part of the exercise, check against your weekly outcomes and your monthly outcomes that you want to accomplish. If you aren’t effective for the week, don’t ask “why not,” ask “how to.” Ask how can you bite off better things and how can you make better choices throughout the week. Just focus on little behavior changes, and this will add up over time. You’ll get better and better as you go, as long as you keep learning and changing your approach. That’s the Agile Way.
There are lots of success stories by other people who have used Agile Results. Everybody from presidents of companies to people in the trenches, to doctors and teachers, to teams and leaders, as well as single parents and social workers.
But none of that matters if it’s not your story.
Work on your success story and just start getting better results, right here, right now.
What are the three most important things you really want to accomplish or achieve today?
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 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 results in teams going through the motions of Scrum without realizing value Scrum promises. Last week I did a talk at Agile2014 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 and Value Streams
I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile2014 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 de 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 has written since he released Scaling Software Agility, have a ton of respect for his work, and agree with the basic patterns he has introduced.
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 either 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 going to ultimately 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 SAFe’s of SAFe’s or SAFe Product Owner Teams or SAFe Portfolio Solutions Teams?
I suspect we might. I think we might also be seeing 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 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 Scrum.com is talking about Object Oriented Design 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 now-a-days 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 in 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 peace harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery, 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 states 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 that 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. The talk is up on the blog, and it was recorded by the conference, but that might take a few weeks 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 ;-)
The post Encapsulating Value Streams and the Object Oriented Enterprise appeared first on LeadingAgile.
Leadership is well defined - that's not the problem - the problem is it has many, many various definitions. Leadership definitions change throughout time. Your grandfather's definition of leadership may vary quite drastically from your's - ask him if you have the opportunity.
A modern classic definition:
Leadership is a process whereby an individual influences a group of individuals to achieve a common goal. -- Peter Northouse
A brief history of Leadership
A working definition of leadership
Is leadership a process
May leadership emerge from a group
Is leadership more than a form of coercion and power
Various Leadership Approaches
Situational, Skills, Style, Trait
Leader-Member Exchange Theory
Transformational Leadership Model
Servant Leadership Model
Authentic Leadership Model
Team Leadership Model
Disclaimer: as this blog is a from of note keeping for me - an extension of my cognitive model of the universe of knowledge - this article and the series of article may be in great flux until complete (or good enough to quit editing).
1) Leadership Theory and Practice - 6th Ed. by Peter Northouse.
This is an initial draft for brief guide to how I use the Kanban Canvas, building on the recently posted Prezi. It will eventually be added to the main Kanban Thinking site. Generally, I use the canvas as the core of a two day workshop, during which I use it to facilitate the collaborative co-creation of a kanban system. The canvas becomes a single, simple artefact which captures a common understanding of how a system is designed, and why it is designed the way it is.System
1. First we begin with understanding the scope and purpose of the System. I’m looking to discover key people, problems, frustrations, boundaries and interfaces. I like to get participants to tell their story leading up to the present day, explaining why they are in a room together designing a kanban system.
The output in this section is one or more a simple narratives capturing the essential system elements and interactions.Impact
Next, we need to be able to assess whether any changes we make are improving or deteriorating the systems fitness for purpose. The goal is to be able to describe the general direction we want to go in, without identifying any specific outcomes or end states.
2. We explore various ways we might want the story to end – and what endings might we want to avoid. I ask participants to imagine impossibly good and bad endings – utopian and dystopian futures – using the three Impacts of Flow, Value and Potential to help them look from different perspectives. They are not distinct impacts, but more like triads, where elements of all three could be involved. This generates healthy conversations about how the potential futures relate to the different impacts.
The output across these three sections is a set up potential endings, placed relative to where they have most resonance. Colour coding is used to distinguish between the utopian (green) and dystopian (red) futures.Interventions
Now we have a good understanding of the recent past and desired future direction, we can begin looking at how we can start interacting with the system to make interventions which we hope will have a positive impact.
3. To really understand how we can make effective change, we first need to Study the context. There are 3 areas that I find it useful to study; the customer or stakeholder, the work demand that comes from them, and the way that demand is processed. We usually start by looking at demand, and the group applies concepts such as value and failure demand, the CORE Profile and Classes of Service. Then we’ll explore where that work comes from with a technique such as Empathy Mapping, and how that work is processed with a variation of Value Stream Mapping focussing on the flow of information and its discovery.
The output in this section is a set of sticky notes capturing a summary of customer/stakeholder needs, demand classifications and classes of service, and primary workflow states, transitions or delays.
4. Once we have a good common understanding of the existing context, then we can Share it by visualising our knowledge on a kanban board. First I ask the group to discuss and agree which information is most relevant and important for them to share – trying to show everything will just create noise. Then I introduce the Token, Inscription, Placement concept as a way of thinking about board design patterns, and the group comes up with approaches to visualise their important information.
The output in this section is a set of mappings between each important informational dimension to be visualised, and the visualisation technique to be used.
5. The next step is to begin to Stabilise the current system by introducing explicit policies. These policies will form flexible boundaries to contain the work. Boundaries which are too hard and fixed will lead to rigid bureaucracy, while boundaries which are too loose will lead to chaos. I introduce Work In Process limits as a core policy type, and we explore the various strategies and techniques for introducing and setting WIP limits. Then the group brainstorms some simple quality checklists to agree how and when work should progress across the board. These simple, standard work definitions become the baseline for future improvements.
The output in this section is a set of decisions regarding basic WIP limit strategies and allocations, and bullet points for initial entry/exit criteria on the board.
6. As a system is put in place and evolves, we need a way to Sense its capability in order to assess its fitness for purpose. The two primary means for this are measures and meetings. First, groups decide which outcomes they hope will have a positive impact, typically selecting from productivity, reliability, responsiveness, quality, customer satisfaction and employee engagement. Metrics are discussed and defined for these outcomes, considering the anticipated behaviour and consequences, and potential tradeoffs with other outcomes. Then groups decide what meetings and cadences they would like to use to give them an ongoing rhythm for assessing capability and progress.
The output in this section is a set of simple metrics definitions, and a list of meetings and respective cadences.
7. Finally, the evolutionary potential of the system is explored by beginning a Search for alternative designs. Given everything that has been discussed so far, the groups begins to define small experiments that could be run on possible changes. Each experiment has a hypothesis, a rationale, measures to both validate and falsify, and a mechanism for ensuring safety and reversibility.
The output in this section is a set of initial simple experiment definitions which can be run.
All of this is done in a very collaborative way, using various facilitation techniques to ensure everyone is able to contribute, different opinions are heard, and consensus is reached. At this point, the group is able to begin learning, evolving and improving their kanban system using the canvas as a basis.
Are your management practices long in the tooth?
I think I was lucky that early on, I worked in environments that shook things up and rattled the cage in pursuit of more customer impact, employee engagement, and better organizational performance.
In one of the environments, a manufacturing plant, the management team flipped the typical pyramid of the management hierarchy upside down to reflect that the management team is there to empower and support the production line.
And when I was on the Microsoft patterns & practices team, we had an interesting mix of venture capitalist type management coupled with some early grandmasters of the Agile movement. More than just Agile teams, we had an Agile management culture that encouraged a customer-connected approach to product development, complete with self-organizing, multi-disciplinary teams, empowered people, a focus on execution excellence, and a fierce focus on being a rapid learning machine.
We thrived on change.
We also had a relentless focus on innovation. Not just in our product, but in our process. If we didn’t innovate in our process, then we got pushed out of market by becoming too slow, too expensive, or by lacking the quality experience that customers have come to expect.
But not everybody knows what a great environment for helping people thrive and do great things for the world, looks like.
While a lot of people in software or in manufacturing have gotten a taste of Agile and Lean practices, there are many more businesses that don’t know what a modern learning machine of people and processes that operate at a higher-level looks like.
Many, many businesses and people are still operating and looking at the world through the lens of old world management principles.
In the book The Future of Management, Gary Hamel walks through the principles upon which modern management is based.The Principles of Modern Management
Hamel gives us a nice way to frame looking at the modern management principles, by looking at their application, and their intended goal.
Most people aren’t aware of the principles behind the management beliefs that they practice or preach. But before coming up with new ones, it helps to know what current management thinking is rooted in.
“Have you ever asked yourself, what are the deepest principles upon which your management beliefs are based? Probably not. Few executives, in my experience, have given much thought to the foundational principles that underlie their views on how to organize and manage. In that sense, they are as unaware of their management DNA as they are of their biological DNA. So before we set off in search of new management principles, we need to take a moment to understand the principles that comprise our current management genome, and how those tenets may limit organizational performance.”A Small Nucleus of Core Principles
It really comes down to a handful of core principles. These principles serve as the backbone for much of today’s management philosophy.
“These practices and processes of modern management have been built around a small nucleus of core principles: standardization, specialization, hierarchy, alignment, planning, and control, and the use of extrinsic rewards to shape human behavior.”How To Maximize Operational Efficiency and Reliability in Large-Scale Organizations
It’s not by chance that the early management thinkers came to the same conclusions. They were working on the same problems in a similar context. Of course, the challenge now is that the context has changed, and the early management principles are often like fish out of water.
“These principles were elucidated early in the 20th century by a small band of pioneering management thinkers -- individuals like Henri Fayol, Lyndall Urwick, Luther Gullick, and Max Weber. While each of these theorists had a slightly different take on the philosophical foundations of modern management, they all agreed on the principles just enumerated. This concordance is hardly surprising, since they were all focusing on the same problem: how to maximize operational efficiency and reliability in large-scale organizations. Nearly 100 years on, this is still the only problem that modern management is fully competent to address.”
If your management philosophy and guiding principles are nothing more than a set of hand me downs from previous generations, it might be time for a re-think.You Might Also Like
I grew up in the Pacific NW just south of Seattle in Tacoma, WA. One of my favorite cartoonists, Gary Larson, is from Tacoma. His cartoon The Far Side was a never-ending source of entertainment for me and later, my two boys. One cartoon that we all never seemed to tire of, answered the age-old question: “Where do boneless chickens come from?” It also led to the follow-on question of “What do boneless chickens do all day?” (Answer: Lay around wondering how they can cross the road to prove to the Possum that it can be done!).
Why is this important? How does this relate to agile? Even if we ignore for a moment the Scrum-concept of “pigs” and “chickens”; quite a lot actually.
Many companies see “agile” as a silver-bullet that can magically transform their “everyone’s busy but we’re unable to make-and-meet commitments; and when we do, its typically late and of poorer quality than we care to admit!” circumstances. Often times they think that knowledge is the answer and that simply attending agile training will be the key to their future success. Many even instantiate an “agile pilot” somewhere within their organization with their recent agile training attendees. The company decouples the pilot from all current process and “administrivia” that puts a drag on other company efforts to ensure the pilot’s success. It works!! Unfortunately, when they try to implement agile within the rest of the organization “agile” fails for them! Just like the boneless chickens in the cartoon … all knowledge and muscle without the bone structure support necessary to move successfully.
Therefore, at LeadingAgile we (highly) encourage organizations to lead with Structure, Governance and Metrics first, THEN train.
We’ve found that there are two basic areas that companies must address to be successful in applying agile at scale:
a) Willingness to establish and maintain dedicated teams; and
b) Flowing work in the form of User Stories that is ready to be pulled/delivered successfully within a sprint by Delivery Team(s).
Structure is about putting in place dedicated teams at the both the Portfolio and Program levels as well as Delivery/Service Team level. Structure in this instance is NOT about re-drawing Org Charts! It is about choosing to bring work to (teams of) people as opposed to bringing people to the work (aka “projects” / managing utilization).
Establishing dedicated team structure demonstrates the organization’s acknowledgement of and commitment to successfully connect corporate strategy/vision to execution in an agile fashion. Governance, in this paradigm, is then how each of these team’s (at each level) “work with each other”. Governance and structure together enable the organization to identify, prioritize and progressively elaborate potential work while limiting overall Work in Process (WIP). They are essential to managing risks/dependencies proactively. Putting structure and governance in place first forces conversations around dependencies (coupling) that, if ignored, put at risk the Delivery team(s) ability to successfully meet commitments. The cadence throughout this agile structure is adjusted to the proven velocity or organization’s capacity to deliver working/tested code that is ready (potentially) be deployed. Finally, Metrics enable the organization to both tie value delivered back to the overall strategy/vision as well as enable business leadership to see the agile transformation’s progress.
Structure, governance and metrics support the organization’s ability to empirically adjust as conditions dictate. They are the critical “bones” that both agile training and coaching hang from as the organization begins its agile walk. Without structure, governance and metrics already in-place the organization doesn’t have the internal support it needs to absorb and respond to the challenges and impediments that always arise when implementing change.
So go on! Ensure your agile chickens aren’t “boneless”! Your agile “pigs” will thank you!
Photo Courtesy of The Far Side © Gary Larson
Ja, es gibt sie, die Scaled Agile Frameworks - also die Modelle, Blaupausen und Ideen, wie man mit Scrum und Kanban ganze Organisationen agilisiert. Ich selbst habe die ersten Ergebnisse dazu auf Konferenzen erzählt und u.a. 2005 in einer verteilten Organisation das Konzept der Chief Product Owner, Chief ScrumMaster, der Product Owner Teams, des Company Backlogs vielleicht nicht als Erster, aber doch zeitgleich mit den damals gerade ablaufenden Entwicklungen in den USA ausgearbeitet. Doch das waren immer Schablonen. Ich bin nie davon ausgegangen, dass man in einer großen Organisation einfach ein Schema F einführen kann und schon ist man fertig. Wäre das so, hätte ich nicht das Buch “Das Scrum-Prinzip” geschrieben, in dem ich zeige, dass jede große Veränderung nur entlang der Widerstände in einer Organisation geschehen kann.
Doch heute wollen viele noch stärker als vor einigen Jahren den Quick-Fix. Es soll von oben Agilität ausgerollt werden. Damit tut man der Organisation und den Menschen in der Organisation Gewalt an. Versuchen wir doch mal, die Blaupausen nur als das zu sehen, was sie sein können: Wegweiser. Wie wäre es, neben diesen Wegweisern noch ein paar Prinzipien einzuführen, die wie von selbst zur Agilität führen? Prinzipien, die zwar nicht auf die Schnelle, aber sicher aus einer Organisation eine agile Organisation machen?Wer Agilität will, muss führen
Zunächst: Wer Agilität einführen will, muss führen. Also eine Vision ausgeben, sich selbst dabei im Klaren sein, warum man das will, und dann voller Begeisterung selbst loslaufen – ohne zu schauen, ob noch jemand mitkommt. Diese Lektion habe ich von meinem Pferd Rubiano gelernt. Wenn ich mich umdrehe, schauen will, ob er mitkommt, bleibt er stehen. Was logisch ist, denn ich sage ihm ja: “Bleib stehen.”
Genauso ist es mit der eigenen Organisation: Wer losläuft, der muss sich sicher sein, dass die anderen mitkommen werden. Und wie ist man sich dessen sicher? Es gibt ein simples Prinzip, auch das hat mir mein Pferd beigebracht: Ein Pferd läuft immer freiwillig mit. Probiert es aus! Versucht doch mal ein Pferd aufzuhalten, dass beschlossen hat, in eine andere Richtung zu gehen als ihr. 500 kg bewegte Masse hält man nicht so einfach auf. Jedenfalls nicht mit einem Führstrick.
Genau das Gleiche – und das meine ich wirklich so – erlebe ich in allen Organisationen, mit denen wir arbeiten, und ich erlebe es in meinem eigenen kleinen Unternehmen. Kollegen gehen mit, wenn sie wollen. Wenn sie sich selbst in die Richtung bewegen wollen, in die ich führe. Und ja – ich führe. Meine Kunden, meine Coachees und meine Kollegen. Jeder Facilitator mag das bestreiten, aber sogar er oder sie führt – immer. Denn der, der den Überblick behält und den Kontext steuert, der führt. Aber der entscheidende Aspekt ist: Zu diesem Prinzip der Führung gehört Freiwilligkeit. Sich dessen wieder klar zu werden ist der erste Schritt zu jeder gelungenen Veränderung hin zu einer agilen Organisation.
Das ist nicht einfach. Ich kann euch dazu nur empfehlen, “Turn the Ship Around” von L. David Marquet zu lesen. In diesem wundervollen Buch sagt Marquet immer wieder, dass es ihm schwer fällt, seine eigenen Überzeugungen zu leben, denn sie liegen quer zu all dem, was wir in der Arbeitswelt der letzten Jahrzehnte gelernt haben. Rückfälle sind also vorprogramiert – na und. Zur agilen Organisation gibt es keinen Weg ohne Sackgassen und Umwege. Wichtig ist das Loslaufen, das Ziel vielleicht vor Augen.
- Mit Kanban kann man alles machen – auch vieles falsch
- Führung ist?
- Entschuldigen Sie bitte, wie lösen Sie Ihre Probleme?
“Forget your perfect offering. There is a crack, a crack in everything. That’s how the light gets in.”
How’s that for a weird quote? I heard it the other day on the radio and it stuck in my head. It has a resonance for me that I just can’t seem to shake. You see, like most folks, I’m intimately familiar with imperfection. I’m faced with it in many of the projects I’m most passionate about: My writing, my career, my boat…
Yeah, I’m building a boat. Technically, it’s my second boat. I think just admitting that qualifies one as insane. The first boat was a mere 9 foot skiff I made for my daughters. It took me almost 3 years to complete it. I should probably mention that I have absolutely no woodworking skills. So after I finished the first one, I decided to build another. This second boat is just for me. Well, me and my brother actually. We’re building it together in his garage. We’re about a year into it so far and it’s coming along pretty well.
OK, honestly it’s a little early to tell. We make a lot of mistakes.
I don’t know what it is about working with wood, but any mistakes you make tend to jump right out at you. Of course, the bigger the project the more room there seems to be for error. I’m discovering that a 17 foot boat leaves lots of room for error. Cutting parts to shape is hard. Getting screws to bite and not strip. Glue everywhere. One false move with a power tool and there are splinters galore. The whole project really is just a glorious catastrophe waiting to happen.
If ever there were a case study in failure, this boat is it for me. Now that might sound terribly defeatist, but it’s not meant to. You see, I’ll finish this boat too, one way or another. It’s just that I’ve got a whole lot of failing to do in between now and the day I finally launch her.
Of course, given all this failing, it’s still pretty astonishing how slowly I manage to learn. For instance, I’m noticing that I don’t seem to give up my standard ways of learning, even in the face of overwhelming evidence that they are not paying dividends. I’m fairly sure I’m not alone in this behavior.
First there is my innate impatience to see quick results. This whole measure twice, cut once thing just doesn’t seem to come naturally. For some reason I’m always in a rush. I find it extraordinarily difficult to slow down and just take my time. Maybe it’s some american thing where we are just impatient with anything that impedes progress…No, I don’t buy that either. I think slowing down is really hard work. It takes discipline to slow down and treat things in a very thoughtful and conscientious manner.
Savoring the moment and appreciating how things feel in the moment is not something that just happens to you. You have to make time for it. I can show you all of the places on the boat where I rushed the job. The places where I tried to drive the screws in with a power drill (I drove them right through the panels – genius!). The areas where the wood split because I didn’t take the time to test the bend first. The evidence of my own impatience is writ large in the construction of this boat.
Do you want to know the really amazing part? I still keep rushing!
Scary. Did I mention that slowing down is hard?
Another area where I struggle to learn: working as a team. Working as a team is hard too. First you have to keep those you are working with in mind all the time. That doesn’t come naturally at all for me. I’ve never really been a good team player. I grew up participating in individual sports like running, wrestling and weightlifting. I operate very well solo. Working as a team has been an alien experience. For example, when my brother and I are working on the boat, I often struggle to figure out what he can do to help. I’ve seen this on software development teams too. Ask a developer what needs to be done, and you will get a detailed list of all of the work that remains. No problem. Ask that same developer how someone else can help them get that work done, and often you will get a blank look. When you are not accustomed to working on a team, it’s hard to picture what teamwork looks like.
To make matters worse, my brother and I have different skill levels when it comes to woodworking. This means that sometimes I need to take the time to show my brother how to do things (or vice versa). I find that hard to do when I’m rushing to get things done (see above). But without taking that time to show him how to do things, I lose the benefit of his help. I lose the teamwork. I’m finding that teamwork takes some serious patience. Ultimately I know I will go faster if both my brother and I can work at the same level, but that means initially I will have to slow down to achieve that goal. Slowing down to go faster.
I’m very lucky to have someone to like my brother to put up with all my mistakes. In a peculiar way, building a boat with him is teaching me a lot about software development. That’s probably good, because God knows if we’re ever going to finish that boat.
Filed under: Agile, practice, Teams Tagged: Agile, boat, brother, failure, improvement, Mistakes, sailing
1. Write a test, it fails (no code to test yet) (Red)
2. Write just enough code to make the test pass (Green)
3. Refactor the code (AND the test code), keeping the test passing
3A. (This is where any simple logic would be written)
When satisfied, start over with a new test.
I find that step 3A is where we lose a lot of folks. Simple logic pretty much includes a calculation or deterministic algorithm. If there is any kind of branch statement - IF, SWITCH, etc. these should all be coded only as a result of new tests.
If we stay with this approach, we will have valuable information about the state of our code and a mechanism to make sure the code actually does what we wanted it to do.
I subscribe to a newsletter from Projects at Work which I rarely read. I happened to open it this month and stumbled upon a gem. 5 Ways to Improve Time Tracking It prompted this post… 5 Reasons to Kill Time Sheets I have a strong dislike to time tracking, especially on software projects and here […]