Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).
How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.
Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of value at least every 30 days. One voice speaks for the customer. A coach and change agent helps the team and the organization improve.
Scrum also creates a context where the Agile values and principles can thrive. "We are uncovering better ways of developing software by doing it and helping others.... We value individuals and interactions over processes and tools.... Our highest priority is to satisfy the customer through early and continuous delivery of valuable software...." As anyone who has attended my Agile company workshop knows, if you use the values of the Agile Manifesto as a guide, you generally make pretty good decisions about how to run your company.
So how do SAFe, DAD and LeSS stack up for scaling Scrum and Agile? I will look briefly at each one, by examining what it claims to be, what its core values are, and give an assessment of how its values and principles correspond to those of Scrum and Agile. For reference, let's start with the Waterfall.
Classical Management or "Waterfall"IMHO, the waterfall is simply adapting the management structures created to manage the automobile industry in the early 20th century to software. Assembly lines assemble components in steps defined by the engineers and managers who watch over unskilled and recalcitrant workers. Companies seek to maximize outputs and profits, and minimize costs. According to Steve Denning, the underlying principles are managers as controllers, coordination through bureaucracy, optimizing utilization, and communication primarily as a from-the-top broadcast.
This approach worked extremely well until about the 1960's or 1970's. Since then it has come increasingly under strain. Deloitte's Center for the Edge predicts that 70% of today's Fortune 1000 companies will not be there 10 years from now. This model doesn't work any more.
Agile and Scrum represent a rejection of this approach for the simple reason that it fails spectacularly when applied to producing software. This also makes clear why scaling Scrum is such a challenge for organizations. It is based on values and principles that are incompatible with the rest of the organization.
Summary: On a 0 to 10 scale, how likely am I to recommend this approach to scaling Scrum? 0.
It's failing. Time to move on. (And yes, I know, most every company on the face of the earth is organized this way. But look at the exceptions: Spotify, Guidewire, Morning Star, WL Gore. There are better ways to organize your company.)
Scaled Agile Framework (SAFe)The Scaled Agile Framework has been getting a lot of attention lately. There is a budding certification program, a roadmap for implementation (with lots of training), and support from various established companies (like Rally). As I write this, the SAFe Academy is listing 5 trainers and claiming over 1000 certifications have been earned at their trainings.
SAFe is "an interactive knowledge base for implementing agile practices at enterprise scale." The SAFe big picture addresses the enterprise at three levels: Team, Program, and Portfolio. At the Team level, SAFe looks a lot like Scrum, including of course XP practices. Not every sprint necessarily produces a potentially shippable increment, but this should happen frequently, possibly after a hardening sprint.
At the Program Level, the efforts the Agile teams are aligned and integrated to serve the needs of the enterprise and its stakeholders. SAFe provides a fair amount of detail on how to do this. The Portfolio level provides similar product and goal alignment between the investment levels and the operational levels of the organization.
What does SAFe value? According to the Core Values page, "we know that Lean thinking, the Principles of Product Development Flow and the extensive benefits that Agile development (Agile Manifesto, Scrum, XP technical practices, Kanban) all play important roles in defining the principles and practices of SAFe," but SAFe "really values" Alignment, Code Quality, Transparency and Program Execution.
This is the statement that worries me about SAFe. The values, principles, and practices that enable Scrum, Agile, and Kanban to work their magic, are important, yada, yada, but subjugated to "what we really value." There is little reason to challenge Code Quality and Transparency, but Alignment and Program Execution mean the development teams are expected to do what top management tells them; the difficulty that "mere mortals" have convincing top management to pursue new innovations is a well documented cause of large organizations' vulnerability to disruptive innovation.
Summary: On a 0 to 10 scale, how likely am I to recommend SAFe for scaling Scrum? 4.
It's better than waterfall, and existing managers will feel at home. But its lack of commitment to Agile Values, especially continuous learning and people over process, means that there will still be managers making decisions over the heads of people who understand the problem better than they do. This does not bode well for the acceptance in the trenches of SAFe and it will be interesting to see how many of SAFe's reference customers are still boasting about it 5 years from now.
Disciplined Agile Development (DAD)After I got over the huge IBM logo on the cover page, I found quite a bit to like about DAD. This process framework is "a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value life cycle, is goal-driven, and is enterprise aware." What does DAD value? It's top four priorities are: 1) People first 2) Learning-oriented 3) Agile and 4) Hybrid.
Hybrid means that DAD also draws on other, more traditional sources, especially the various flavors of Unified Process for governance and life-cycle management. Projects are divided into three phases, Inception, Construction and Transition. Compared to Scrum, DAD puts more emphasis on architecture and technical risk reduction through the designation of an Architecture Owner. (DAD also changes many of the names of Scrum, so the Scrum Master is now the "Team Lead").
Back in 2008, I wrote that people and responsibility were missing from the Rational Unified Process. This latest evolution is clearly a huge step in the right direction. The notion of "Potentially Consumable Service" as opposed to "Potentially Shippable Product" is intriguing. OTOH, our understanding of risk has grown substantially since the days of RUP to include Market Risk and Social Risk, among others. Furthermore, this approach does not look very close to the way successful startups (Facebook, Spotify, Guidewire) are actually scaling up.
DAD now has a certification program. As of this writing, there are 9 trainers and 29 certified DADs.
Summary: On a 0 to 10 scale, how likely am I to recommend DAD for scaling Scrum? 7.
Much good stuff, and nothing obviously evil. My own experience both with technical risks and chief anythings (developer, architect, project leader, etc.) lead me to be skeptical about those aspects, but not so skeptical to throw the baby out with the bath.
I almost gave DAD an 8, but I lowered the score for pitching IBM tools in the white paper (compare to LeSS which encourages Open Source).Large Scale Scrum (LeSS)"Large-scale Scrum is regular Scrum applied to large-scale development." Craig Larman and Bas Vodde set out to manage large projects while staying within the constraints of vanilla Scrum. They have developed two frameworks depending on the size of the project. Because they remain true to the constraints for Scrum, Large Scale Scrum cannot be considered a practice. It is an organizational design framework.
Framework-1 is for projects of up to around 10 teams. The basic roles are unchanged, but some the of the meetings are changed and some are replicated at the-cross team level. For example, Sprint Planning 1 may be held with representatives of each team, rather than all members of all teams. Similarly, a cross team retrospective with representatives of each team facilitates overall improvement. Teams are organized as Feature-Teams. Other inter-team coordination meetings may be added, in the form of Scrum of Scrums or Open Space meetings.
Framework-2 is designed for even larger projects. Framework-2 adds an additional role, the Area Product Owner, who assumes product Ownership of a major section of the product. At this point, an Overall Sprint Review and Retrospective is also added to ensure overall product consistency and process improvement.
Beyond Scrum, there are many technical practices which are helpful and encouraged to enhance coordination: Continuous Integration. Internal Open Source (any source can be modified by anyone), Team-controlled build systems. These become even more important for multi-site projects. Pervasive video, Free Web 2.0 tools (skype, google docs) and open source tooling reduce the friction between teams.
Summary: On a 0 to 10 scale, how likely am I to recommend LeSS for scaling Scrum? 9.
One the plus side, LeSS is clearly in the Scrum and Agile tradition. It is the simplest of the three approaches and makes only a few changes to vanilla Scrum. When I look at Spotify, an organization that has scaled from 6 to 1200 staff members, I see a company architecture that is very close to LeSS. It will be a very natural approach for small organizations that are scaling up as they grow.
As with any Scrum transition, moving to LeSS is a complete architecture-redesign. Informed buy-in is the key to acceptance. I can imagine in larger companies, that could be a challenge.
Overall SummaryHow likely am I to recommend these approaches?
- Waterfall: 0
- SAFe: 4
- DAD: 7
- LeSS: 9
SAFe comes in a close second. With its training academy, licensed trainers, and traditional management-friendly approach, it is clearly resonating well and is poised to do well in the market. (The reports I have gotten on the quality of the courses is strongly mixed. Some say horrible, others seem to be eating it up).
Will SAFe be enough of break with the waterfall to save their customers from being part of the 70% that won't be in the Fortune 1000 ten years from now? Fundamentally it's people separated by two or three layers of management from the real world setting direction for those who get it. Not promising.
On paper, DAD has come a long way since RUP. It's values are more in sync with Agile than ever. Today, DAD has more trainers than SAFe, but hardly anyone has actually taken the course, so is it really resonating with the market? The other question I have is whether its practitioners have really left their RUP days behind them. Do they really believe their new-found values? However, given the choice between SAFe and DAD, I would clearly chose DAD, especially if your coaches really understand Agile and the values it represents.
LeSS is more two guys with a book at the moment (3 books, actually). Their approach is sound, but there is no institutionalised marketing. While the Scrum Alliance currently lists 57 Certified Scrum Coaches, the "Black Belt" of the Scrum world, this is not strictly speaking a LeSS certification, nor are any LeSS courses or certifications being offered. On the other hand, that's about where Scrum was 10 years ago. People reading books, and deciding to change. For my money, it's time to start reading Larman and Vodde.
P.S. This article represents a first pass at comparing the frameworks. Does it sound right to you? I would love to hear from practitioners of these approaches to share the experiences and/or improve this article!
Getting started with ATDD
Have you ever been in this situation?
Then this article is for you – a concrete example of how to get started with acceptance-test driven development on an existing code base. Read on.
Calling all project managers: does the idea of your organization going Agile fill you with dread? Are you wondering where you fit in Agile’s “self-managing teams”? Do you want to sharpen your skills in one of the fastest-growing areas of project management?
As we gear up for the 2013 PMI Global Congress, kicking off tomorrow in New Orleans, Louisiana, we invite you to join us at the Rally booth for some Agile project management love.
Find out why more and more organizations are adopting Agile, and how Agile skills can boost your career. Pick up a copy of our Project Manager’s Agile Survival Guide. Try a demo of Rally. Learn how Agile takes program management to the next level. Get answers to your burning Agile questions, like ...
- Agile: passing fad, or growing trend? Absolutely a trend: 34% of PMs now use Agile, and 62% of those PMs are Agile-certified.
- Why are more companies choosing Agile? Agile helps organizations be innovative and responsive in a competitive market. Agile methods have been shown to increase productivity by 25% cut time-to-market by 50%.
- Will Agile put me out of a job? Unlikely: Agile NEEDS project managers -- in fact Agile PM jobs have grown 1,750% since 2005 (according to Indeed.com.)
- How is Agile different? Instead of being planned and executed sequentially, Agile projects are incremental (break up a large-scale project into doable pieces) and iterative (produce working code/product at the end.) Instead of command-and-control team management, Agile teams are “self-managing”: project managers guide, enable, and facilitate their work.
- How do I find the Agile role that’s best for me? Do you understand people and group dynamics? You might be a good Scrum Master. Are you good at managing expectations and working with stakeholders? Then you might be a good Product Owner. Get the Survival Guide for more tips.
You’ll find the Rally team at booth #300. We look forward to seeing you there.Jenny Slade
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 6: THE TOP WORKPLACES
“Some of the highest performing companies in the country have the culture thing figured out, they nurture their internal brand as a strategic asset that stimulates a strong external brand.” – Ted Sickinger
Running time 29:04
If you work in a place that you really think could be a top workplace, what is it about that place that makes it so? If you have some opinions about what would keep a workplace from showing up on such a list, we’d be interested in your thoughts on what those conditions are.
Leave a comment on this blog or email us at email@example.com
[Intro] Identifying key attributes to top workplaces.
[01:44] “[Nurturing a company’s] internal brand as a strategic asset … stimulates a strong external brand.”
[05:03] Open vacation “policies” … as long as you get your work done.
[09:59] The responsibility of managers and/or leaders in implementing these types of “stances” in an organization.
[16:25] The move from a paternalistic caretaking organization to “we’re all adults here” type of culture.
[20:09] The size of an organization may impact the type of culture, stance and/or policy an organization engages in.
[24:17] The link between people’s happiness and their relationship with their immediate superior. Are organizations paying attention to who gets put in leadership positions and what type of training they are offered?
[26:49] Top workplaces run the gamut across industries.
Balance of Work and Life by Ted Sickinger
The Year Without Pants by Scott Berkun
Joan sits on the bus, her scarf wrapped tightly around her hair. She jumps when a young man next to her fumbles to withdraw his vibrating phone. She yearns for a time when her fear would be tinged with excitement at the possibilities of connection.
John sits at his desk, his headphones blocking out the humanity around him. He awakens when his manager approaches. The manager just walks by. Unnoticed and unappreciated his defences swell and he vows to ignore the needs of that man.
The Guardian reports that the Japanese youth are choosing to shun sex. This may result in the population reducing by a third by 2060. Apparently they have a preference for designer clothes over the complication of such a messy connection.
Mark manages a team of 48 operators (8 rows of 6). He smiles patronisingly as he watches them, with their headsets on. Sitting on his throne, monitoring their conversations, he keeps them at a distance, denying them the honour of connection. He also sleeps alone.
Anisa works in Shoreditch, at a startup that is never quite enough. Another line numbs the pain of her misfortune. She reminds her colleagues how much crazier it was in “The Valley”. Her gloat denies herself and them connection.
After work we share stories in The Wellington, on the corner of Drury Lane, empathising, the connection is strong despite our despondency. We lament the actions of those who fear the connections that bind us. That can bind us all.
Summer is over, the sun is almost gone, but fortunately here comes a new version of iceScrum and iceScrum Pro!
It brings several important bug fixes and a brand new feature for iceScrum Pro: the task board.R6#10 – R6 – Sprint 10 (24/08/2013 – 24/10/2013) New features and improvements
- ICESCRUM-581 – Contextual display of tasks and actions available through touch-friendly buttons
- ICESCRUM-545 – Quickly and temporarily switch user to update tasks
- ICESCRUM-766 – Include comments (read-only) in task and story web service API
Please note that some issues may remain when creating / updating tasks. We are working on it.
- ICESCRUM-768 – Comments aren’t kept when accepting a story as urgent task
- ICESCRUM-777 – Comments missing from task quicklook
- ICESCRUM-778 – Tooltips aren’t HTML escaped
- ICESCRUM-781 – Impossible to update task when other users browse the sprint plan
- ICESCRUM-787 – Latest opened project isn’t opened when logging in
- ICESCRUM-786 – Private project name can be displayed to outside users
- ICESCRUM-769 – Wrong remaining time (0) in toolbar when switching to table view
- ICESCRUM-770 – Latitude missing in table view (iceScrum Pro)
I’ve seen a lot of bad staff meetings over the years. Everyone feels compelled to attend because the boss called the meeting. The boss sets the agenda but sometimes doesn’t have time to think it through. There are urgent issues that everyone else knows the group needs to discuss, but they aren’t front-of-mind for the boss, so they’re not on the agenda.
What if your staff meetings always focused on the most burning issues? What if you were able to resolve five to six issues rapidly? What if everyone was deeply engaged in the meeting? At Rally, we’ve been using the Lean Coffee technique to transform staff meetings, and it’s spreading throughout the company. Here’s how it works.
First, we gather topics for the meeting. Since we’re distributed, we collect topics all week tagged #leancoffee in Flowdock. On Monday afternoon, I move the topics to a voting spreadsheet. Each meeting participant distributes three votes across the topics they want to discuss. Thus, at the start of the meeting, we know what the most burning issues are.
If your team is co-located, you can do this with sticky notes at the start of the meeting. But the advantage of raising #leancoffee issues in advance in Flowdock is that some of them get discussed asynchronously and are resolved before the meeting even starts.
As facilitator, I start a seven-minute timer for the first topic, and we let the discussion run. At the end of seven minutes, I ask for a thumbs up, sideways, or down from everyone on whether we should continue the topic for three more minutes. Once a majority wants to stop, we move on to the next topic. Sometimes, we finish discussing a topic even before the first seven minutes are up.
What’s nice about this approach? We work through the most burning issues very fast. Anyone can raise a sensitive topic and it often gets voted up even without support of the meeting leader. Finally, you can easily sit out of a topic you’re not interested in and process email during that time.
Seven minutes is not a lot of time, and so we tend to move to action quickly. Our R&D leadership team holds our staff meeting for 40 minutes once a week, and we often process half a dozen or more contentious issues during that time.
How have you been using Lean Coffee in your business?Alex Pukinskis
Did you see Dwayne Phillips’ post today, Adding People to a Late Project? Dwayne says:
Adding people to a late project only makes it later. We have known this for decades.
Especially in the article he refers to, it seems as if there might be no end to the number of people added.
Did anyone ask the people on the project if they needed more people? Maybe they needed to know which requirement is top on the list. Maybe they needed acceptance criteria for each feature. Maybe they needed each feature to stay put for more than a nanosecond. There is more than enough blame to go around for this particular project. Most of the blame has nothing to do with the developers and testers.
Now, if they had asked me what I would do, here is my plan.
- What is the most important thing people need to do to sign up for health care? Get a cross-functional team to work on that, get it to done, and make sure it works. Use reviews, acceptance criteria, release criteria, whatever it takes to finish the work. Timebox that work to one week. Make sure you have performance tests. Roll it out. (Oh, do not let people work overtime. Make sure they can keep to a sustainable pace.)
- What’s the next most important thing? Do that in the second week.
- What’s the third most important thing? Do that in the third week.
- Now you have a shot of understanding the architectural needs. Go fix the underlying architecture. Make sure you have unit tests, integration tests, database tests, performance tests, and oh yes, system tests. But the tests that are key are underneath the GUI. They will tell you more than any GUI-based tests. Yes, you must test the GUI too. But the under-the-GUI tests will tell you the performance.
- While you are fixing the architecture in week four, if you have enough people, you set a group of people to fixing the overall performance. I suspect if you fix the architecture, you fix the performance. If not, you buy enough server capacity to fix performance.
I don’t know the culture of the project. I don’t know how many people are on this team. Is it a program or a project? Did they have silos to start? Did they think they could use waterfall?
I empathize with the technical people on the project. They were and are the victims of poor project management decisions and poor management decisions. On the other hand, they could have coded defensively with many tests. Maybe they did. They could have tested defensively with many automated tests. Maybe they did. In that case, they are ready for this phase, the “other 90% of the project.” Because they are deep into the 90% Schedule Game.
I bet these people are smart enough to work themselves out of this, by using timeboxes. The question is this: Are the managers smart enough to let them?
Last month we released a new Snippets tool that allows you to easily create syntax highlighted code snippets to share with team members. While the tool has been widely accepted, many users asked for the ability to insert these code snippets inline with wiki pages, tickets, messages, etc. We listened and just released this updated functionality. Here is how it works:
Create the snippet and copy the markup reference (see below).
Paste the markup reference into any wiki page, ticket description, ticket comment, merge request comment, message, etc.
Save and your snippet will now show inline. Any changes to the main snippet will reflect wher ever it is embedded.
If you do not have the Snippets tool installed, check out the release announcement for instructions on how to install it.
We hope you enjoy this new feature. Happy coding!
Wieso tun wir uns nur so schwer damit, eine für die Veränderung bereits getroffene Entscheidung auch tatsächlich umzusetzen? Eigentlich ist uns vollkommen klar, dass es uns danach besser gehen würde und trotzdem gehen wir den letzten, alles entscheidenden Schritt nicht. ScrumMaster sind Change Agents und gehen somit auf die ständige Suche nach kontinuierlicher Veränderung bzw. Verbesserung. Allerdings werden sie häufig mit einer schier unüberwindbaren Kraft konfrontiert, die alles tut, um Veränderung zu vermeiden: dem kleinen Feigling.
Mit der anstehenden Entscheidung in Richtung “Veränderung” (z.B. mehr Sport treiben, andere ausreden lassen, mehr delegieren statt alles selber machen, etc.) macht er sich eindrucksvoll bemerkbar und tritt in einen inneren Dialog mit uns. In diesem führt er einen bunten Blumenstrauß an Gründen auf, warum eine Veränderung nicht unbedingt sein muss, keinesfalls klappen kann oder zumindest der jetzige Zeitpunkt dafür vollkommen falsch ist. Als Meister der Aufschieberitis ist der kleine Feigling von Haus aus Pessimist mit wenig Bereitschaft zum Risiko. Meine Hypothese: der kleine Feigling – eine Mission Impossible für ScrumMaster?Mit Musterunterbrechungen gegen den kleinen Feigling
Was tun, um den kleinen Feigling zu überlisten? Was tun gegen den inneren Schweinehund, gegen Stillstand, gegen die Angst, etwas Falsches zu tun? Sprachliche Musterunterbrechungen können Abhilfe leisten. Sie unterbrechen Routinen mittels Sprache und verwirren das Handlungskonzept des Empfängers, indem sie ihn mit neuen, unüblichen Perspektiven konfrontieren. Auf diese Weise werden mentale Freiräume geschaffen, die die Tür für andere Denkwege öffnen und so ungeahnte Ressourcen freisetzen. Ein wichtiger Hinweis: Sprachliche Musterunterbrechungen sind für seinen Konsumenten unkonventionell und provokativ, z.B. wenn unterstellt wird, man wäre ein hoffnungsloser Fall und unfähig für eine Veränderung. Ziel einer solchen Intervention ist, eine energiegeladene Haltung des Widerstands zu erzeugen, die zu einem radikalen Umdenken beiträgt. Provokationen verlangen jedoch vom Anwender (ScrumMaster) Fingerspitzengefühl (Wie weit kann ich gehen?). Ich möchte euch meine drei wirksamsten sprachlichen Musterunterbrechungen anbieten und einladen, sie auszuprobieren.Das Muster meines Gesprächspartners ins Leere laufen lassen
Eine effektive Methode, um ein Handlungsmuster zu unterbrechen, ist das Schweigen. Euer Gegenüber trifft eine Aussage, die ihn in seinem aktuellen Problemmuster bestätigt. Zum Beispiel: “Ich bin jetzt 52 Jahre alt. In diesem Alter ändert man sich nicht mehr.” (Vermeidungsstrategie) Folgende Musterunterbrechungen sind in einem solchen Fall angemessen:
- Starrt euer Gegenüber an, als hättet ihr gerade einen Außerirdischen gesehen.
- Nehmt wortlos einen Notizblock, schreibt den gesagten Satz eures Gegenübers auf und wartet schweigend auf eine Reaktion von ihm.
- Atmet tief ein und anschließend langsam und hörbar aus.
Jede dieser Musterunterbrechungen löst eine Reaktion aus und tut ihre Wirkung. Garantiert. Alleine die Tatsache, dass die Verunsicherung über euer Schweigen ihn dazu bewegt, seine Aussage zu rechtfertigen, unterstützt den Veränderungsprozess nachhaltig. Dann heißt es: dranbleiben!Mit Beharrlichkeit dem Muster meines Gegenübers zustimmen
Zeigt eurem Gegenüber, dass ihr seine Sicht absolut verstehen könnt und bleibt dabei. Angenommen euer Gesprächspartner konfrontiert euch mit den Worten: “Bei anderen mag das mit dem Priorisieren funktionieren, aber in meinem Fall ist das einfach nicht möglich.” Was tun? Probiert es mit beharrlicher Zustimmung, zum Beispiel: “Ja, das sehe ich ganz genauso. Alle anderen bekommen es hin, nur bei dir ist es aussichtslos. Das hab ich schon gesehen, als du zur Tür rein gekommen bist”, ODER “Wäre ich an deiner Stelle, ich würde das Gleiche sagen.”Verschlimmerungstaktik
Wenn ihr wirklich sicher gehen wollt, dass euer Gegenüber sein Muster (zumindest kurzfristig) unterbricht und den Negativstrudel verlässt, dann versucht euch an Verschlimmerungsfragen. Verschlimmerungsfragen suchen nach Antworten, was euer Gegenüber tun kann, um die für ihn bereits prekäre Situation noch weiter zu verschlimmern. Ein Teammitglied kommt zu euch und beschwert sich zum wiederholten Mal darüber, dass einer der Kollegen zu langsam ist. Mögliche Verschlimmerungsfragen wären: “Was kannst du tun, damit er/sie noch langsamer wird?”, ODER “Angenommen, wir würden einen Kurs über Langsamkeit bei ihm/ihr besuchen, was könnten wir dort lernen?”
Sprachliche Musterunterbrechungen stehen nie für sich alleine und sind ebenso wenig Patentrezepte, die eine Veränderung auf Knopfdruck erzielen. Sie dienen als unterstützendes Hilfsmittel, um routinierte, verkrustete oder eingespielte Denkrhythmen zu verlassen und ein anders Denken überhaupt zu mobilisieren und als Alternative anzunehmen. Es ist zu empfehlen, sie nicht inflationär einzusetzen, sondern mit Bedacht. Wenn ihr sie aber zum Einsatz bringt, dann tut es konsequent und mit Nachdruck, also glaubhaft. Nur dann könnt ihr damit rechnen, dass sie wirken.
- Das Haar in der Suppe oder was ScrumMaster gegen negative Denkmuster tun können
- Scrum – Eine Revolution (3)
- Bitte geben Sie Ihr Ziel ein! Tipps für das Transition Team
A new ScrumMaster wanted to know what to do with a 20 point story that wasn’t complete at the end of an iteration. I explained to her that the story and its points move to the next iteration, but she wasn’t happy with the approach. She wanted to divide the 20 points between the current and next iteration. It was the only story in her iteration and she didn’t want to end up with an iteration with zero points.
“I’m having a hard time getting past this. Are you saying I have nothing to show for this iteration?”
What a telling phrase: “nothing to show for it”. Let’s dig a little deeper into that question: What does she want to show? How does she want to show it? Who does she want to show it to?
Of course, what she was trying to say was, “I want proof that the team did work this iteration.” She’s having trouble getting past the fact that we’re not measuring output, we’re measuring outcome. That means we don’t measure the hours we worked, we measure the value we delivered. Every practice and ceremony supports this paradigm. Check it out:
- What do you want to show? Completed features, not completed tasks. If you want to end the focus on time tracking, you have to stop talking about effort and start talking about features. Either you did or didn’t deliver a feature. Whether you spent 80 hours or 8 is irrelevant.
- Where do you want to show it? At the iteration review, not on the project status report. The iteration review is your opportunity to show the value you provide, literally. You should rehearse and polish your demonstration before inviting everyone to see what you’ve made – it’s your opportunity to impress your organization. If you do that, your stakeholder meetings become a matter of formality.
- Who do you want to show it to? Product stakeholders, not your boss. You should be more worried about whether or not you’ve delivered value than if your boss knows that you’re actually working. In fact, if you’re working but not delivering delivering value, you must be pretty ineffective. You don’t want to show that to your boss. If you’re delivering value, obviously you’re working. Who needs a timesheet to prove that?
This is a difficult leap for organizations to make. It’s second-nature to assume that hours worked equals productivity. The organization won’t change until the conversation changes. So stop talking about hours worked. Stop talking about maxed-out resources. Start talking about value delivered. If you keep talking the language of features and business value, eventually those around you will to. If everyone around you is talking about value, your organization has made the shift.
If you’ve found ways to change the conversation, I’d love to hear it. Hit me up on Twitter at @johnkrewson.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
It’s excruciatingly boring to write specifications. It seems like it’s the most boring thing in the world that a product owner has to do. This could be the reason why most specifications are horrible and come across as the root cause of delays, reworks, and bugs.
This problem can be partly alleviated if a product owner is always available to talk to, but even that is not a cure-it-all remedy.
The agile movement has its peculiar point of view on specifications. The most extreme part of agilists express their feelings quite clearly:
F%$k the specifications!
I know this is going to sound weird, but I have an affinity for the boards we use in Agile Software Development (or Agile Project Management). I’m using the generic term board, but you may refer to them as Storyboards, Taskboards, Testing boards, kanban boards, or simply job boards.
If I get into the way-back machine; back to when I first started my career. I was in Valdosta, Georgia working my first job out of college, Trus Joist MacMillan, and I was being walked around the manufacturing facility. It was in awe and deep appreciation for what I was learning. As I went through the customer service area, I noticed a large magnetic board and on it were these color coded cards with lines that represented stages and dates running across the top. I inquisitively asked, “what is that?” They quickly and proudly gave me the run down that these things all represented our customer’s requests for goods (a.k.a. orders). The columns represented stages of the manufacturing cycle and the lanes represented weeks. This board was the central information hub for the plant — the board described everything going on from department-to-department. It gave the all plant team members indicators as to how busy they, what’s coming up for the next week, and which customer orders were being held up. The other thing I noticed is that as you went throughout the facility, other departments had similar boards that were a reflection of the main board but for the specific customer requests they were working and the boards reflected each departments workflow.Does this sound familiar?
If it doesn’t, then you are probably not working in an agile world, or living under a rock, or you are using agile by you are missing out on something great. Me and my colleagues talk about metrics a lot – with our customers and internally. Well, in case you didn’t notice, the boards themselves are living breathing metrics. The boards are the team’s communications central as well as a key way to see collectively “how are we doing?”
In fact, the boards often ask just as many questions that they answer. These questions can vary based on your role and whether or not you are an embedded team member using the board or a bystander looking to gain insights from the board. I took on the the challenge of looking at questions asked and answered by the boards and found 40, yes 40 — check them out on this mind map. I’m sure there are more; however, I figured 40 was a good start and stop.
Besides all the questions boards ask and answer, I also love boards for their ability to simplify the portrayal of real-time information while being able to have complex information tucked away in the details. Teams can easily innovate and adapt their boards with the use of colors, pictures, lines, layouts, materials, etc.
Finally, I love boards because they actually build the teams. They provide a place to recognize accomplishments, and they are the place to stand around and talk about what is happening on the project. If you are using an electronic board, you can still gain these valuable intangibles by keeping the board up-to-date and driving all collaborations on what is happening on the boards. Boards give teams focus, while also given them information that empowers them to make decisions to get things done and meet commitments.
Please share your thoughts on why you like, love, or hate the boards your teams use. Share some examples.
Here are some example boards that VersionOne provides:
We were discussing what process steps we should define to meet CMMI something something... and the list on the board look like:
- Sprint planning
- backlog grooming
- release planning
- project planning
- risk mitigation planning
I believe that planning is way less important that the activity of reflection (learning). I could refer you to some wonderful quotes by US Army Generals about the uselessness of plans. But let me skip that meme and jump to the assertion that Retrospectives are more important that planning activities.
Because with just that one practice, Retrospectives, a team that was doing no planning could derive a practice of planning using the practice of reflection and adaptions (learning). Therefore Retrospectives trump Planning every time.
I find it interesting that we were focused on the secondary practice. Does CMMI have a learning practice defined?
Je öfter ich agile Implementationen begleite, desto deutlicher wird für mich: Es geht nicht um Scrum. Oder anders gesagt: Das Reden über Scrum lenkt die Aufmerksamkeit von den eigentlichen Themen ab.
In meinem ersten Job war ich ScrumMaster eines neu geformten Scrum-Teams. Ich weiß noch genau, wie viel Zeit ich damals darauf verwandt habe, von Anfang an alles richtig zu machen. Vom Storywriting über das Schätzen bis hin zum Commitment – mein Team hinterfragte beinahe alles – und ich setzte meine gesamte Energie ein, um ihnen zu erklären, warum man das “mit Scrum” nun so machen muss. Auf diese Weise haben wir es geschafft, die ersten Sprints über nichts anderes als Scrum zu diskutieren. Gibt es eine bessere Form, unproduktiv zu sein?
Viele behaupten immer noch, Scrum sei eine Methode oder ein Prozess. Typischerweise geht damit die Forderung einher, man müsse, gerade am Anfang, Scrum “by the book” machen, um erfolgreich zu sein. Zugegeben: Das Befolgen von eng gesteckten Regeln schafft Sicherheit, indem es unerfahrenen Teams einen Rahmen gibt. So diskutieren wir nicht lange, ob fünfzehn Minuten Daily oder eine Sprint-Retrospektive Sinn machen - wir tun es einfach.
Problematisch wird dieser Ansatz dann, wenn Scrum zum Zweck an sich verkehrt und dadurch zum unhinterfragbaren Dogma erhoben wird. Kritik des Teams wird dann mit der Begründung abgeschmettert, Scrum erlaube das nicht. Was dann passiert, ist leicht auszumalen: Das Team beginnt, Scrum in Frage zu stellen und es als Grund ihrer Unzufriedenheit zu betrachten.
Anstatt mit Scrum wie mit einem roten Tuch vor den Augen unserer Teams hin und her zu wedeln, sollten wir uns viel intensiver mit ihren Problemen auseinander setzen. Woran krankt die Produktentwicklung gerade? Was kann mein Team schon richtig gut? Und wo braucht es jetzt Hilfe? Wenn wir bei solchen Fragen starten, werden wir Scrum einsetzen können, ohne wirklich über Scrum reden zu müssen.
Ich habe kürzlich mit meinem neuen Team ein Backlog Grooming durchgeführt, ohne davon zu erzählen. Es hat einfach gerade gepasst. Mein Team wollte die nächsten Schritte besprechen und wäre – ganz klassisch – eine Excel-Tabelle mit dem Projektleiter durchgegangen. Im Backlog Grooming geht es darum, das Product Backlog so zu überarbeiten und zu pflegen, dass es aussagekräftig und handlungsweisend bleibt. Doch anstatt das zu erklären, habe ich die Teammitglieder gebeten, die aktuellen Themen auf einem Flipchart in ihren eigenen Worten zu formulieren, sie dann gemeinsam zu besprechen und schließlich zu priorisieren.
Meine Hypothese: Wenn es uns gelingt, Scrum besser mit dem Bedarf der Teams zu verknüpfen, dann erschließt sich der Sinn der Artefakte, Meetings und Rolle von selbst. Scrum wird dann nicht mehr als vorgeschriebener Overhead, sondern als Stärkung, als passendes Mittel zur passenden Zeit wahrgenommen. Wenn uns das gelingt, dann können Teams Scrum dafür nutzen, wofür es eigentlich gedacht ist: Als Rahmenwerk, mit dessen Hilfe Ballast abgeworfen und die regelmäßige Weiterentwicklung von Produkten endlich in Mittelpunkt allen Tuns steht.
Ein Tipp zum Schluss: Skizziere auf einem Blatt Papier, wo dein Team gerade steht und welches eine Ziel du mit deinem Team nächste Woche erreichen möchtest. Achtung: Deine Ziele dürfen nicht astronomisch sein, sondern müssen den Möglichkeiten deines Systems entsprechen. Ich kann 100 Meter in 11 Sekunden laufen – 10 Sekunden sind für mich außer Reichweite. Unter dem Stichwort SMART verbergen sich fünf Eigenschaften guter Ziele: Spezifisch, messbar, erreichbar, relevant, zeitlich terminiert.
Wie sieht dein Ziel aus? Vielleicht geht es um eine bessere Einbindung von Teammitgliedern, vielleicht geht es um mehr Zuverlässigkeit in der Lieferung oder um mehr Qualitätsbewusstsein. Egal, was es ist: Überlege dir dann in einem zweiten Schritt, wie du dieses Ziel gemeinsam mit deinem Team erreichen kannst, ohne ein Wort über Scrum zu verlieren. Überlege dir nach Bedarf auch ein Alternativszenario, einen Plan B: Was mache ich, falls mein ursprünglicher Plan nicht funktioniert?
Lass Scrum ruhig im Hintergrund, als Prinzip, vom dem du überzeugt bist, wirken. Nutze Scrum, um dir bei deinen Entscheidungen zu helfen. Ziehe die Inspiration für dein Tun aus Scrum. Aber belästige dein Team nicht damit. Es hat vermutlich andere Sorgen. Setz dich statt dessen mit deinem Team zusammen, sag ihnen offen und ehrlich, wo genau du momentan Handlungsbedarf siehst, was du mit ihnen erreichen möchtest, und arbeiten dann mit ihnen, so lange es nötig ist, an der Erreichung des Ziels. Du wirst dich wundern, wie schnell das Arbeiten nach Scrum zu einer Banalität wird, die keiner mehr hinterfragt.