I know of no industry in the world that is as infested with methods and frameworks as the software business. Whether it’s RUP, XP, Scrum, AUP, DAD, or SAFe, it seems IT businesses are always looking for yet another method or framework that they can “implement” next month.
As a retailer, how often do you come into contact with filmmaking? Not very often. How often do you come into contact with road building? Except when you are stuck in traffic due to a construction site, not very often.
How often do you come into contact with IT? Every business comes in contact with IT. Whether to sell on online, automate processes, manage work, or whatever, every IT and software are everywhere. And IT projects can be extremely complex and failure is quite common.
And IT is so widespread, there aren't enough experts to go around -- or why does Jurgen tour the world to promote his book and his framework, instead of working with individual companies to help them improve?
Most people have no idea where to begin. Our instincts from our hunter-gatherer phases evolution are often counter-productive. So frameworks are essential. They are reasonably well understood place to start. Some of them even work pretty well, like Scrum (or even Kanban ;-) if you apply them reasonable well. And this is hard part.
For some more research-driven explanations as to why frameworks are helpful, see Chip and Dan Heath's book: Switch, or How to Change when Change is Hard. Their example on Minimally Invasive Cardiac Surgery is particularly illuminating. Taking on a new complex activity requires a good place to start, a lot of practice, and a willingness to learn.
In “Design Thinking für Product Owner – Teil 1″ habe ich die Frage untersucht warum Design Thinking für den Product Owner wichtig ist. Heute will ich einen besonders wichtigen Punkt ansprechen: Bei der Gestaltung eines Produkts geht es immer um Menschen. Daher lautet die Frage: Wie sollte ein Design-Thinking-Team zusammengesetzt sein?Allein ist der Product Owner
Der Product Owner soll die Produktvision schmieden und für das Entwicklungs-Team greifbar machen. Zuweilen steht er allein da, mit der Verantwortung für die Priorisierung des Backlogs und mit der Verantwortung für die Profitabilität des Projekts. Denn woher weiß er genau, was der Nutzer jetzt oder bald wirklich benötigt?
Ist es der Kunde, der den Nutzer kennt und dieses Wissen ohne Reibungsverluste an den PO weitergeben kann? Oder ist der PO einfach ein genialer Erfinder mit dem richtigen Gespür für den Markt?
Besser ist es, wenn der PO selbst den Nutzer und dessen Bedürfnisse kennt und davon die passende und machbare Lösungen ableiten kann. Dafür bietet sich Design Thinking an: Produktideen werden direkt am Nutzerbedürfnis entlang entwickelt und getestet, der PO erarbeitet dies gemeinsam mit einem starken Team und kann danach mit voller Überzeugung die Produktvision vertreten. Der Product Owner ist hierbei oft die einzige konstante Person und daher extrem wertvoll, wenn es darum geht das gewonnene Wissen aus dem Design-Thinking in den Scrum Flow zu übertragen.
Design-Thinking ist eine strukturierte aber bunte Mixtur aus Methoden unterschiedlicher Disziplinen, um innovative Lösungen für komplexe Probleme zu erarbeiten. Genauso unterschiedlich (interdisziplinär) sollte auch die Zusammenstellung der Menschen im Design-Thinking Team sein. Der Nutzen der Interdisziplinarität ist die Perspektivenvielfalt. Diese sollte als Schatz begriffen werden, denn bei guter Moderation hilft das, schneller den “richtigen” Blick zu finden und schneller passende Ergebnisse zu liefern.
Dabei braucht es weniger den Experten oder Erfinder im Team, denn der Design-Thinking-Prozess ist so angelegt, dass die Teammitglieder in kürzester Zeit selbst zu Experten werden. Vielmehr sind Menschen nötig, die intelligent und neugierig sind und Lust haben, sich gegenseitig zu inspirieren und gemeinsam zu lernen. Die erfinderische Kraft entspringt dabei der gesamten Gruppe und ist keine Einzelleistung.
Eine grundlegender Unterschied ist in der Zusammensetzung der Teams zu finden. Design-Thinking-Teams sollen interdisziplinär und Scrum-Teams cross-funktional zusammen gesetzt werden. Cross-funktional bedeutet in Scrum-Teams: Alle Expertisen, die zur Erstellung der versprochenen Funktionalität gebraucht werden, sollen innerhalb des Teams vorhanden sein, z.B. Programmierung, Datenbanken & Testing.
Interdisziplinär bedeutet in Design-Thinking-Teams, dass der Programmierer mit einer Juristin und einer Ärztin, einem Philosophen und einem Fotografen und vielleicht noch mit einem Extreme-User arbeitet. Diese Vielfalt hilft, komplexe Probleme von allen Seiten zu beleuchten.
Man kann nun argumentieren, dass in einer weiten Betrachtung “cross-funktional” für Design-Thinking-Phasen eben auch “interdisziplinär” bedeutet. In der praktischen Anwendung ist lediglich wichtig:
Das Design-Thinking-Team besteht aus dem PO und gelegentlich ein bis zwei weiteren Mitgliedern des Scrum-Teams und braucht darüber hinaus noch 3-5 Teilnehmer aus ganz anderen Arbeitsfeldern. Das Team sollte insgesamt 5-7 Personen umfassen und benötigt zusätzlich einen professionellen Design-Thinking-Coach.
Im Konzernumfeld ist es oft sehr schwer, “echte” Nutzer, Kunden und andere externe Personen in das Team zu integrieren. In diesem Fall sollten zumindest Teilnehmer aus anderen Linien wie Personal, Einkauf, Sales, Logistik etc. in das Design-Thinking-Team aufgenommen werden. Es ist erstaunlich, wie sich der Horizont erweitert, wenn eine intelligente Person zur anderen intelligenten Person sagt: “Das verstehe ich nicht, erklär mir noch ein mal warum?” Und damit alteingesessene Denkmuster hinterfragt.
Thema der kommenden Beiträge zu “Design Thinking für Product Owner” wird die Kombination von Design Thinking mit Scrum sein.
Bei Fragen oder Anregungen zu diesem Thema freue ich mich über Ihre Nachricht.
- Produktfindung mit Design Thinking
- Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?
- 5 min on Scrum | Small Project(s) (-teams)
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
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?
How diversity helps us in problem solving, creativity and overall intelligence? It helps a lot. Diverse groups of people can produce better results and radiate more creativity. But what about your own, personal diversity? Is it a good idea to accumulate knowledge from wide range of disciplines? Does knowledge of music theory help to write better code? Does knowledge from biology make you a better user experience designer? I believe yes, and here is why.Escher Butterfly Wallpaper by MPCine
Douglas Hofstadter and Emmanuel Sander wrote a very controversial book Surfaces and Essences. It is not an easy read, but it is time spent well. Authors unfold thinking process from language to high level constructs. They show how analogy-making helps us think, generate new ideas and fuel our creativity, including scientific insights.
This book deeply resonated with me. In general I agree that analogy-making is a core of our creativity. I even tried to apply knowledge from Running domain to Software Development domain and generated some quite interesting ideas like Interval development. Sure these ideas can’t be proved easily, since analogy doesn’t mean the idea is great. But still it is relatively easy to take knowledge from one domain and apply it to another domain.How can it help me?
All that brought me to the idea to increase my personal diversity and expand my knowledge beyond typical areas like system thinking, software architecture, groups dynamic, innovation models, user experience and other stuff every CEO learns. I read books and took courses about quite diverse topics already, but I did that in a chaotic way.
Suddenly it became obvious to me how all these new domains can help me to be more creative and solve problems better.What domains should I explore?
I think you should try anything you always wanted to learn, but didn’t have time to. It is quite hard to predict what analogies can be generated from unknown domains. For example, you always wanted to know how people paint, how art evolved and how Michelangelo painted a fresco of The Last Judgement on the altar wall of the Sistine Chapel. Dig into the art domain and learn as much as you can in a single year. Will it help you to be a better software developer? Why not? If you try to paint something you can train patience and learn how to sketch (everybody should sketch, you know). Michelangelo’s approaches may give you some ideas how to structure your work. As I said, it is hard to predict exact ideas that you’ll generate in the end, but I promise you will generate some.
I personally want to study biology, music theory, architecture, education, medicine, go and swimming. If a simple running domain gave me new insights, I believe larger and more complex domains will bring even more value.Why one year?
A year is a good timeframe to focus on something. It will be your new hobby for a full year. You can read 20+ books, take 1-3 online courses, maybe take offline courses, try to apply your new knowledge constantly. Small domains demand less time, but larger domains are hard to grasp in 2-3 months.
I don’t believe in quick solutions. You can read a book or two about a subject and have some fresh air in your head, but it is not enough to just scratch the surface. In 10 years you will have a decent knowledge in 10 domains. That sounds cool to me.Did you try that?
Nope. I started to dig into music theory recently. So far I’m just sharing the idea with a hope that there is always a chance you’ll like it and give it a try.
And maybe, just maybe, you’ll even find your new passion. Who knows?
This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.
I haven’t visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I’m in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.
How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don’t get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How’s that happened?
Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?
There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.
SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won’t work in many cases, and you can’t fix it without context-awareness.
SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don’t believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.
So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.
I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C’mon, folks, this separation is childish.
All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:
- Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
- Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don’t do that on sessions as well?
- There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
- Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
- 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I’d like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.
In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can’t imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.
The final thing is the slogan I saw yesterday. It is just unbearable to me: “Allow agile and waterfall work together” WTF?
I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.
“Pirates are bold not safe” — These guys are doing something good
Last week, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla presented a webinar about “Fast IT,” a new way of managing rapidly changing and Agile projects in areas like mobile, Web, analytics and marketing applications, while working smoothly with reliable core systems ("Core IT"). Andy discussed the dynamics of Fast IT, and Sid presented a case study of how Attivio spun up a major Business Intelligence app in two weeks with two people.
If you missed the webinar, view and download the slides.
Want an overview of Fast IT in 60 seconds? Watch the video below:
Get notified about new and exciting content around Fast IT by completing the form below:
Paying for your Assembla subscription with PayPal has never been easier. We recently added the ability to set up recurring payments with PayPal that will automatically pay for your Assembla subscription every billing period, whether that be monthly or annually. Previously, it was a manual process that required logging in and paying every time an invoice was created.
To set up automatic payments with PayPal, visit your billing page > select the PayPal option > and follow the steps.
If you have any questions or issues, please contact Assembla support at firstname.lastname@example.org.
Last week one of our stakeholders brought his pug dog, Lola, along to our product review meeting. “Watch out, she likes feet!” he joked but she remained quiet and well behaved throughout the meeting. Unruly is not the only place I’ve come across where dogs have been accommodated at work, another had a dog basket in their main board room. I appreciate not everyone likes dogs around but I like working for a company that’s not too stuffy to allow people flexibility to make our workplace more homely.
We’re lucky at Unruly to have a dedicated People & Places team who work closely with our Design team create a work environment that has personal touches. There are many informal meeting places around the building to make collaboration easy and it’s decorated with original artwork reflecting our culture. Little things amaze visitors as we show them around, for instance we created a two-way webcam portal between our London and New York office with a gold antique-style frame, which makes it seem more special and echoes Harry Potter where characters move around. What’s the business case? Creating an environment that allows human expression encourages creativity to flourish in our work.
The design of our workspace is not owned by a central team outside development. We recently reorganised our desks and unlike many companies, where a "Desk Move" is a dreaded logistical nightmare involving packing things up for another team to execute overnight, our developers simply got stuck into disassembling desks and lifting floor tiles themselves to get everything in the right place. Our spirit of collective ownership and taking responsibility for how our code structured seems to extend out to our surroundings. Taking care of our workspace, isn’t somebody else’s job.
Our teams use our walls and whiteboards for practical purposes but with a sense of humour too. Even electronic tools get a bit of customisation, we use Trello for our backlogs and teams can add distinctive backgrounds to make them easier to pick out.
Teams in bigger companies often find that their boards are the easiest areas to start personalising, when you introduce Kanban boards you can involve everyone on the team in designing the layout. Rather than diving straight in to moving things around, you can create a mini-version of the new layout with sticky notes. I think it’s important to give everyone on the team the opportunity to mull the proposed design over and allow time for tweaks. We’ve taken this approach with how we lay out our boards and our desks (as in the examples below).
I appreciate that many people work in organisations that don’t actively support personalisation of the workspace but you can start small with a potted plant, a team mascot, a little whiteboard artwork. You'll likely find personal touches are noticed and soon start to spread around surrounding teams. Another small step that you can take is to adopt iteration names or pictures that pick up on what’s going on in the outside world or reflect metaphorically on current mood within the team. In software development, we spend a lot of time in an office environment, taking care of your surroundings helps to take care of the people working within them.
XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.
To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.
Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.
As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is more than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scatches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.
As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).
We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.
There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resiliant to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!
If your team uses Slack, HipChat, Flowdock, or Bigplans for communication, we have added preconfigured webhooks to make setting up these integrations painless. Once configured, you can selectively manage the Assembla events that are posted out to these apps, such as ticket activity, commits, deploys, etc., to monitor project activity in real-time, inline with other team communication.To get started, click on the desired integration below:
Ripple is a protocol for value exchange that makes it easy to transfer and trade fiat currencies, Bitcoin, or XRP - the native asset of the Ripple network.
Assembla is giving away 1000 free XRP (the Ripple native cyptocurrency) to any person with software development skills who is interested in learning about Ripple development. Get it here: https://www.assembla.com/ripple
I called Ripple Labs a few months ago to find out more about ways that their "gateway" can help us pay developers in many different countries. Essentially, we do banking for the developers on our global team. We pay internal accounts, hold the money until they ask for it, and then transfer money to them by bank wire, ATM/Payoneer, or other mechanisms. We have found that the bank wire system is embarrassingly slow and unreliable. This is the problem that Ripple is trying to fix. Their gateway is like a bank in an open-source box. It keeps accounts in any currency, including USD, other currencies, XRP, and Bitcoin. It can transfer those accounts instantly and reliably on the shared "ledger." It is also gaining exciting new features such as "multi-signature" which enables outsourcing and crowdsourcing customers to post a budget amount, and then transfer it to their hard-working suppliers through an arbitrator.
Now I am working more closely with Ripple to help them scale up their development process. I decided to make this free XRP offer for two reasons:
- Users need 20 XRP to activate a Ripple wallet. We want to remove the hassle from acquiring the XRP so new developers can get started.
- We want to build an email list of developers that might be interested in working on internal development, bounties, or bank integration projects.
If you use Assembla and Bigplans, we have added a pre-configured webhook making it easy to post Assembla events out to your Bigplans chat room. Check out below for configuration instructions.
Bigplans is a simple, integrated way to manage a distributed team. It includes a "lean" task board, real-time chat, and a unique "advisor" (a real person) that helps you get on-demand resources if you need them. For programming teams, it includes a tight integration with Assembla login and Assembla tickets.
You can use the Webhooks tool to feed Assembla events into any of your team chats. To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select Bigplans from the list of pre-configured post options:
You will need to obtain and update the auth token in the “Content” section.
To obtain your Bigplans auth token:
Visit Bigplans and navigate to the plan you want to post Assembla events to. Click on the ‘Connect’ option in the top bar. Under the “Message API” section, there is a section called “API Token” that will display your token. If no token is set, click on the ‘Reset’ button. Copy the token ID and replace the “BIGPLANS_AUTH_TOKEN” in the Webhook tool.
Now configure what Assembla events you would like to post to your Bigplans chat room and click ‘Add and Authenticate.” Don’t forget to enable the configuration under the “Title” field.
Your Assembla events will now be posted to the configured Bigplans chat room:
If you use Assembla and Slack, we have added a pre-configured webhook making it easy to post Assembla events out to your Slack chat room/channel. Check out below for configuration instructions.
To get started, you will need the Webhook tool installed in the Assembla project you want to configure. If you do not have the Webhook tool installed, visit the Admin tab > Tools section > and click ‘Add’ next to the Webhook tool.
Once installed, click on the Webhook tool in your main navigation and select Slack from the list of pre-configured post options:
You will need to setup an incoming webhook service integration within Slack to obtain your token. To do this, visit https://YourSubdomain.slack.com/services/new/incoming-webhook, select the desired channel to post to, and click ‘Add Incoming Webhook.’
Once created, copy the provided Webhook URL and update the External URL in Assembla’s Webhook tool.
Now configure what Assembla events you would like to post to your Slack room/channel and click ‘Add and Authenticate.' Don’t forget to enable the configuration under the “Title” field.
Tip: Within the Slack “Incoming Webhook” page that you set up for this integration, you can scroll to the bottom of the page and expand the “Integration Settings” where you can add a label, change the post-to channel, and change the icon and name for your webhook bot.
Your Assembla events will now be posted to the configured Slack room/channel: