Sprintly is excited to announce the Bugsnag integration. Bugsnag detects and diagnoses crashes in your applications and now you can set up Bugsnag to automatically create defects within Sprintly. Read more about Bugsnag and the integration on Bugsnag’s blog!
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Most folks have heard the old adage that you never discuss religion or politics in polite company. Frankly, I’m guilty of both because I think it’s fun and I can take it. As a society, I think it’s time to consider a third category of zealotry that needs to be banned from our fancy dinner parties… agile methodology.
You’re probably wondering now what it’s like to go to a party with me, and why the hell would I be talking about agile at dinner for anyway… but that is beside the point. The problem is that some of us can’t seem to talk about agile without getting really upset and taking disagreement way too personally.
The past few nights I’ve been entertaining myself by posting controversial topics on my Facebook page. My goal is to see if we can spin up some lively discussion. Last nights topic was on the minimum wage in the US and the role of government in controlling such things.
People have very strong opinions about these topics. Many folks come at the discussion from the position of social justice and doing what’s right. Some approach it from a systems perspective and the impact such controls have on society. Some believe a free unregulated economy should determine the prices on goods and services.
What was interesting about the discussion, and I was really trying hard to facilitate a discussion… not a debate… was how personally people connect with these topics. It’s not some abstract political discussion, it’s about the people we know, our families, and how we perceive the world around us.
Religion as you might imagine is even more difficult. How do you have polite conversation about what you believe about God? It transcends the academic and moves into our soul. Questioning my faith isn’t about examining historical facts, it’s about the very foundation of my belief system.
Often, religion has a huge role in how we were raised as children, the relationship we have with our parents, our social structures, and how sure we are about the afterlife or the lack of it. It sets the tone and the underlying foundation for how we view the world around us.
Folks have a hard time distinguishing between a simple academic discussion and a personal attack on who I am as a person. The issues strike that close to our core.
Sometimes I feel like we get this way about agile… at least those of us that live, breath, and eat this stuff. Those of us who are zealots about one methodology or the other. Those of us who write books, publish blogs, and tweet incessantly about the topic… we are all pretty strongly opinionated.
Sometimes the conversation isn’t really about the merits of my methodology against your methodology… it’s more personal than that. It’s more about my perception of the world (and my place in it) in violent opposition to your perception of the world (and your place in it).
It can tie into issues of economic security if my business is built around one approach or the other. It might trigger ego issues if I happen to be heavily invested in one particular approach… as either an inventor or well known thought leader. It might just be that my experience simply isn’t your experience.
Many of us have a lot of experience and we’ve seen lot’s of stuff work. What I find absent from many of the online conversation is context. We are so busy arguing about what is right, what is wrong, what works, and what doesn’t… sometimes I think we forget that all of this stuff has worked in one context or the other.
Personally… I have made waterfall work beautifully at scale. I have made textbook RUP work. I have made Scrum, XP, RUP, and Waterfall hybrids work. More recently we’ve blended Scrum, XP, and lean program and portfolio governance into dynamic, situationally specific models for our clients… and it works.
I tell my clients quite often that most everyone they’ll talk to in this space is a consultant. We all have a point of view, we all have something to sell. Sometimes having something to sell get’s in the way of doing the right thing, or even going off message for the sake of the clients success.
I’d love to see more of our conversation start with context. What did you experience? Why did you experience it? What was it about the context you were in that led to your choices? What were your constraints? What worked? What didn’t? What would you have done differently next time or in a different context?
Wether it be religion, politics, or agile… I think some genuine desire to understand each other, and each other’s perspectives, would go along way to more constructive dialog and more meaningful outcomes.
Neulich bin ich über einen Blog gestolpert, in dem stand, dass der Posten eines klassischen Produkt Managers attraktiver und prestigeträchtiger sei, als der eines Product Owners. Für “agile Stellen” gäbe es kaum durchdachte Karrieremodelle, weshalb sich BewerberInnen lieber für klassische Stellen entschieden. Die Scrum-Methodik ist außerhalb der IT noch ein relativ unbekanntes Vorgehensmodell. Viele Außenstehende können mit den Begriffen “agile Organisation”, “ScrumMaster” oder “Product Owner” nichts anfangen. Sie kennen weder die Vorteile, noch die Herausforderungen, die damit einhergehen. Wahrscheinlich einer der Gründe, warum es so schwierig ist, diese Stellen zu besetzen und geeignete Kandidaten am Markt zu finden.
In bereits agilen Organisationen kämpfen wir mit einem anderen, aber damit zusammenhängenden Problem. Die von uns ausgebildeten ScrumMaster, die schon seit einiger Zeit in dieser Rolle tätig sind, kommen jetzt an einen Punkt, an dem sie sich fragen: “Wie geht es weiter?” Was sind meine nächsten Karriereschritte? Wie rechtfertige ich meine Gehaltserhöhung? Das Management fühlt sich mit diesen Fragen verunsichert, da es keine Antworten liefern kann. Bisher hat sich schlicht noch niemand wirklich damit auseinandergesetzt, wie man beispielsweise ScrumMaster weiterhin an das Unternehmen binden kann.
Beiden dieser Szenarien liegt zugrunde, dass die Personalabteilungen bisher keine Möglichkeiten hatten, geeignete Konzepte für ihre Mitarbeiter zu erstellen. Die Kernaufgabe von Human-Ressource-Abteilungen ist es, Personal sicherzustellen und gezielt einzusetzen. Die HR war bisher aber so weit von der Produktentwicklung entfernt, dass sie sich gar keine Gedanken machen konnte.
Tja, aber was jetzt? Für Unternehmen, die kurz vor einer Scrum- Implementierung stehen: Nehmt eure Personalabteilungen von Anfang an mit! Die Veränderung betrifft auch sie! Sie brauchen Vorlauf um neue Konzepte für ihre Personalplanung und -weiterentwicklung zu erstellen. Auch das Recruiting von agilem Personal muss gelernt werden. Ausgehend vom Anforderungsprofil bis zum tatsächlichen Bewerbungsgespräch. Welche Skills braucht ein ScrumMaster? Welches Fachwissen sollte ein Product Onwer mitnehmen? Je früher die Personaler abgeholt werden, desto schneller können sie auf die Bedürfnisse eurer Mitarbeiter reagieren.
Für Unternehmen, die schon seit einiger Zeit agil arbeiten, ist es wichtig, den etablierten Prozess so transparent wie möglich auch der restlichen Organisation vorzustellen. Eure Kollegen aus der Personalabteilung sind Experten, wenn es um den planmäßigen Einsatz der Arbeitskraft von Mitarbeitern geht. Wenn sie erst einmal verstanden haben, wie ihr arbeitet und welches Produkt euch gerade Bauchschmerzen bereitet, können sie helfen, eure Produktivität sicherzustellen und die Veränderung mit euch gemeinsam voranzutreiben. So kann zum Beispiel auf mangelndes Branchenwissen der Prodct Owner mit geeigneten Weiterbildungsmaßnahmen reagiert werden.
In unserer täglichen Arbeit als Berater sind wir zur Überzeugung gelangt, dass die HR als Partner des Managements dafür verantwortlich ist, die Produktivität des Unternehmens sicherzustellen! Wenn das gelingt, entscheiden sich zukünftig immer mehr qualifizierte Leute, eine Stelle in einem agilen Unternehmen anzutreten und bereits tätige ScrumMaster oder Product Owner sehen mehr Vielfalt in den Möglichkeiten am Markt.
Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release.
One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all along—they have “delivered,” but the deliverables don’t work.
Now, say you’re halfway through the desired program time. You, as a program manager, can see that this program is in trouble. That one team is not going to make it. What do you do?
This us where you start talking to people and understanding what the value of everything is.
- Does the program need everything on that team’s backlog?
- Does the program need everything on other team’s backlogs?
- Does the program product owner understand the cost of delay?
- How about the sponsors for the program? Do they know what’s going on?
Take out your back of the napkin calculation and show it to anyone who will listen.
Does the team understand the problem of lateness, as we discussed in part 1? They might. They might be overwhelmed by the technical difficulty of what they are doing. Maybe their stories are huge. Maybe they aren’t so hot at agile. Maybe they aren’t working in an agile way. There are 1001 reasons for this problem. If you are a manager of any stripe, program manager, development manager, whatever, you are responsible for understanding first, not yelling. (I often see senior development managers, VP Engineering encountering this, not realizing that they are the program managers in this situation.)
Does the program product owner really need everything in their backlog? It’s time to consider how little can that team do, and still deliver something of value. Or, it’s time to consider how little other teams do and still deliver something of value. Or, it’s time to rejigger who is doing what. Otherwise, you are going to lose the money in the middle of the revenue stream.
Are the teams working by layer, front end, middleware, back end, instead of through the architecture?
Something has to change in this program. You are not going to make the desired date. This problem is a larger case of the not shipping on time problem, but it’s not just one team. It involves more teams. And, with a program, it involves more money. It’s almost always a bigger stake.
This is when you want to start considering cost of delay for features. Yes, not just for releases, but for features.
Each feature has value when you deliver it at a certain time. Before a certain time, it might have more or less value. After a certain time, it has less value.
Who knows when that time is? Who can make these decisions in your organization. Sometimes that person is called a product owner, a product manager, or, gasp, a customer. Sometimes, that person is called a Marketing Manager or Director, or even a CEO. Rarely is that person called a developer or tester, or even a development manager or test manager or an Engineering manager or CIO or VP of Engineering. Sometimes the product development side knows. Almost never does the product development team know by themselves.
If you make decisions as a cross-functional team, product development and marketing, you can get the best of both worlds. You can learn about the technical risks—especially good if the team is having technical problems. You can learn about the cost of delay risks—especially good from the customer perspective. Now, you can make a decision about what to do for the good of the program.
You have to optimize for the program’s throughput, not any one team’s throughput.
In my world, you work with the team: do they want to stay together? Are they working well together, and having a tough time technically? If so, the team has many options:
- The team can ask for technical help from another team (get an architect/designer to work with the team)
- The team can split their backlog among several other teams, to give them a fighting chance.
- If the team is not working well together (and they will tell you if they are still storming), offer them a chance to split. Or, you can facilitate a better working relationship so they can work well together.
If you don’t ask the team, you don’t know what’s wrong.
The problem with this cost of delay is that it’s tricky to discuss, it’s tricky to estimate, and it’s tricky to fix. It’s real. I bet you’ve seen it.
I would take out the napkin and remind the team that their delay costs the entire program. I want to help them remove that delay.
If you are using a waterfall approach to your programs, this cost of delay is invisible until the end of the program, when testing occurs. Why? Because that’s when you start to see features emerge.
If you are using an agile approach or at least an incremental lifecycle, you will start to see this much sooner, and you can do something about it.
The posts in this series so far are:
@mentions are the thing that make Assembla indispensable for us. They weave together ticket comments and responses into a conversation. Today, we gave them a little bang! to make them even more useful.
In any message, ticket, or ticket comment, create a mention with @, and add a ! at the end. When you add the ! on the end, it sends an email to that person.
Use this feature to get feedback from someone who does not log in to Assembla every day and check mentions. It's useful for working with clients or people in other departments.
We got this from a customer:
We have plenty of users (QA, Designer, CEO), who will not be living in Assembla. They don't need to come check Assembla every day, and they certainly don't need a digest of the conversations happening between devs when 98% of the conversation doesn't concern them. It's a firehose. However, occasionally we want to ping them or give them an opportunity to chime in on a ticket. it's not always appropriate to assign a ticket to them since they don't _need_ to respond. @Mentions looked like the perfect solution ... [but it doesn't send emails].
REVIEW OF MENTIONS
Use mentions to bring other users directly into your conversation. In any message, merge review, ticket, or ticket comment, type @ and start typing the name of the person that you want to bring in. Assembla will pop up a user search form and you can select the user you want. They will receive a notice, in real time, on their start page and in the little red box on the top bar of their Asembla app. They can click through to your conversation, and respond.
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 6: COMPETITION
“There are people who fundamentally believe that competition is the way to get the best out of people, and there are people who fundamentally believe that the spirit of collaboration is the way you that you get the best out of people.”
Running time 30:20
What are your experiences with staff ranking or other policies and processes in your organization that you feel have helped you perform better or have gotten in the way of performing better? Have you seen or experienced real significant differences in policies and processes between private industries or government, schools and other such organizations?
Leave a comment on this blog or email us at email@example.com
[Intro] The pros and cons of staff rankings.
[02:36] The impact of the bell curve on employees.
[08:03] Real world example – Ken Blanchard.
[12:10] Applying business policies and processes to public institutions. Is it effective?
[15:44] Competition tends to be part of the American cultural fabric.
[18:29] Different levels of competition – from healthy competition to unhealthy competition.
[22:05] Consequences of competition.
[23:12] Introducing change that impacts only a certain group vs. starting at the top.
[24:40] How do you positively and effectively help people do good work?
[27:09] Take time to assess before making big changes.
Agile and Beyond: the words paint an image of a dark, star-lit sky. The starship Agile floats through the air toward some distant, efficient, high-performing process improvement.
Excuse the attempt at a dreamy, poetic intro; I’ve got Valentine’s Day on the brain.
Good news; this thinking need not be conceptual dreaming. Agile and Beyond, coming to Detroit next week, brings a place and platform for healthy discussions and dialogue around agile software development’s past, its present, its future.
Stop by and visit us at Agile and Beyond to learn what you need to know about managing your company’s agile processes with an agile project management tool, or continue to evolve or adapt your understanding and execution of agile. We are the first booth on the left when entering the sponsor area.
When you are not visiting our booth, check out the great slate of sessions available.
From reading the titles and abstracts, these are my favorites:
Stop Thinking and Start Doing: Action is everything, right? In this presentation, Daniel Davis will explore how we can use agile to put noble goals in place for you and your team. This will be personal development at its finest.
The Power of Promiscuous Pairing: In this provocatively titled talk, Thomas Piggott and Carol Treat Morton will showcase how pairing can yield tremendous benefits even beyond development. Who wouldn’t want to attend a talk that helps your team eliminate ‘towers of knowledge?’
Removing the UX Roadblock: Anyone who has been on an agile team with UX talent knows the struggles. A developer’s work styles, patterns, and pacing may be completely different than a UX designer’s, yet the designer’s contributions and output are pivotal to producing software. Stop thinking of the UX team as a roadblock; instead visualize them as a high-performing team member capable of greatness.
We are just scratching the surface here with the number of awesome presentations and workshops on the schedule.
Thanks, Agile and Beyond for putting together another outstanding event. We look forward to meeting the agile software development community of the greater Detroit area.
BTW: If you have time after the conference, visit one of the great Middle Eastern restaurants that call Detroit home. You won’t be disappointed.
Community Marketing Manager
Affectiva, a startup, is announcing the launch of its mobile software development kit (SDK) for tracking emotions.
"The company says it can analyze a user’s emotions by tracking their facial expressions, and it uses that technology to measure the effectiveness of ads. With the new SDK, mobile developers will be able to add these capabilities to their apps as well." -- TechCrunch Anthony Ha
"This means Affectiva’s technology could be embedded into consumer products — a spokesperson suggested via email that the possibilities include healthcare, education, and gaming apps." -- TechCrunch Anthony Ha
See -- TechCrunch Anthony Ha article
How could we use this tech (SDK) to nurture better teams? Reinforce positive sharing and interaction behaviors for a group of people (geeks) that love to interact with the confuser (mobile or desktop) but may be on the light-gray end of the autism spectrum?
Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt.
One of the big problems in backlog management is ranking technical debt stories. It’s even more of a problem when it’s time to rank technical debt projects. You think product owners have feature-itis problems? Try having them rank technical debt projects. Almost impossible.
But if you really want the value from your project portfolio, you will look at your impediments. And, if you are like many of my clients, you have technical debt: a build system that isn’t sufficiently automated, insufficient automated system tests, too many system-level defects, who knows what else.
If you addressed the build system, and maybe some of the system tests, if you created a timeboxed technical debt project, you could save time on all of the other projects in this code base. All of them.
Imagine this scenario: you have a 2000-person Engineering organization. It takes you 3 weeks (yes, 21 calendar days) to create a real build that you know works. You currently can release every 12-18 months. You want to release every 3-6 months, because you have to respond to market competitors. In order to do that, you have to fix the build system. But you have a list of possible features, an arm and a leg long. What do you do?
This client first tried to do more features. They tried to do features in iterations. Oh, they tried.
By the time they called me, they were desperate. I did an assessment. I asked them if they knew how much the build system cost them. They had a group of 12 people who “supported” the build system. It took at least 10 days, but closer and closer to 20-25 days to get a working build. They tried to estimate the cost of the build in just this group of people: 12 people time 21 days. They did not account for the cost of delay in their projects.
I showed them the back of the napkin calculation in part 1, and asked, “How many releases have you postponed for at least a month, due to the build system?” They had an answer, which was in the double digits. They had sales in the millions for the maximum revenue. But they still had a sticking point.
If they funded this project, they would have no builds for four weeks. None. Nada. Zilch. And, their best people (whatever that means) would be on the build project for four weeks.
So, no architecture development, no design, no working on anything by the best people on anything other than the build system. This company was convinced that stopping Engineering for a month was a radical step.
Does it matter how long your iterations are, if you can’t build during the iterations and get feedback?
They finally did fund this project, after about six months of hobbling along.
After four weeks of intense work by 16 of their smartest people, they had an automated build system that anyone in Engineering could use. It still took 2 days to build. But that was heaven for everyone. They continued the build system work for another month, in parallel with regular Engineering work to reduce build system time.
After all the build system work, Engineering was able to change. They were able to transition to agile. Now, Engineering could make progress on their feature list, and release when it made sense for their business.
What was the payback for the build system work? Almost immediate, Engineering staff said. When I asked one of the VPs, he estimated, off the record, that they had lost more than the “millions” of dollars of revenue because they did not have the features needed at the time the market demanded. All because of the build system.
People didn’t plan for things to get this way. They got that way a little at a time, and because no one wanted to fund work on the build system.
This is a dramatic story due to technical debt. I bet you have a story just like this one.
The cost of delay due to technical debt is real. If you never look at your technical debt and see where it impedes you, you are not looking at the value of your entire project portfolio.
If you eliminated a technical debt impediment, would that change one of your costs of delay?
No, I don’t love them for acting like police and filing reports if they spot a deviation from some “standard certified” rules in the development process. I wonder if it makes sense at all to monitor software engineering processes for compliance to abstract guidelines written by someone who’s never seen how your company actually works?
No, I don’t love them for meticulously clicking through screens in the UI-heavy cases, even though this job does deserve to be admired. Also, I don’t love them for following established testing practices without ever having a thought of questioning or tweaking them.
No, I don’t even love them for writing automated test scripts; it’s because some people view this skill as the only upper sky limit for QA’s. Neither do I love them for checking that a certain functionality in the product is implemented exactly as in the specs.
My point is that with all the above scenarios QA’s are supposed to function rather as cogs in a machine, and not as thinking individuals who have a lot more in store than the narrow-minded ability to follow rules and guidelines. It depends on an organization, of course, because in some companies QA’s are regarded only as human-shaped tools.
What is it that I love our QA folks for, then? It’s their ability to see the big picture and contribute to the quality of the product on all levels. I also love them because they keep a reasonable calm stance to bugs and glitches in software and UI. Some QA’s take it personally if the count of WTFs per minute is overriding all possible limits.
I love our QA’s for being curious people who go beyond the “human tool” thinking which seems to be prevailing in the industry, unfortunately. A professional QA person is someone with the analytical and critical mind, who reaches deeper into the background of the job at hand. It’s not only about writing automated tests, or test-driven development. The QA’s big picture embraces anything that has to do with how product appears to users. A truly competent QA will question irrational practices, bring this to everyone’s attention, and suggest ways to do things better. This sounds like a mix of internal auditor and external agile coach, and not everyone will have it, but if a company manages to raise such people in-house, the benefits are obvious.
Our QAs have this thoughtful mindset in place, and some of them have re-invented themselves outside the QA domain. A web operations/automation engineer, a product specialist, a feature owner, and there’s at least one ex-QA among those guys who overhauled our technical support and introduced the high service standards that our customers seem to appreciate.
The well-rounded QA’s are precious in almost any activity of a softdev company. They start from the bottom up and literally click their way through to the bigger picture. QA’s excel at noticing the flaws that others might miss, and this combination of inherent responsibility + attention to detail +analytical mindset makes them appear both as excellent problem finders and problem solvers.
Der Ursprung allen Konfliktes zwischen mir und meinen Mitmenschen ist, dass ich nicht sage, was ich meine, und dass ich nicht tue, was ich sage. Martin Buber
Eine wichtige Aufgabe von Menschen in Führungspositionen ist der Umgang mit Konflikten in ihrem Verantwortungsbereich, gerade auch in Veränderungsprozessen. Führung, als zentrale Ordnungs- und Strukturfunktion in sozialen Systemen, muss zum Umgang mit Konflikten bereit sein und Konfliktmanagement als eine ihrer Aufgaben sehen, da Konflikte in ihrer Dynamik fast immer Auswirkungen auf Leistung, Aufgabenbewältigung und das Klima im Team haben. Gerade Teams mit Selbstorganisationsauftrag sind nicht frei von Konfliktkonstellationen. Ein Konflikt ist das Aufeinanderprallen von (scheinbar) nicht zu vereinbarenden Wünschen, Zielen, Erwartungen, Interessen, Werten Ideen etc. mit einem hohen emotionalen Anteil und einer starken Handlungsdynamik mit der Tendenz zu Lösung, Eskalation oder Verhärtung.
Üblicherweise wird die Aufgabe von Führung im Konfliktmanagement, also im Bearbeiten aktueller, eskalierter Konflikte gesehen. Diese Sicht greift allerdings meines Erachtens deutlich zu kurz, um der Bedeutung dieses Themas gerecht zu werden. Methaphorisch ausgedrückt: „Ist das Kind in den Brunnen gefallen, wird es manchmal ziemlich eng, um es zu retten. Andererseits, geht das Kind nie zum Brunnen, kann es evtl. verdursten.“ Also was tun?
Es gibt vier zentrale Handlungsfelder, die aus der Führungsperspektive im Umgang mit dem Phänomen Konflikt je nach Lage der Dinge beachtet und bearbeitet werden müssen.
Prophylaxe heißt aus der Führungsperspektive, vorbeugende Strukturen zu schaffen, die dabei helfen, Interaktionen so weit als möglich konfliktarm zu gestalten. Dazu gehören definierte Erwartungen aneinander, Werte, Regeln, Normen, effektive Prozesse, aber auch teamfördernde Maßnahmen wie Teamentwicklung, Schulung etc. So kann z.B. in einer Retrospektive das Thema Konflikt gezielt angesprochen und bearbeitet werden. Welche Vorstellungen habe die einzelnen Teammitglieder, wenn es zu Konflikten käme, und wie wünschen sie sich, dass damit im Ernstfall umgegangen wird?
Früherkennung. Die genaue Wahrnehmung kritischer sozialer Prozesse im Umfeld ist besonders wichtig. Im Kontakt und im Gespräch mit den Mitarbeitern, Kollegen, dem eigenen Chef, können Konfliktsignale wahrgenommen und eingeordnet werden. Sich mit diesen direkten oder indirekten Signalen konfliktträchtiger Situationen, z.B. bei Besprechungen aller Art, auseinanderzusetzen, hilft bei der Früherkennung. Führungskräften sollte bewusst sein, wie der eigene Bezug zu diesem Thema ist. Bin ich eher „konflktscheu“, tendiere ich evtl. dazu, unbewusst Signale zu übersehen/überhören und setze gerne die rosarote Brille auf? Konflikte generieren Emotionen aller Art, das gehört dazu, ist beherrschbar und oft heilsam. Angst vor Gefühlen, der Versuch, immer alles rein auf der Sachebene regeln zu wollen, hindert daran, sich Konflikten „echt“ zu stellen. Ganz gleich, ob selbst beteiligt oder als Führungskraft in „neutraler Posisition“, wichtig ist es, Verantwortung für Konfliktsituationen zu übernehmehn. Das gehört zur Fühungsaufgabe.
Bearbeitung. Wenn eine Konfliktsituation bereits akut geworden ist, hat die Führung die Aufgabe, einzugreifen und konkrete Maßnahmen für eine Konfliktklärung anzustoßen. Führungskräfte können je nach Eskalationsstufe selbst agieren oder externe Konfliktmanager engagieren. Wichtig, und nicht immer ganz einfach, ist dabei, den richtigen Zeitpunkt und das funktionalste Vorgehen zu erwischen. Bin ich zu früh, „leugnen“ die Mitarbeiter den Konflikt oder unterschätzen die Eskalationsdynamik. Bin ich zu spät, hilft oft nur noch Machteinsatz. Und das hinterlässt meist verbrannte Erde, sollte aber deswegen kein Tabu sein. Auch eine Trennung kann eine Lösung sein. Es stellt sich die Frage, in welcher Funktion will ich intervenieren. Als
- Aufmerksammacher (Winken mit dem Zaunpfahl)
- Berater und Tippgeber (Vorsicht: Parteilichkeit, Einseitigkeit, missverstanden werden, zur eigenverantwortlichen Klärung motivieren)
- Moderator/Mediator (Wichtig: gute Gesprächsstruktur, Zeit, Regeln, Ausgewogenheit, Schutz, Vertraulichkeit)
- Leader (Machteinsatz, klare Vorgaben, Kontrolle, echte Konsequenzen)
- Auftraggeber an externe Mediation (Delegation an Dritte, klarer Auftrag, Profi aussuchen, Ziele für die Streitparteien setzen, unbedingt Nachkontrolle)
Stimulierung. Ein Arbeitskontext ohne jeglichen Konflikt oder zumindest ohne jegliche Auseinandersetzung (eine Vorstufe mit Konfliktrisiko), in dem ständig nach Harmonie gestrebt wird, ist häufig eingeschränkt kreativ und mittelmäßig leistungsfähig. Man spricht dann etwas zynisch von „Schönwetterführung“. Deshalb kann und muss es bei Bedarf auch Führungsaufgabe sein, Mitarbeiter zu ermutigen, konfliktbereiter zu sein und Auseinandersetzungen, wenn sinnvoll, auch zu riskieren und einzugehen. Einzelgespräche, Coaching, Teamentwicklung, Seminare sind z.B. Instrumente zur Stimulierung. Stimulierung muss immer offen betrieben werden. Keine Maßnahmen „von hinten durch die Brust ins Auge“, damit die Mitarbeiter mal sehen wie „feige“ und „harmoniesüchtig“ sie sind. Das ist aus meiner Erfahrung äußerst kontraproduktiv. Also das Thema bei Bedarf direkt ansprechen, Mut machen, Hilfestellung geben, Kommunikationsräume schaffen (einzeln und im Team).
Also ran an die Konflikte! Wenn sie schon keine „Lust“ sind, dann sollten sie auch keine „Last“ sein, sondern funktionaler Teil der Aufgabe, Teams in ihrer Selbstorganisation zu begleiten und zu führen.
Tipp: Führungskräfte können den Umgang mit Konflikten lernen – zum Beispiel mit dem Scrum Supplement “Konfliktlöser”
- Konfliktlösung – eine Kurzanleitung
- Führung und Management in Spannungsfeldern (Teil 2)
- Vom Umgang mit sozialer (Un)Ordnung und Struktur in agilen Systemen
Sometimes Twitter is just a bunch of crap and noise.
Other times, stuff comes over that you just can’t ignore. After we published the State of Agile report, I had one of those moments.
It hit me after one dude tweeted something to the effect of: “How in the world can a team claim to be doing Scrum if they don’t practice retrospectives?” I couldn’t let this one go. I polled our staff of professional agile coaches. Within an hour, 6 of them had opinions on whether you can proudly call your team “Scrum” or even “Agile” without conducting regular continuous improvement procedures.
Here I’d like to share with you some of our coaches’ opinions and recommendations – then find out your take. (ADHD moment: If you are new to agile or wondering ‘what is a retrospective?’ here’s a good explanation).
Take this as FREE advice from our professional coaches. Normally you pay for this stuff so IF you enjoy it, you at least owe me a LinkedIn share or tweet @VersionOne.
WHAT THE VERSIONONE COACHES SAY…
“You can’t be ‘Scrum’ if you aren’t doing all of the practices of Scrum.” – Steve Ropa
True. But I give this statement a big “So what?” Isn’t the goal of agility to create great software? If some part of Scrum doesn’t work for your team, should you do it anyway just so you can be Scrum? In the words of John Pinette, I give this a “nay nay.” I recommend doing all of the practices to start with – and only removing or modifying practices when you find them to be unnecessary or even detrimental. Ironically, teams usually come to that conclusion during the retrospective.
You can be agile without retrospectives, but it’s a very, very rare team who can. I have run into a few. They’ve usually been doing XP for a while, and are always co-located. Some teams did the retrospective because they were supposed to, but never really came up with anything new. What they were able to do was to inspect and adapt at the drop of a hat. These teams also found that daily standups had become redundant.
“It’s the wrong question to begin with.” – Lowell Lindstrom
The question of whether or not a team can be “Scrum” is a red herring for a few reasons.
First, due to the inherent inspect-and-adapt nature of Scrum, over time, no two teams will be identical and any given team may evolve in a way that makes one of the common or defined parts of the Scrum framework suboptimal. The classic example of this is task articulation and estimation in Sprint Planning, which many agile teams find is not necessary as they improve.
Second, there is no one person who can designate whether or not a team is Scrum, leaving any assessment to the discretion of the assessor. Across experts in the various Scrum communities there is a little consensus. This is due largely to the first point, i.e., the fact that each person’s opinions will be shaped by their experiences. And these are inevitably different.
It’s worth noting that the original definition of Scrum didn’t even include retrospectives. The patterns and papers from the mid-90s, and Ken Schwaber’s first book on Scrum (2001) make no mention of retros. The focus was on the product with the Sprint Review at the end of each Sprint, but no explicit reference to the team’s PDCA. Similarly, the original definition of Extreme Programming (XP) did not include retrospectives.
In 1999/2000 as XP was gaining in popularity, Norm Kerth was writing his book Project Retrospectives: A Handbook for Team Reviews. Although focused on larger, longer projects and the difficulty of learning what really happened, the ideas resonated strongly with the XP community and we soon saw the practice added to the XP list. The Scrum community followed suit and in Ken’s next book on Scrum (2005), we see retrospectives become part of the framework as we know it today.
So, were teams doing Scrum from 1993-2005 not considered ‘Scrum teams’ because they didn’t do retrospectives? Of course they were; it’s a silly question. What we can say is that the Scrum community and its leaders have found that the most hyper-performing teams reflect on their practices with a tenacious attitude toward improving the way they develop. Most do this through the construct of the retrospective. However, doing retrospectives well is difficult and depends on a culture that values learning. So, if my retrospectives suck and yield no improvement, then am I really any closer to being Scrum than if I do not do them at all? I would argue: No. Is a team who uses most of the Scrum framework but not retrospectives, integrating PDCA into their daily work as the Kanban community advocates, still a Scrum team? I would argue: Yes.
Any discussion centered on “being” Scrum or “doing” Scrum should explore whether a practice improves a team’s performance, the different scenarios and conditions required for a practice to thrive, and the substitutes that might make a practice replaceable.
“Retro is a key ceremony. You cannot be ‘true’ Scrum unless you follow the framework as it was designed.” — Jo Hollen
You can, however, be “ScrumBut”… and realize some value from your partial Scrum efforts.
Going back to agile and Lean principles, the notion of continuous improvement is very foundational. Without retrospectives, I would be concerned about how the culture is addressing the principle of continuous improvement. Do such organizations have other methods through which they can incorporate team feedback and address improvement? Maybe the more interesting examination is why do they NOT want to do a “retrospective” – or not think they need to? I’ve seen where they were done as part of the process, but often I felt they were not very effective in many teams.
First, it must feel totally safe to bring up something that is not going well. Many cultures still want to immediately find a person to blame for the “problem.” If anyone feels unsafe, the retrospective will be superficial. Nothing useful will come from it, and the team will quickly find the retro a waste of time.
Even if a team gets to the point of bringing up real issues, there must be a spirit of appreciation for the input – then real results and follow-through. If nothing ever comes of the feedback, it will quickly stop. Besides, if results are not implemented, then there is no improvement anyway (thus, another waste of time).
Or maybe the team feels that everything is fine. REALLY??? Nothing can be improved? (Maybe you should hire them for coaches then). Even the highest-performing teams will find things that can be improved. But, maybe every two weeks feels too often? Maybe they should do a health-check/status and a deep-dive examination every few sprints. Agile requires some form of engagement and commitment to continuous improvement.
“You can’t be ‘Scrum’ without the ‘Scrum’ ceremonies.” – John Krewson
You can be agile without the ceremonies so long as you’re adhering to the principles, but “Scrum” asserts certain ceremonies as part of the framework. Those ceremonies, retrospectives included, are intended to uphold the theory of empirical process control upon which Scrum was built. I refer to retrospectives as the “missing agile value” and have a blog post coming out soon to address this.
“Learning always precedes agile maturity.” — Brian Irwin
As you’ll see in John’s blog post, from an organizational perspective, learning always precedes agile maturity. I’m also planning a blog post specifically about expanding retrospectives past the team level and embracing them at all levels in the organization, including (or especially) at the upper-management level.
To me, one of the most critical aspects of agility is learning; i.e., at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Maximizing learning is also a key Lean concept.
I think people tend to get so hung up on processes and how to do things that they forget why they’re doing them in the first place. But to answer the question directly, if you’re not doing retrospectives not only are you not doing Scrum—you’re not really agile if you aren’t making time for learning. Teams typically stop doing retrospectives because they’re difficult. Once you’ve addressed the low-hanging fruit, it gets complex to address the real hard stuff (people issues, organizational dysfunction, etc.).
“Not doing retrospectives suggests the plan must be perfect.” — Michael Moore
I would say that this is not specific to Scrum so much as it’s one of the principles of agile to inspect and then adjust/tune. This principle goes beyond agile even; I’m not sure I’ve seen any good improvement method that doesn’t include some sort of periodic reflection and adjustment, whether it be self-improvement or organizational.
Not doing retrospectives suggests that there is no need for adjustment, which means that the team and plan must be perfect. If they aren’t, however, this activity is essential to maximizing effectiveness.
Of all the principles, this is the first that should be implemented, regardless of the method. From this principle, all other principles and practices are discoverable.
WHAT’S YOUR OPINION?
Can a team be Scrum or Agile without retrospectives? Join the debate by leaving a comment below. Better yet, subscribe to this blog; several articles addressing this topic are on deck from our coaches in the upcoming Agile Chronicles. We’d like to hear from you!
Strategy Deployment is sometimes known as Hoshin Kanri, and like many Lean concepts, it originated from Toyota. Hoshin Kanri is a Japanese term whose literal translation can be paraphrased as “compass control.” A more metaphorical interpretation, provided by Pascal Dennis in Getting the Right Things Done, is that of a “ship in a storm going in the right direction.”
photo: Flickr, The Commons
Strategy Deployment is about getting everyone involved in the focus, communication, and execution of a shared goal. We have described in previous posts how we collaboratively came up with strategies and an initial plan in the form of an X-matrix. The tool that we use for the deployment is the Strategic A3.
A3 refers to the size of the paper (approximately 11 x 17 inches) used by a number of different formats to articulate and communicate something in a simple, readable way on a single sheet of paper. Each rock or departmental team uses a Strategic A3 to describe its plan. This forms the basis for their problem-solving approach by capturing all the key hypotheses and results, which helps identify the opportunities for improvement.
The different sections of the A3 tell a story about the different stages of the PDSA cycle (Plan, Do, Study, Adjust.) I prefer this latter formulation from Dr. W. Edwards Deming to the original PDCA (Plan, Do, Check, Act) of Walter A. Shewhart, because “Study” places more emphasis on learning and gaining knowledge. Similarly, “Adjust” implies feedback and iteration more strongly than does “Act.”
This annual Strategic A3 goes hand-in-hand with a macro, longer-term (three- to five-year) planning A3, and numerous micro, problem-solving A3s.
Anatomy of a Strategic A3
This is what the default template that we use looks like. While it is often good to work on A3s using pencil and paper, for wider sharing across the organisation we’ve found that using a Google document works well too.
Each A3 has a clear topic, and is read in a specific order: down the left-hand side, and then down the right hand side. This flow aligns with the ORID approach (Objective, Reflective, Interpretive, Decisional) which helps avoid jumping to early conclusions.
The first section looks at prior performance, gaps, and targets, which give objective data on the current state. Targets are a hypothesis about what we would like to achieve, and performance shows the actual results. Over time, the gap between the two gives an indication of what areas need investigation and problem-solving. The next section gives the reactions to, and reflections on, the objective data. This is where emotions and gut feelings are captured. Then comes interpretation of the data and feelings to give some rationale with which to make a plan.
The three left-hand sections help us look back into the past, before we make any decisions about what we should do in the future. Having completed that we have much better information with which to complete the action plan, adding high-level focus and outcomes for each quarter. The immediate quarter will generally have a higher level of detail and confidence, with each subsequent quarter afterward becoming less granular. Finally, the immediate next steps are captured and any risks and dependencies are noted so that they can be shared and managed.
Co-creating a Strategic A3
As you can probably imagine from reading the previous posts, the process of completing a Strategic A3 can be a highly collaborative, structured, and facilitated process. One team with which I work closely recently had grown to a point where we would benefit from our own Strategic A3, rather than being a part of a larger, international Strategic A3. To create it we all got together for a day in our Amsterdam office. We felt that this would allow us to align more strongly with the corporate strategy and communicate more clearly what we were doing, and where we needed help.
We began by breaking into small groups of three to four people, mostly aligned around a regional territory. These groups spent some time filling in their own copy of the A3 template. We then reconvened together and each group gave a readout of its discussions, presenting the top three items from each section, which we captured with post-it notes on flip charts. Having gone around each group I then asked everyone to silently theme the post-its in each section until everyone seemed happy with the results. This led to a discussion about each theme and identifying titles for them. We still had quite a few themes, so we finished off by ranking them with dot-voting so that we could be clear on which items were most important.
Our last step was to identify the top three items on the A3 that we wanted to highlight to the wider business. This turned out to be a relatively simple conversation. The collaborative nature of the process meant that everyone had a clear and shared understanding of what was important and where we needed focus.
Strategy deployment is not a one-off, top-down exercise. Instead, the Strategic A3 is used as a simple tool that involves everyone in the process. Teams prepare and plan their work, in line with the corporate goals, and each quarter they revisit and revise their A3s as a means of communicating status and progress. As performance numbers become available an A3 will be updated with any changes highlighted, and the updated A3 then becomes a key input into Quarterly Steering, the subject of a future post.
Before we start our conversation about governance in the structure-governance-metrics framework we’re building out, I want to take a minute and see if I can finally tell you guys about the house my wife and I were planning to build this past summer. It’s an important conversation because we need to establish a shared understanding around what it means to plan on an agile project.Scenario One – Team Agile Home Builder
My wife and I decide we want to build a new home. We find a piece of property we like in a nice neighborhood. We find a builder we like and think we can trust. We have a really good idea of the type of house that will work for us and our family. We decide that we want to spend somewhere around $500K to get the house completed but it needs to be finished sometime before our kids leave school for the summer.
Next step is to reach out to the builder and see what he can do.
The next day we show up at the builders office and tell him about our plan for our new home. The builder is really excited, seems competent, and is very confident he can get the house built within the time and cost constraints that we’ve established. We ask him what’s the next steps for planning construction on our new home. To our surprise, he tells us that he is an agile builder and doesn’t do any planning.
The builder proceeds to explain to us that as an agile builder, he doesn’t do any planning. He will meet with us every two weeks to determine our priorities and figure out the next most important thing to build. Every two weeks we can inspect what he’s built and change our mind about anything anytime. He tells me this is really in my best interest because I won’t know exactly what I want until I see it.
When I ask if I’ll have the house I want when I run out of time and money, he doesn’t know, but assures me I’ll have the most valuable parts of the house early. Furthermore, I could actually move into the house anytime during the build process, and if I decide I’ve built enough house at any time, I can cancel the contract early and pay him for only the weeks he worked plus 20% of the remaining contract.
So here is my question… would you spend your money this way?
Most people when they are spending their own money, want to have some idea of what they are going to get when the time and money runs out. They want some assurance that they’ll have enough bedrooms and enough bathrooms. They want to know the acreage of the lot and if they are going to get a one story or a two story house and how many cars they’ll be able to fit into the garage.
People understand they might have to make some tradeoffs later in the build process. They might go over on carpet and have to make some tradeoffs with the lighting. They might decide they want fancy cabinets and go with a less expensive hardwood floor. They might want to defer decisions about the colors, or the finish, or the bushes they want to put in the front yard. They aren’t willing to leave out bedrooms.
We wouldn’t spend our own money this way, but this is the way we are asking our customers to spend their money when they build software with us.Scenario Two – Scaled Agile Home Builder
Fortunately for us, this wasn’t the way that our builder asked us to build our house. We did meet with him and describe our dream home. We talked about the property we wanted to build on, the number of bedrooms and bathrooms, and the number of cars we’d be able to fit into the garage. We talked about the quality of the finishes and flooring and how we wanted the yard landscaped. That took about an hour.
After that, we spent a week or two having meetings with the architect. We got pretty specific about the room layout, the number of floors, the layout of the basement, and the placement of the house on the lot. We made high level decisions about floors and cabinets, but didn’t pick any specifics, decide any colors, or pick specific appliances, light fixtures, or door knobs. There was way more left open then decided.
What we did decide was the stuff that would drive the cost of the house. The stuff that would be expensive to change later. We went into the process understanding that a ton of stuff was going to change, but there was also stuff that would be really difficult to change, and those decisions had to be made early. We talked about potential risks once they broke ground and buffered in case anything went wrong.
The result was a blueprint and elevation for the house. We had a line item budget for construction costs, material costs and miscellaneous tools and supplies. Every line item factored in a profit for the builder. Every line item represented some feature or attribute of the house that I would probably care about when the house was complete. We did all that in a few weeks and made no detailed decisions about the home.
It was interesting, the first cut of the plan was about $200K more than we wanted to spend and we were aware that there was some risk and should probably buffer another $50K just in case. Even though I trusted the builder, I had my CPA and advisor review the plan line-by-line just to make sure all the costs were reasonable and we were making a sound financial decision before we decided to move forward.
As we were reviewing the plan… the builder said something to me that was pivotal for how we were going to manage this project. He told me that I had a 20K budget for hardwood floors. For that price, he assured me that I would be able to get a high quality floor, extra long and extra wide boards, and a very high quality wood with a very high quality finish. That said, my budget was 20K for the hardwood floors.
When it got time to build put in the hardwood floors, it was up to me to choose what kind of floors I wanted to put in. If I decided I wanted a less expensive floor, I could save money and use it for something else. If I wanted an exotic wood like Brazilian Cherry, that would cost more and I’d pay extra. It would ultimately be up to me, but he would work with me to understand my trade-offs and any associated costs.At Enterprise Scale, Estimates Become Budgets
I instantly made the connection that this was exactly how I coached teams to define, estimate, and plan software projects. You have to have a high level plan. You have to make key decisions early. You have to have time and cost estimates to present to the customer. What you don’t have to do is define anything and everything before you even get started. You have to establish budgets to bound your uncertainty.
At the point the builder made the estimate, he was bound to manage the project to that estimate… the estimate became a budget. The builder had to work with me as the primary stakeholder to help me make tradeoffs to live within that budget. As we break down software requirements, focusing on minimally marketable features and maximizing value, we are effectively doing the exact same thing.
Okay… let me drive this one point home. Just like you wouldn’t build a house with an open ended scope, your stakeholders don’t want to commit to an open ended software project. We have to do enough work up front to put together a credible plan, mitigate risk, and understand costs. We have to estimate the work, set budgets, and make tradeoffs to ensure the product is done on time and on budget.
It is important to be able to tell people what the project is going to cost and when it’s going to be done. It’s important to tell people what they are going to get for their time and money. It’s also important they know the risks and can buffer some contingency. They also need to know what’s locked and what’s open and the kinds of tradeoffs that they might have to make along to way to ensure success.Why Is This Such a Difficult Problem to Solve?
The problem is that many software teams are trying to build products in less than ideal conditions. They are constantly realizing issues and risks they didn’t anticipate. They are working across too many projects at one time. They have external dependencies that can’t be managed or controlled. People are not dedicated to the team. The result is that people are coming to the conclusion software can’t be estimated.
Going back to the house analogy, it’s as if we are building on rocky soil and are constantly finding boulders that have to be broken up and hauled away. It’s as if we have contractors that never show up when they say they will. It’s as if we are constantly changing our mind between a one story house and a two story house or deciding we want a basement after the foundation has already been poured.Summing It All Up
The answer can’t be throwing our hands up and refusing to make a commitment. We might have to pay a few thousands dollars to determine if the build is feasible. We might have to pay another few thousand for soil tests to make sure the land can accommodate our new home. You can spend money to mitigate risk. Sometimes you need to do some work to learn what you don’t know.
No estimating, no planning, and not committing won’t be the answer for most organizations. It’s not a starting place anyone can live with.
You have to ask yourselves what it is going to take to stabilize the delivery process. Forming teams that stay together helps, that was my previous post on structure. Having a governance model to control the flow of work helps too, that’s my next post. Having a means to mitigate risk, invest in discovery, establish baseline metrics, and the ability to measure improvement over time all play a part. More posts to come!
#noestimates is a #nonstarter
One final note… Kimi and I never ended up building this house. The neighborhood was beautiful. The plan and elevation were beautiful. We really liked our builder and trusted he could deliver our dream house within the time and cost constraints we agreed on. The problem was that housing prices were depressed in the county we planned to build in and the appraisal came in at 60% of the build cost of the home.
We could have moved forward anyway, but would have been instantly in a house that was worth less than we paid for it, with no indication it would recover in the foreseeable future. So sure, we spent a bunch of time and mental energy, and even some hard cash to find out we shouldn’t build the house. Had we built the house using mainstream agile thinking, we’d have found out too late it wasn’t worth what we’d actually paid for it.
We spent a few weeks of time and a few thousand dollars but avoided what would have been a very, very expensive mistake. That’s not waste in my opinion… that’s good risk management.
Check out the previous post, Shu Level Agile Isn’t The Same As By-The-Book Scrum.