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.
My twitter stream delivered an interesting quotation about quotations yesterday. This one, and the tweet came from Bob Marshall:A quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business.
Quotations indeed take a fairly large part among tweets and other social web shares. When something troubles us at work, whether we are looking for a solution to a technical or to an organizational problem, and if talking it out with friends and colleagues is not enough, or we are shy and/or unwilling to speak, we find outlet in sharing quotes by reputable gurus, and those quotes reflect how and what we think about this problem.
I only in part agree with the quote by A. Milne above. The habit of using quotations can be perceived as lazy thinking, sometimes. However, I don’t think that people who share quotes or links online are the lazy ones. On the contrary, they are the ones who do think. It’s just that for the time being they are shy to step forward with their opinion, expressed in their own words. It might be even scary for some, to stand out and say: yes, these are my thoughts, and my words and I’m ready to be accountable for them. We are all human, and we all have things that we are not yet ready to let out to the outer world. This might be out of fear, or out of passive-aggressive reactions, or … <insert your reason here>. We might be too lazy to care about building formal logical discourses so as to pass on the message to those who do not share our thinking right away. Some people seem to resonate naturally with each other, and with some people a heavily geared-up persuasive rhetoric has to be used. Take a moment and think: which people in your social circles throw links or tweet quotes instead of writing or speaking up? They are just not yet ready to make this leap, the shift from the safe protection of quotes and references to the scary uncertainty of how the world and others would react to what would then officially be treated as their own opinion. Absolutely, they need to be encouraged to speak out and to write up.
The scary uncertainty got hold of me and of my article on self-organization earlier this week. I expressed my own opinion, backed up by intuition and personal experience, and didn’t pay much attention to references, details and credibility proofs. If I did, it would take a book, not just one article. Anyway.
There’s another controversial subject that probably has many heads in software development thinking about it. I want to bring it forth, but this time I will take a safe protection of George Lois, an advertising guru, who wrote the book called “Damn Good Advice (For People with Talent!). Software development is a creative pursuit, at least, when it comes to the ideas part, so I was delighted to see that a recognized creativity guru thinks about teamwork along the same lines that I do. The subject of groupthink, and the dynamics of software development teams working efficiently together has preoccupied me for quite some time, but I will hold back my thoughts for now, letting George Lois speak instead:Team work might work in building an Amish barn, but it can’t create a Big Idea.
The accepted system for the creation of innovative thinking in a democratic environment is to work cooperatively in a teamlike ambience. Don’t believe it. Whatever the creative industry, when you’re confronted with the challenge of coming up with a Big Idea, always work with the most talented innovative mind available. Hopefully.. that’s you.
Avoid group grope and analysis paralysis. The greatest innovative thinker of our age remains Apple cofounder Steve Jobs, a modern-day Henry Ford. Jobs was not a consensus builder but a dictator who listed to his own intuitions, blessed with an astonishing aesthetic sense.
Everybody believes in co-creativity — not me.
Be confident of your own, edgy, solo talent.
Wait, wait. Before you throw rotten tomatoes, George Louis does give credit to teamwork, and I do, too. Here’s what goes next in the book:
Once you’ve got the Big Idea, that’s where teamwork comes in – selling the Big Idea, producing the Big Idea and bringing the Big Idea into fruition.
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!
Retrospective: looking back on or dealing with past events or situations.
In projects, it is a meeting to discuss what was successful, what could be improved, and how to incorporate successes and improvements into future initiatives. In Scrum, the purpose of a retrospective is to inspect and adapt with regards to people, relationships, process, and tools seeking to implement improvements to the way the Scrum Team does its work.
If you believe that you are the very top of your industry and your competition cannot ever touch you, this article will not help you. Hope you are right….To everyone else, keep reading.
So you acknowledge that maybe you might need to improve and grow… but here are 7 signs that you’re not doing sprint retrospectives right. Retrospectives might still be a waste of time if:
- You think you are smarter than your employees or peers and thus believe they have nothing to offer you.
- You just like to be in control. After all you worked hard to get to the position you are and they should just respect what you tell them to do.
- You think that people are the problem and you really just get tired of their complaints and whining.
- You think that if somebody has an issue with the way we do things around here, they are just a trouble-maker and should get with the program, or just move on.
- You think that if somebody thinks they can do something better, than they should just go do it themselves to prove their worth and stop asking for help all the time like they cannot cut it on their own.
- You promote continuous improvement, as long as nobody makes your area look bad, or expects you to have to do anything new or different. After all we really just want to look good and promote what we are doing.
- You really are just too busy.
You are right then! Retrospectives and continuous improvement initiatives are in fact a waste of time for your organization or team. Your employees and peers will not contribute anything of substance anyway out of fear. Sadly, I suspect there are elements of this thinking more often than we would like to admit. But there is hope, and these attitudes can change.
To succeed, continuous improvement requires a supportive culture – one of safety and respect. Establishing the culture can be very hard. The vision and expectations for the culture must be explicitly clear and communicated effectively to all. Those who are hindering the adoption of the culture must be refocused immediately. More of this later….
In a culture of safety, ideas and opinions are respected and not criticized. Dissenting opinions are welcome and people are not punished and devalued for them. It is understood that healthy debate of conflicting views often results in better solutions and sharing of new knowledge. People are not viewed as the problem, and problems are viewed as opportunities.
It takes time to establish a healthy continuous improvement mentality. I suspect that is why Scrum came to build it into the process framework – to ensure that new teams were focused on getting this culture established and healthy. But this is very hard to do well and often gets abandoned too early.
Over time, high performing empowered teams and organizations just build it into how they work and it is not so much a “scheduled reoccurring event”, as just how we do things here. It becomes the culture. It occurs spontaneously all the time as part of the norm without requiring a focused activity to ensure that it gets done.
So, if you think a scheduled meeting called a retrospective is a waste of time or not needed because you have achieved a true culture of spontaneous improvement as a way of working, then I applaud you!!! To everyone else, I suspect you still have some work to do.
Perhaps the first retrospective your business or team should conduct is to determine why they think they do not need an improvement program.
Leadership should immediately resolve impediments that are holding them back from realizing the benefits of the ideas that those closest to the work can offer.
While we have made great strides in challenging late integration, lack of collaboration and the obvious need for automation, we still have a ways to go when it comes to ideation, and the dangerous amount of certainty we have when it comes to products and people.Assume Delivery is a Constant
I once had a physics teacher who often said, “Assume acceleration is a constant,” just before he took us into the land of big thinking. Before we stepped too far into the land of complex learning, he tried to reduce the number of variables so we could focus on the more complex aspects ahead. I use this same idea when working with product teams by helping them to work towards delivery as the constant.
Of course delivery is never a constant, but it is tangible and often deterministic. Eco-systems where teams build and sustain adaptive eco-systems with well structured code, high levels of automation, rich collaboration and strong visualizations tend to do well with delivery, and often learn to deliver more than ever before. Thoughtful and aware teams (and programs) quickly realize that as product delivery becomes a constant, product discovery looms large on the horizon, and it is a land that’s messy, clumsy, non-linear and non-deterministic. Best practices rarely help.Product Arrogance
So, for a minute, assume you’ve made delivery a constant. How sure are you that you are producing the right thing? How do you decide what is your next best investment, and how do you validate your choice? As a tool to help you, I offer of the idea of product arrogance. Inspired by Nassim Taleb‘s use of Epistemic Arrogance in The Black Swan, or “the difference between what you know and what you think you know,” Product Arrogance is simply defined as “The difference between what people really need and what you think they need.”
Now, while you are still assuming delivery is a constant (which is no small challenge on its own), ask yourself, “How wrong are you?” as it relates to the product ideas you are chasing. Or examine the flip side, “How sure are you that you are building the right thing?” What makes you sure, and what makes you unsure, are areas of thinking and learning that confront teams when they’ve worked hard to smooth out delivery. It does not matter if they are using Scrum, Kanabn or NonBanThe Myth of Certainty and the Measures of Realities
Many teams I coach talk about a “definition of done,” one of many emergent ideas from the agile community that has helped people learn to deliver. Work deemed done, in the form of working product in a meaningful environment, improves measures and learning, but sometimes induces a false sense of certainty and a dangerous level of confidence that success is near.
Unfortunately, products are only done when they are in use. Watching users in the wild often teaches teams that what they were certain about. “I am sure people will need to …” is not what people need. It may be that one person’s arrogance, or fear of “not being a good product owner,” is the issue. It could also be the simply fact that the product ideas were right and the market changed the game. When this happens, shedding arrogance and embracing evidence is your best tool for building less of the wrong thing (which allows you to learn fast and spend less).Embracing Wrongness
Product development, which goes far beyond product delivery alone, is an act of being wrong often. Like science, ideas are tools for learning and need to be viewed with less certainty than an automated test. Where people are involved, as opposed to code, automation is more difficult. People are beautifully chaotic and take unexpected journeys into interesting and uncharted territories. Being ready to be wrong is one way to be ready to learn, and product learning something we all need to practice, and practice and practice.
If you have practical experiences to share, please chime in so we can collaboratively learn from being wrong collectively.
Guest post by Ellen Gottesdiener, Founder and President of EBG Consulting
If you’re on a team that’s transitioning to lean/agile, have you experienced troubling truths, baffling barriers, and veritable vexations around planning and analysis? We work with many lean/agile teams, and we’ve noted certain recurring planning and analysis pain points.
Mary Gorman and I shared our top observations in a recent webinar. Our hostess, Maureen McVey, IIBA’s Head of Learning and Development, prompted us to begin by sharing why we wrote the book Discover to Deliver: Agile Product Planning and Analysis and then explaining the essential practices you can learn by reading the book.
As we work with clients—product champions and delivery teams for both IT and commercial products—we strive to learn continually. And that learning is reflected in the book. It tells you how to take actions that will accelerate your delivery of valuable products and will increase your enjoyment in the work.
9 Pain Points to Prevent, Mitigate, or Resolve
Here’s what you need to know, in a nutshell — the 9 pain points we most often see in planning and analysis. (Note: when you read “team,” it means the product partnership: business, customer, and technology stakeholders.)
Inadequate Analysis: Teams start to deliver and then realize they don’t know what not to build. Some teams, making a pendulum swing to agile, abandon analysis, trying so hard to go lightweight that they go “no weight.”
Poor Planning: Teams waste a lot of time in planning and meeting without first having a shared understanding of the product vision and goals or the product needs for the next delivery cycle. Planning might be taking too long, or, on some teams, the product champion and delivery team mistakenly think they have sufficient information to plan and deliver.
Frazzled Product Champion: The product champion (what Scrum calls the Product Owner)—the person who makes decisions about what to deliver and when—is frayed, frustrated, overwhelmed, and overstressed. These people, the keepers of the vision and the holders of political responsibility for the value of the product, often struggle mightily to balance their strategic product-related responsibilities with their tactical ones.
Bulging Backlog: Teams accumulate monster, huge backlogs (baselines) of requirements, often in the form of user stories. Every possible story or option for building the product is weighing down the backlog and squeezing or obscuring the highest-value stories.
Role Silos: The team members are acting according to their formal roles, and not focused on the goal. For example, someone always writes the stories, someone else does the testing, and someone else develops. They don’t have a shared way to communicate or a shared understanding of the product needs.
Blocked Team: Teams. Just. Get. Stuck. Waiting. On hold. It even happens to teams using high-end agile project management tools, which are supposed to help them stay organized and efficient. Some of these teams are overwhelmed by the plethora of requirements (see “Bulging Backlog”). Or they have unclear decision rules or don’t know how to define, quickly analyze, and act on value-based decisions. We’ve also observed teams with too few “fresh,” well-defined requirements, ready to pull into delivery.
Erroneous Estimates: Estimates are way off (dare I remind you, most of us underestimate our work). We’ve observed teams that, even after three or four iterations, can’t stabilize their cycle time or speed. Often, they lack clarity about complex business rules and data details, or about the product’s quality attributes (such as usability or performance). That often contributes to our next observation.
Traveling Stories: Traveling stories (no, not traveling pants) are ones planned for a given iteration or release but end up being pushed to a later date. (As you may know, a story is a product need expressed as a user goal. Many agile teams use them, following the canonical format: “As a…I need to…so that…”) Occasionally stories travel due to unexpected technical issues. More often it’s because the stories are “too big” to be completed in a given release. Or at the last minute the team discovers they need an interface. Or they find expected business rules for an unexplored regulation. Or data dependencies pop up. Teams are not thin-slicing their stories based on value, and so they’re unable to finish.
Oops: Teams find unpleasant surprises during demonstrations and reviews, or weeks (or months) after delivery. Or worse, they aren’t delivering the right thing, the right value.
Context-Conversation-Collaboration: Pain Relief
You may have heard of card-conversation-confirmation, originated by Ron Jeffries and his coauthors. These “3Cs” explain the critical aspects of user stories, a part of the planning cycle.
Borrowing from Ron, we’ve found 3Cs of our own: agile product planning and analysis means attending to context, conversation, and collaboration. And these practices relieve the 9 pain points we’ve outlined.
Watch the Video
Hear more about our observations of development teams, learn about the underlying principles that we’ve seen work in all kinds of teams, and see how Mary and I integrated them into Discover to Deliver. The link to the video is here. Let us know what you think.
Troubling Truths, Baffling Barriers, and Veritable Vexations. What are your pain points around agile planning and analysis? Share them with us in the comments section below.