Immer wieder frage ich mich in meiner Rolle als ScrumMaster: „Was kann ich dafür tun, dass mein Team schneller wird? Wie kann ich es anspornen?“
Was sind Motive, um schneller zu liefern? Unterscheiden wir zunächst zwei Kategorien der Motivation. Die intrinsische, also die Motivation von innen heraus, und die extrinsische, also die Motivation von außen. Hier einige Beispiele:
- Die Arbeit und ihr Ergebnis begeistern mich.
- Das Ergebnis hat für mich persönlich einen greifbaren und spürbaren Nutzen.
- Angst um den Arbeitsplatz/vor den Konsequenzen bei Verzug, auch ohne spürbaren Druck von außen
- Ich weiß, welchen Anteil/Beitrag ich leiste.
- Ich weiß, wohin die Reise geht.
- Ich bin innerhalb eines für mich guten und nachvollziehbaren Rahmens selbstbestimmt in meinem Handeln
- Druck von außen (Chef, Projektleiter etc.)
- Prämienzahlung bei Termintreue und stimmiger Qualität
- Anerkennung vom Chef/Vorgesetzten.
- Konkurrenz anderer Teams/Projekte/Unternehmen
Idealerweise arbeitet jemand effizient und liefert entsprechend schnell und in guter Qualität, auch ohne dass wir etwas tun. Das Leben ist aber nicht immer ein „Ponyhof“ und so sind doch immer wieder einer „Beschleunigung“ von außen und Motivationsspritzen durch den Scrum Master nötig. Ich möchte also die Frage stellen: Wie motiviert ihr euer Team? Oder. Wie bringt ihr das Team dazu, vielleicht sogar für euch zu rennen? Hattet ihr schon einmal einen Team Lead/Chef/Vorgesetzten, den ihr so sehr geachtet habt, dass ihr schon aus diesem Grunde für ihn oder sie gerannt seid? Eine ideale Situation, oder?
Als Geschäftsführer habe ich die Erfahrung gemacht, dass genau hier ein wichtiger Hebel liegt. Es steht zwar in keinem Buch geschrieben, aber der ScrumMaster ist in meinen Augen auch für die Stimmung im Team zuständig. Wie heißt es doch so schön: Der Fisch beginnt beim Kopf zu stinken. Oder: „Zeig mir dein Geschäft und ich zeig Dir deinen Chef.“
Tun wir also etwas dafür, dass das Dev Team gerne liefert. Sorgen wir für Stimmung und dafür, dass die Mitglieder gerne zur Arbeit kommen und gerne in diesem Team arbeiten. Genau dafür braucht es ja die berühmten Soft Skills, wie die Fähigkeit, Konflikte zu lösen oder als Schlichter und Moderator zu agieren, um Frust zu vermeiden etc. Warum nicht also den Witz des Tages einführen oder ein regelmäßiges Teamfrühstück durchführen? Auch mehr oder weniger große gemeinsame Teamevents können helfen. Dies sollen keine pauschalen Allheilmittel sein. Jeder sollte herausfinden, was dazu führt, dass ein Teammitglied sich noch wohler fühlt. Wichtig ist jedoch, dass Konflikte gelöst und nicht unter den Teppich gehören. Machen wir uns bewusst, dass Stimmung immer herrscht, ob wir sie nun gerade sehen oder auch nicht. Aber sie ist vorhanden und sie bewegt und leitet unsere Teammitglieder. Machen wir sie also lieber sichtbar. Beispielsweise durch eine Frage danach in der Retrospektive. Eine Freude für alle, wenn sie ohnehin gut ist. Eine Chance jedoch, wenn sie gerade nicht gut ist, denn sie wirft die logische Frage nach dem “Warum” auf. In der Retrospektive des vergangenen Sprints fragte ich alle Mitglieder nach ihrer Stimmung auf einer Skala von 1-10, wobei 10 die Bestnote war. Im Durchschnitt lag unsere Stimmung bei wundervollen 8 Punkten. Ein tolles Ergebnis, aus dem ich ableitete, dass diesbezüglich keine dringenden Maßnahmen nötig waren. Und vielleicht könnt ihr euch vorstellen, was dieses nun transparente Ergebnis in den Gesichtern der Teammitglieder bewirkte.
Fragt euch am besten also selbst nach den Gründen dafür, warum ihr gerne in einem bestimmten Umfeld arbeitet und lasst euch davon leiten. Frei nach dem Motto: Ich behandle die anderen so, wie ich selbst gerne behandelt werden möchte.
- Scrum Essentials: Die sieben Fragen der User Story
- Der ScrumMaster als Dienstleister
- What´s S.C.R.U.M. ?
Natalie Warnert (@nataliewarnert) blogs at Confessions of a New ScrumMaster. Here she is, talking about dating Agile.
So I’m being an Agile player. I’m dating a few different versions of Agile to see which works best while trying to keep it from the other methods I’m test driving. Don’t tell Scrum that I was scoping out Kanban. Don’t let Kanban know I made a date to get to know TDD better. How can I help the team decide which is best when there are so many options to consider? A hybrid approach can sometimes work, but under some corporate guidelines the relationship needs to be with one or another exclusively, not multiple. It’s all about exclusivity in this corporate Agile dating world. (I plan on posting a subsequent post exploring the non-exclusive relationships and hybrid approaches to this in the future – check back).
Honestly I’ve only tried each for a short time, so it could be too soon to tell. How long do you date one until you decide to make your relationship and commitment public? There is the get-to-know you phase where you’re just trying to figure out what each methodology is about, what they stand for, and what they work best for. It has to be determined if they are compatible with the team and project and if the relationship will work in the future.
Once you have an idea of which you want to commit to, how can you be sure? Should you keep the others on the line in case it doesn’t work out? If there are a few things that don’t work in one, do you try to tweak those things at the risk of losing the integrity of the methodology itself? What are the long term consequences of not being able to make a commitment? Obviously methodologies don’t have feelings but teams do, and how do you help the team to determine what is best without causing them unnecessary pain and confusion?
Does the team settle for what works “well enough”? Where they and the stakeholders can be happy? But what is to say there is not more happiness out there to be found? That hopefully should be found as the team improves and continues to inspect and adapt for what works best for them. There are things in methodologies, like people, that won’t change in relationships, but there are other things that can and will change as the relationship grows and matures. Goals get more defined, it becomes more comfortable, but there will still be and should still be ups and downs. That is how the relationship continues to improve and get stronger. Maybe at some point if the team or project changes too much the relationship will need to be ended, but that shouldn’t be looming overhead. If it ends, it simply means the team and the methodology grew apart and will need to look to start dating again.
It’s okay to be an Agile player at the beginning but in some corporate PMO run environments, the non-exclusivity does not work for very long. It’s best to go in with your eyes open, learn as much as you can quickly, and help the team to make an informed decision for what methodology they should have a commitment with.
This post first appeared as I’m being an Agile player on Natalie’s blog in June 2013.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
It’s very common for organizations to track the velocity of the Agile teams over time. This is quite a reasonable datapoint to plot. Combined with other data, it might give you some insights when you look back, and insights based on data are typically more useful than insights based on opinion. Remember, though, to keep in mind what the data is, and what it is not.
In the case of velocity, it’s not an analog for productivity. It’s easy to fall into the trap of thinking so. “28 story points is the amount of work we can accomplish in a sprint.” Except 28 points is not an amount of work; it’s an estimate. Even if you count stories rather than estimating them—”17 stories is the amount of work we can accomplish in a sprint”—it’s still an estimate. We can easily manipulate either one by estimating with more story points or slicing the work into smaller stories. It’s so easy, we can do so without noticing or intention to do so.
Goodhart’s Law: Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
In other words, while velocity may roughly track productivity, it will cease to do so as soon as we use it for that while trying to increase productivity.
This misuse of velocity to represent productivity is well-known, but I frequently still hear or read statements that conflate the two. Pick something actually valuable to you if you want to measure productivity.
Many organizations have trouble communicating effectively between executives, product owners, and developers.
Because they are trying to decompose high-level epics into granular user stories.
Features are needed to scale, because it’s too difficult to manage large programs with just user stories.
What’s the best way to use Agile features to manage large enterprise programs?Agile Features
I recently worked with a large mobile telecom where the organization had been breaking epics directly into user stories. They were experiencing issues and didn’t find it effective to go from big, high-level epics to small detailed stories. This is a challenge I see at a lot of organizations and there is a simple solution, features.
Features are needed to scale, because it’s difficult to manage large programs with just user stories. Release planning becomes too detailed if you don’t have a middle tier of features representing what you’re trying to build. Without features you lose the ability to coordinate across teams effectively and are not able to provide enough context about the higher level value and goals. You need features to define the product, coordinate, and plan what you’re going to build at the delivery team level.
It is much more effective to discuss what the development teams will deliver in the future by describing it in high-level features, particularly for folks at the senior leadership level, senior product owners, and executives. User stories do not resonate with them, because they’re too granular. A senior executive doesn’t want a list of two-hundred user stories that you’re going to deliver in the next release. They don’t have time for all that detail. They want to talk higher level about what key capabilities are going to be delivered in this release, six months or a year down the road.
You apply a lot of the same rules for features that you do for user stories. You deliver features frequently, synchronize your work across teams, and limit your work in progress for features just like you would for user stories.Tips for Agile Features
There are a few rules that I try to impart when I’m dealing with features. I like to allow features to span iterations, but I generally don’t want features to span releases. By that I mean, if you have a product release six months down the road, you want to make sure that you’ve got all the features you’re going to build within that release and you don’t have a feature that’s partially in one release and partially in another release.
It’s important that your organization doesn’t feel like the product roadmap and features are etched in stone. The features may change based on new challenges that the team has discovered. You may discover that one particular feature is going to take longer than you expected, and so it’s important to review this feature set in a regular cadence with senior leadership, so they know what to expect in the future. Don’t set the false assumption with senior executives that the feature set is fixed and it’s not going to change. This is software, and things always change. Contrary to popular opinion I find executives are pretty amenable to change. They just don’t like surprises.
When you define features, they need to be associated with a particular goal of the system. If the feature does not align to a particular goal you may start having feature creep and orphan features. Your product owner team should be responsible for making sure each feature is aligned with a specific goal. The product owner team should take the big picture that’s being discussed at the portfolio level and decompose those long-term objectives into release-level features. It’s also their responsibility to take those features and help decompose those into user stories. I recommend you do that by defining the product roadmap and conducting roadmap workshops or release planning workshops.
Another important responsibility of your product owner team or core product team is to make sure that dependencies between features are managed. The best way to do that is to make sure there are as little dependencies as possible and to make sure that features are as self-contained as they can be. Ensure features are not dependent on aspects of other features.
Just like user stories, features can be described in what we call the traditional “Three C” format, card, confirmation and conversation. The three C’s help your team gain a shared understanding of the feature. You can confirm your shared understanding of features with acceptance criteria and visual specification. The visual specification can be a use case diagram, sequence diagram, wire-frame diagram or mock user interface. Just provide a visual representation to describe what product capability the feature provides.Summary
I hope I’ve inspired you to look into whether features would help your organization. If you are using features, I hope you’ve found some value in revisiting the best way to utilize them. If you are not using features, take some time to investigate if there are communication break downs when product owners are breaking their epics into user stories.
What are some tips you have for using user stories?
The post How to Manage Large Agile Enterprise Programs with Features appeared first on LeadingAgile.
Neulich kam ein etwas resigniertes Projektmitglied ins Büro uns sagte zu mir: „Wir haben alles noch schlimmer gemacht – wir haben es verscrumpelt!“
Er bezog sich dabei auf recht komplizierte IT-Controlling-Aufgaben und Prozesse zwischen drei Organisationen. Mich hat es aber insofern getroffen, als dass er die Wortschöpfung „verscrumpelt“ ja nicht ohne Grund aus dem Hut zauberte. Offensichtlich empfand er die Veränderungen, die durch die Einführung von Scrum ausgelöst wurden, als negativ. Und das erlebe ich nicht zum ersten Mal. Bei dem Versuch, so einfache Abläufe und Beziehungen wie Scrum sie vorsieht, einzuführen, werden die hoch regulierten Strukturen und lange gewachsenen und ausdetaillierten Prozesse grundsätzlich in Frage gestellt. Vor der Veränderung hat das System in Bezug auf Agilität nicht gut funktioniert, aber es war im Gleichgewicht und hatte einen Weg gefunden, mit den Aufgaben umzugehen.
Nun verändern wir ein kleines Teil im Getriebe oder Uhrwerk und die Auswirkungen sind enorm. Und dabei kann man nicht mal alle Auswirkungen vorhersehen und wird daher das eine oder andere Mal überrascht. Was wir für die Softwareentwicklung fordern, gilt in diesem Falle auch für die Organisationsveränderung. Neue Prozesse entstehen, indem man sie ausprobiert und lernt. Das kann in den ersten Anläufen frustrierend sein und so wirken, als wenn man alles noch schlimmer macht. Vor allem für Menschen, die klare Strukturen brauchen und alles vorab bis ins kleinste Detail durchdenken und planen wollen, stellt diese Vorgehensweise eine Herausforderung dar.
In solchen Fällen versuche ich, den Anspruch der Personen auf die Optimierung des Prozesses oder der Rahmenbedingungen zu lenken. Skizzen des „optimalen“ Prozesses und die Visualisierung der Stellen, wo es momentan noch „kracht“, können die Enttäuschung der Personen konstruktiv werden lassen.
Ich habe dann vorgeschlagen, dass wir gemeinsam versuchen, die neuen Prozesse so zu verbessern, dass wir sagen können, wir haben sie „verscrummed“ und nicht „verscrumpelt“. Seitdem biegt sich die die Frustrationskurve allmählich in eine Steigerung des Level of Done nach jeder Iteration. Vielleicht hilft uns ein Board, auf dem wir die Prozesse und Abläufe unter „verscrumpelt“ sammeln und nach und nach Richtung „verscrummed“ bewegen. Das würde die Impediments schön transparent und wahrscheinlich handhabbarer machen. Mal sehen, was der Kollege davon hält.
- Scrum Meetings – Spannungsfeld Routine versus Kreativität | Dieter Rösner
- Mit dem Computer Code bessere Teamarbeit erreichen
- Die Scrum Artefakte
I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.
Some signs you may have a problem introducing a change:
- Taking action requires getting permission (this is straight from Pawel)
- Action can’t be taken because projects are too important to risk
- Only certain people can take action
I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…
Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.
The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.
Filed under: Agile, Coaching, impediment Tagged: Agile, blog, Continuous Improvement, continuous improvement effort, culture, impediment, Impediments
I’ve got to admit it’s getting better (Better)
It’s a little better all the time (It can’t get no worse)
Why do we expect productivity to increase? This goal seems to be a common expectation for management-driven Agile adoptions. Productivity is like motherhood and apple pie; who wouldn’t want more?
There is a story of a farm boy who went to the barn every morning and picked up the new-born calf. When asked why, he replied, “If I keep doing this every day, in a year I’ll be able to lift a thousand-pound cow!”
Just as there is a limit to our capacity to lift weights, there is a limit to the rate at which we can produce software.
Agile software development is not about productivity; it’s about working well. Yes, I think there are potential gains in productivity for most teams. Even then, the bulk of the gains are from “maximizing the work not done” rather than becoming more efficient programmers. We cannot increase our productivity indefinitely. More efficient programming is a slow process and comes not from trying to go faster, but by trying to do a better job. Productivity is one of the many things we’d like that are more likely achieved by an oblique approach.
I have a new column up on project management.com. It’s called Debugging Your Geographically Distributed Agile Team. (You have to register to read it. Registration is free.)
You can do agile with geographically distributed teams. You might not be able to do Scrum. You have other choices of approaches.
Helping a team form is tough. This article, which is true, shows how tough it can be.
Do you have similar experiences? Different experiences? Let me know. I’d love to hear from you.
I don’t consider myself an expert on designing compensation systems, but as of late this issue has come up with several clients, and of course, I have to deal with compensation issues leading LeadingAgile. I’d like to share some thoughts with you guys, get some feedback, and maybe even generate a little healthy debate.
The key challenges around compensation, at least for me, center around figuring out how to reward individual performance without encouraging internal competition, local optimization, or one person feeling rewarded while another feels punished. You want compensation to motivate people, not to have a negative impact on performance.
Ever since I read Dan Pink’s Drive I’ve been very aware of the distinction between intrinsic and extrinsic motivation. While you’d like everyone intrinsically motivated… the realities of having a mortgage, consumer debt, household expenses, kids that need to go to college, or even saving for retirement drive different extrinsic needs.
Some folks want to come to work, do a great job, and go home. Some folks want to go the extra mile and really make a difference. Some poeople really want to kill it, advance their career, and be rewarded for all that hard work. Just saying that everyone should get a fair base salary, with no performance based component, isn’t going to work for some people.
So the question becomes, is it possible to use money or other rewards to recognize performance without introducing the negative side effects? Can we build a compensation system that values collaboration without creating internal competition, local optimizations, or risks leaving one person feeling punished because they didn’t get as much as their peer?
Here is what we are doing with LeadingAgile…
First, we have all our coaches is a pretty narrow salary range and we are working to narrow that range even further. When we started hiring a few years ago, I was pretty risk adverse and you really had to be a true believer to come work for me. As we grew, salaries increased and we are making things right for the people that joined us early.
As a quick aside, I want to be able to justify numbers if we ever decided to publish salaries internally. For the record, I am totally open to full transparency and think it’s a good idea. Some folks aren’t so keen on the idea, so we are respecting that for now. It does influence decision making around salaries when everything might be out in the open some day.
We believe that baseline performance is binary, you are good enough to be on the team or you aren’t. We are starting to get more explicit about what it means to be good enough to be on the team, but if we hire someone, we have very high confidence they can work in our model and be successful. Occasionally something will come up after the fact, but that has been rare.
If you are good enough to be on the team, you share in the team’s success. For us, that means a 20% bonus on top of your salary. Everyone will get the bonus or no one will get the bonus. We are toying with quarterly payouts but for now, it’s annual. The idea is that if the company is successful, we want to share that success with everyone.
Success for the time being is defined as 75% utilization. We’ve debated setting the target a little lower and we’ve discussed a sliding scale. There is a ton the utilization implies about our ability to market, sell, deliver services, and manage cash… so it’s not just about revenue. That said, revenue is what drives our ability to get people paid.
Does this fall into the category of an extrinsic motivator that might actually demotivate people? Maybe. But how else would you share financial success when things are going well? If we just added that 20% to each salary, my cost structure would be too high should we underperform financially. I’d have to let people go in a slump and that’s not the goal!
We are intentionally falling on the side of keeping our cost structure in check and rewarding the team if we are able to perform at a high level. We are building the infrastructure to help the team support marketing and sales, educating folks on how to manage engagements, and really encouraging people to pay attention when we have unexpected downtime.
I’m hoping that by taking a whole team approach, keeping everything visible, and empowering everyone to influence the goal we’ve been able to strike the right balance. Time will tell.
That said, we still haven’t addressed how to compensate the people that really want to kill it. Those consultants that want to hep market and sell, grow the practice, lead multiple accounts, and create sustainable economic value for the company. If someone is able to create that kind of value, I need to reward them or they’ll leave our company and start their own.
We are looking at introducing a variable component to our salary structure based on several other metrics we think might be relevant: overall financial contribution based on sales and marketing activity, the ability to keep yourself busy on one or more accounts, willingness to grow and develop professionally, customer feedback and peer feedback.
The idea is that for an individual component to pay, the team would have had to meet its overall goals. No local optimizations. Any compensation model over and above base salary and team based goals would have to meet certain design criteria to make sure it adequately rewards individual performance but doesn’t feel punitive to those that don’t make it.
It has to be inclusive… anything that one person is able to do, everyone is able to do. There can’t be some named subset of people able to participate in the plan.
It has to be based on abundance … everyone is able to be at the top every time. We want to build a system that assumes everyone has the ability to be a top performer.
It has to be transparent… whatever we choose to measure will be tracked openly so you can see where you are relative to your peers at all times. The measures and goals have to be clear and attainable.
It has to be cooperative… there cannot be any penalty for working together to achieve a goal. If two people work on a goal together, the reward has to be as much or greater than working on it individually.
It has to be sustainable… we will only ever reward sustainable growth. Creating incentives that encourage people to only look out for short term economic outcomes won’t help the company grow.
My hypothesis is that if we can fairly compensate people by way of base salary, give everyone something extra if we hit our financial targets, and create an inclusive, abundant, transparent, cooperative, and sustainable model for paying one person more than another… we might have a shot of making it work and allowing folks to meet their individual financial goals.
If an employee receives a fair salary, is compensated when the company does well, but decides not to participate in the broader plan… they may not like that they didn’t get anything extra, but at least they’d understand why and know what needed to happen in order to participate in the future. If your good enough to be on the team, that door is always open.
Okay… so what do you think? Is it fair or a slippery slope? What could we do differently? I realize we are a services company, but could these ideas work in a traditional software company? Would a model like this work for an agile team? An agile enterprise? If it would work, what kinds of measures might we consider for software developers and other team members?
In einem meiner letzten Beiträge habe ich bereits über die Bedeutung des Minimum Viable Products geschrieben. Dieses Mal stelle ich nun vier mögliche Strategien vor, Kunden aber auch potentielle Investoren bereits vor dem eigentlichen Launch für ein Produkt zu begeistern und wertvolles Feedback einzuholen.
Das Erklär-Video ist kein Produkt im engeren Sinne, sondern beschreibt dem potentiellen Nutzer die Funktionen, die er in Kürze von dem Produkt erwarten kann. Dieses Video ist entweder ein kurzer Animationsfilm, oder vielleicht ein Video eines bereits funktionierenden Prototypen. Ein gutes Beispiel für ein Video als MVP lieferte Dropbox: Bereits vor Fertigstellung der ersten Release sprang die Zahl der Newsletter-Abonnenten innerhalb eines Tages von 5.000 auf 75.000. Defintiv genug, um ein Gefühl dafür zu bekommen, ob es sich lohnt, weiterzumachen. Es versteht sich von selbst, dass ein solches Video entsprechend beworben werden muss.
Die Landing Page
Auf einer Landing Page landen Kunden in der Regel dann, wenn sie im Vorfeld auf eine Online-Anzeige geklickt haben. Sie ist also eine Art Barometer für den Erfolg der Online-Marketing Aktivitäten. Trotzdem soll sie den Besucher im nächsten Schritt dazu anregen, sich für einen Newsletter zu registrieren. Die größte Herausforderung besteht darin, die Value-Proposition so simpel und eindrucksvoll wie möglich zu transportieren – beispielsweise indem man sie mit dem Erklär-Video kombiniert. Achtung: Eine Landing Page ist nur dann wertvoll, wenn man entsprechende Analyse-Tools, wie beispielsweise Google Analytics, einbindet, um den Erfolg oder Misserfolg auch messbar zu machen.
Das Wizard of Oz MVP
Ein Wizard of Oz Minimum Viable Product gibt an der Oberfläche vor, ein Produkt oder ein Service zu sein, das in Wahrheit so noch nicht existiert. Das US-Vorbild des Onlineversandhandels Zalando, zappos.com, hatte beispielsweise damit angefangen, Schuhe in lokalen Schuhläden zu fotografieren und anschließend online zu stellen. In dem Moment, in dem Kunden diese dann online auswählten, gingen die Gründer von Zappos zurück in den Laden, kauften das ausgewählte Modell und kümmerten sich um den Versand. Wichtig: Hier geht es noch nicht darum zu überprüfen, ob ein Produkt oder Geschäftsmodell skalierbar ist, sondern lediglich darum, eine Hypothese zu testen.
Das Concierge MVP
Das Concierge MVP eignet sich besonders dann, wenn das zukünftige Produkt automatisierte Prozesse beinhalten soll, die so noch nicht abbildbar sind. Ich selbst habe sehr gute Erfahrungen mit dieser Art von MVP gemacht: Für eine Smartphone App wollten wir Veranstaltungsdaten über ein Content Management System auch in der App verfügbar machen. Da die erforderliche Schnittstelle für Datenimport und -umformatierung noch nicht fertig war, wir aber unbedingt den Kunden von unserem Produkt überzeugen wollten, haben wir die Daten eben selbst und von Hand eingetragen – mehrere Tage hintereinander, gerne bis tief in die Nacht. Das war zwar mitunter nicht die spannendste aller Tätigkeiten, aber auf diese Weise konnten wir zeigen, wie sich unser Produkt auf Nutzerseite am Ende anfühlt, ohne dass wir bereits den kompletten Funktionsumfang anbieten mussten.
Der Grad der Anwendbarkeit des MVP-Ansatzes und der hier aufgeführten Strategien variieren sicherlich stark, je nachdem, um welches Produkt es sich letztlich handelt.
Die Grundidee des Minimum Viable Products – sich bei der Produktentwicklung auf einige wenige Kernfunktionen des späteren Produkts zu fokussieren – ist jedoch branchenübergreifend gültig und sollte jedem Product Owner präsent sein.
- Think big, start small – das Minimum Viable Product
- Der Product Designer als rechte Hand des Product Owner?
- Warum wir eigentlich alle Freelancer sind
At Rally, we have teams that ship code to production every day. Some teams ship multiple times per day with zero downtime; we certainly release in small batches. Some teams do Scrum, and some do Kanban. But nobody is holding back code for once-every-10-weeks releases.
So why do we still get everyone together to do “release” planning once per quarter? The quick answer is this: getting together and laying out 12 weeks worth of work forces us to think deeply and get realistic about our capacity. The act of trying to see what work fits in a quarter is a key part of adjusting the number and variety of projects we are attempting. As the SAFe folks say, this meeting is about aligning demand with capacity.
I remember Ronica Roth a few years back struggling with what to call this ceremony. Ronica felt “release planning” was the wrong name, since many companies don’t actually align their releases with these 8-12 week timeboxes. She’s called it “mid-range steering,” which is a bit clunky. In SAFe, it’s sometimes called release planning and sometimes PSI planning, for a “Potentially Shippable Increment.” Rachel Weston Rowell suggests that we call it the “Biggeration.”
Whatever you call it, if you’re doing Agile and you don’t do this kind of planning, you might see:
- High stress from teams frequently switching context
- Way too much work in the system
- Projects that cost 2-3x what was expected because teams over- or under-invested in architecture, scalability, or features
- Long wait times as completed work sits around waiting for another team to get to it
- Finger-pointing as teams blame other teams for not providing the support they need
- Teams continuing to work on projects that everyone knows will never deliver, just because they haven’t stepped back to look at the feasibility of their plan
The problem, of course, is that if you have 50 or 100 people in your group, release planning meetings are really tricky to plan and facilitate well. I’m lucky in that Michael Ball, an internal coach here at Rally, does a great job at planning and running this kind of meeting across three locations simultaneously.
Back when our teams first started moving to Kanban instead of Scrum, we lost the discipline of this big, collaborative, all-day meeting. We’ve since started to do it again, and it’s really helped to improve our predictability, reduce our WiP, and keep features moving.
If you’re just sprinting along and not collaborating around your mid-range plans, you’re missing out.
Need guidance making your first big release planning / PSI planning / mid-range steering event a success? We can help.
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 8: WHO NEEDS ‘EM?
“Do we need managers? It depends.”
Running time 27:02
What role(s) do managers have in your organization? How are managers viewed in your place of work? What does the staffing structure look like?
Leave a comment on this blog or email us at email@example.com
[Intro] Do we need managers? Example of Zappos and Treehouse.
[02:39] Defining the word “boss” and what it triggers and represents.
[07:27] Managerial work: it’s about the nature of the work and how the work is valued.
[09:00] What are the differences in compensation?
[14:50] Workplace design: what does this look like and who decides?
[19:55] The nature of the job responsibilities may dictate workplace design.
[24:35] Getting rid of the word “boss”.
Holocracy: How Zappos could change corporate America
Portland startup Treehouse eliminates the boss, tells workers to manage themselves
What does fulfillment at work really look like?
Who’s the Boss? There Isn’t One
What Is Open Allocation?
How Google Sold Its Engineers on Management
Do your teams want to know how agile they are? And what could be the possible next steps for them to become more agile and lean? In an open space session about Agile Self-Assessments organized by nlScrum we discussed why self-assessments matter and how teams can self-assess their agility to become better in what they do.
Becoming Agile over Doing Agile
There are many checklists and tools for agile self-assessments. Some of them focus on “hard” things agile practices, meetings and roles, while other cover the “soft” aspects like an agile mindset and values, culture, and the conditions for agile adoption in organizations to be successful.
We discussed about self-assessing the teams agility at the nlScrum open space. One conclusion was that most attendants had a strong preference for assessing based upon agile values and mindset to explore if and how their teams are becoming agile. This way of assessing distinct teams where professionals have really internalized what agile is and know why they should do it and how it helps them to deliver value to their customers and stakeholders from teams who are only doing agile or Scrum because they have been told to do so by their managers or organization.
Assessing values and mindset involves asking why certain agile practices and rituals are done. It empowers the agile team by developing a shared understanding of the weaknesses and strengths of their way of working and to decide which steps they will take to become better.
Effective agile teams understand the agile culture, mindset and values. That makes it possible for them to improve their development processes in an agile way. They can use the golden rules for agile process improvement to improve by continuously doing small but valuable improvement actions.
Can teams assess themselves?
As the name suggests, agile self-assessments are intended to be tools for agile teams. The result of an assessment helps a team to know how they are doing to help them improve themselves. Therefore the results of an assessment are intended to be used by the team alone. They should not be used by managers to evaluate the team’s performance or to compare and rate teams.
Question is if you can expect that a team can assess itself? It depends as usual :-). Teams who have just started with agile can find it difficult to take some distance and explore how they are doing. They also might not have enough understanding of the why and how of agile to really assess how they are doing. In such cases an (external) facilitator can help teams to do their first assessments.
Agile retrospectives are another great way for teams to reflect and improve their way of working (read more on how to do them in our book Getting Value out of Agile Retrospectives). They help team to learn observing and analyzing their way of working and define their own improvement actions. Many skills that team members develop doing retrospectives are also usable to do self-assessments, so investing in retrospectives makes sense.
Finally an agile coach can help a team to develop assessment skills, enabling them to do their own assessments in the future. Soft skills matter in IT and agile coaches can help people to learn and improve those skills. Which is also an effective way to help a team to become agile in an agile way.
I like the Open Space Technology (OST) approach; it’s a great way to get people together and discuss those things that really matter to them. At the nlScrum Meetup about Scrum Maturity Models hosted by Xebia we did an open space session where we exchanged our experiences with agile self-assessments. This is what we came up during our stand-up meeting:
Photo taken by Doralin on February 6, 2014 at the nlScrum meetup hosted by Xebia
I already talked about assessing values over practices and why self-assessments are intended to be used only by the team and not by their managers. In our discussion in the open space and afterward on the meetup forum, several tools and checklists were brought up to do self-assessments and also several models and frameworks were mentioned that can be used to develop your own assessment. Some of them were already on my list of Agile Self-assessments tools and checklist, but there were also some new ones which I added (thanks guys!):
- Agile Adoption Framework by Ahmed Sidky
- Organizational Agile Transformation by LeadingAgile
- Agile Addresses “The Five Dysfunctions of a Team” from InfoQ
- Drexler/Sibbet Team Performance Model
- Personality types: Myers-Briggs Type Indicator and DISC assessment
- Team Dynamics: Satir Change Model, Human Dynamics and Tuckman’s Stages of Team Formation
Self assessing your agility
Have you done agile self-assessments? Did they help you to improve and become more agile and lean? I’d like to hear from you!