When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.
The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working tested increment of the product… and therefore what defines the basic requirements for a Scrum team.
When you put analysts, designers, developers, and testers into a single workgroup, let them work across skill-set boundaries, self-organize to balance load, and have them collectively produce a working tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.
Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness, you have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.
Why Scrum Breaks?
The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.
When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.
It’s my assertion that these planning dependencies are what results in teams going through the motions of Scrum without realizing value Scrum promises. Last week I did a talk at Agile2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.
That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.
The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.
SAFe and Value Streams
I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise level scale. Scaling Scrum is the topic de jour.
Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean has written since he released Scaling Software Agility, have a ton of respect for his work, and agree with the basic patterns he has introduced.
This conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.
At LeadingAgile, we typically coach an explicit value stream in the middle level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.
It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier, it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.
Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.
SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.
We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.
We believe this concept is methodology independent and will make any methodology you choose better in the long run.
Why SAFe Breaks?
Scrum isn’t trying to break dependencies within the team, it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working tested increment every couple of weeks.
SAFe isn’t trying to break dependencies either within these larger value streams either, it is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work and stabilize throughput, while producing a working tested increment every PI.
There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?
If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.
If SAFe is going to ultimately struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about SAFe’s of SAFe’s or SAFe Product Owner Teams or SAFe Portfolio Solutions Teams?
I suspect we might. I think we might also be seeing evidence of this already.
Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already given how well SAFe is doing in market.
If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon and are people talking about this?
Ken and Jeff Got it Right
Back in 2006 Ken Schwaber put up a slide where he illustrated a team of teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely-coupled teams (and at that time, that was NOT my reality).
A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that ‘teams were never expected to self-organize across class boundaries’. They were implicitly saying that encapsulation was the expectation for a Scrum team to form.
Jeff Sutherland, as we speak over at Scrum.com is talking about Object Oriented Design in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.
I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum now-a-days don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.
When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put in place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago but that is seldom implemented.
I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum,
SAFe Is A Compromise
I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.
That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.
At this point in the evolution of my thinking, I find myself in a place where I don’t believe the Scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.
We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.
Refactoring Your Enterprise
The only real, long term sustainable approach to Scaled Enterprise Agile is to take the long hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.
The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peace harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery, and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.
With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future states starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like that help us get there, while still running our businesses effectively.
If I think about it… that was really what my talk last week was about. The talk is up on the blog, and it was recorded by the conference, but that might take a few weeks to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend ;-)
The post Encapsulating Value Streams and the Object Oriented Enterprise appeared first on LeadingAgile.
Leadership is well defined - that's not the problem - the problem is it has many, many various definitions. Leadership definitions change throughout time. Your grandfather's definition of leadership may vary quite drastically from your's - ask him if you have the opportunity.
A modern classic definition:
Leadership is a process whereby an individual influences a group of individuals to achieve a common goal. -- Peter Northouse
A brief history of Leadership
A working definition of leadership
Is leadership a process
May leadership emerge from a group
Is leadership more than a form of coercion and power
Various Leadership Approaches
Situational, Skills, Style, Trait
Leader-Member Exchange Theory
Transformational Leadership Model
Servant Leadership Model
Authentic Leadership Model
Team Leadership Model
Disclaimer: as this blog is a from of note keeping for me - an extension of my cognitive model of the universe of knowledge - this article and the series of article may be in great flux until complete (or good enough to quit editing).
1) Leadership Theory and Practice - 6th Ed. by Peter Northouse.
This is an initial draft for brief guide to how I use the Kanban Canvas, building on the recently posted Prezi. It will eventually be added to the main Kanban Thinking site. Generally, I use the canvas as the core of a two day workshop, during which I use it to facilitate the collaborative co-creation of a kanban system. The canvas becomes a single, simple artefact which captures a common understanding of how a system is designed, and why it is designed the way it is.System
1. First we begin with understanding the scope and purpose of the System. I’m looking to discover key people, problems, frustrations, boundaries and interfaces. I like to get participants to tell their story leading up to the present day, explaining why they are in a room together designing a kanban system.
The output in this section is one or more a simple narratives capturing the essential system elements and interactions.Impact
Next, we need to be able to assess whether any changes we make are improving or deteriorating the systems fitness for purpose. The goal is to be able to describe the general direction we want to go in, without identifying any specific outcomes or end states.
2. We explore various ways we might want the story to end – and what endings might we want to avoid. I ask participants to imagine impossibly good and bad endings – utopian and dystopian futures – using the three Impacts of Flow, Value and Potential to help them look from different perspectives. They are not distinct impacts, but more like triads, where elements of all three could be involved. This generates healthy conversations about how the potential futures relate to the different impacts.
The output across these three sections is a set up potential endings, placed relative to where they have most resonance. Colour coding is used to distinguish between the utopian (green) and dystopian (red) futures.Interventions
Now we have a good understanding of the recent past and desired future direction, we can begin looking at how we can start interacting with the system to make interventions which we hope will have a positive impact.
3. To really understand how we can make effective change, we first need to Study the context. There are 3 areas that I find it useful to study; the customer or stakeholder, the work demand that comes from them, and the way that demand is processed. We usually start by looking at demand, and the group applies concepts such as value and failure demand, the CORE Profile and Classes of Service. Then we’ll explore where that work comes from with a technique such as Empathy Mapping, and how that work is processed with a variation of Value Stream Mapping focussing on the flow of information and its discovery.
The output in this section is a set of sticky notes capturing a summary of customer/stakeholder needs, demand classifications and classes of service, and primary workflow states, transitions or delays.
4. Once we have a good common understanding of the existing context, then we can Share it by visualising our knowledge on a kanban board. First I ask the group to discuss and agree which information is most relevant and important for them to share – trying to show everything will just create noise. Then I introduce the Token, Inscription, Placement concept as a way of thinking about board design patterns, and the group comes up with approaches to visualise their important information.
The output in this section is a set of mappings between each important informational dimension to be visualised, and the visualisation technique to be used.
5. The next step is to begin to Stabilise the current system by introducing explicit policies. These policies will form flexible boundaries to contain the work. Boundaries which are too hard and fixed will lead to rigid bureaucracy, while boundaries which are too loose will lead to chaos. I introduce Work In Process limits as a core policy type, and we explore the various strategies and techniques for introducing and setting WIP limits. Then the group brainstorms some simple quality checklists to agree how and when work should progress across the board. These simple, standard work definitions become the baseline for future improvements.
The output in this section is a set of decisions regarding basic WIP limit strategies and allocations, and bullet points for initial entry/exit criteria on the board.
6. As a system is put in place and evolves, we need a way to Sense its capability in order to assess its fitness for purpose. The two primary means for this are measures and meetings. First, groups decide which outcomes they hope will have a positive impact, typically selecting from productivity, reliability, responsiveness, quality, customer satisfaction and employee engagement. Metrics are discussed and defined for these outcomes, considering the anticipated behaviour and consequences, and potential tradeoffs with other outcomes. Then groups decide what meetings and cadences they would like to use to give them an ongoing rhythm for assessing capability and progress.
The output in this section is a set of simple metrics definitions, and a list of meetings and respective cadences.
7. Finally, the evolutionary potential of the system is explored by beginning a Search for alternative designs. Given everything that has been discussed so far, the groups begins to define small experiments that could be run on possible changes. Each experiment has a hypothesis, a rationale, measures to both validate and falsify, and a mechanism for ensuring safety and reversibility.
The output in this section is a set of initial simple experiment definitions which can be run.
All of this is done in a very collaborative way, using various facilitation techniques to ensure everyone is able to contribute, different opinions are heard, and consensus is reached. At this point, the group is able to begin learning, evolving and improving their kanban system using the canvas as a basis.
Are your management practices long in the tooth?
I think I was lucky that early on, I worked in environments that shook things up and rattled the cage in pursuit of more customer impact, employee engagement, and better organizational performance.
In one of the environments, a manufacturing plant, the management team flipped the typical pyramid of the management hierarchy upside down to reflect that the management team is there to empower and support the production line.
And when I was on the Microsoft patterns & practices team, we had an interesting mix of venture capitalist type management coupled with some early grandmasters of the Agile movement. More than just Agile teams, we had an Agile management culture that encouraged a customer-connected approach to product development, complete with self-organizing, multi-disciplinary teams, empowered people, a focus on execution excellence, and a fierce focus on being a rapid learning machine.
We thrived on change.
We also had a relentless focus on innovation. Not just in our product, but in our process. If we didn’t innovate in our process, then we got pushed out of market by becoming too slow, too expensive, or by lacking the quality experience that customers have come to expect.
But not everybody knows what a great environment for helping people thrive and do great things for the world, looks like.
While a lot of people in software or in manufacturing have gotten a taste of Agile and Lean practices, there are many more businesses that don’t know what a modern learning machine of people and processes that operate at a higher-level looks like.
Many, many businesses and people are still operating and looking at the world through the lens of old world management principles.
In the book The Future of Management, Gary Hamel walks through the principles upon which modern management is based.The Principles of Modern Management
Hamel gives us a nice way to frame looking at the modern management principles, by looking at their application, and their intended goal.
Most people aren’t aware of the principles behind the management beliefs that they practice or preach. But before coming up with new ones, it helps to know what current management thinking is rooted in.
“Have you ever asked yourself, what are the deepest principles upon which your management beliefs are based? Probably not. Few executives, in my experience, have given much thought to the foundational principles that underlie their views on how to organize and manage. In that sense, they are as unaware of their management DNA as they are of their biological DNA. So before we set off in search of new management principles, we need to take a moment to understand the principles that comprise our current management genome, and how those tenets may limit organizational performance.”A Small Nucleus of Core Principles
It really comes down to a handful of core principles. These principles serve as the backbone for much of today’s management philosophy.
“These practices and processes of modern management have been built around a small nucleus of core principles: standardization, specialization, hierarchy, alignment, planning, and control, and the use of extrinsic rewards to shape human behavior.”How To Maximize Operational Efficiency and Reliability in Large-Scale Organizations
It’s not by chance that the early management thinkers came to the same conclusions. They were working on the same problems in a similar context. Of course, the challenge now is that the context has changed, and the early management principles are often like fish out of water.
“These principles were elucidated early in the 20th century by a small band of pioneering management thinkers -- individuals like Henri Fayol, Lyndall Urwick, Luther Gullick, and Max Weber. While each of these theorists had a slightly different take on the philosophical foundations of modern management, they all agreed on the principles just enumerated. This concordance is hardly surprising, since they were all focusing on the same problem: how to maximize operational efficiency and reliability in large-scale organizations. Nearly 100 years on, this is still the only problem that modern management is fully competent to address.”
If your management philosophy and guiding principles are nothing more than a set of hand me downs from previous generations, it might be time for a re-think.You Might Also Like
I grew up in the Pacific NW just south of Seattle in Tacoma, WA. One of my favorite cartoonists, Gary Larson, is from Tacoma. His cartoon The Far Side was a never-ending source of entertainment for me and later, my two boys. One cartoon that we all never seemed to tire of, answered the age-old question: “Where do boneless chickens come from?” It also led to the follow-on question of “What do boneless chickens do all day?” (Answer: Lay around wondering how they can cross the road to prove to the Possum that it can be done!).
Why is this important? How does this relate to agile? Even if we ignore for a moment the Scrum-concept of “pigs” and “chickens”; quite a lot actually.
Many companies see “agile” as a silver-bullet that can magically transform their “everyone’s busy but we’re unable to make-and-meet commitments; and when we do, its typically late and of poorer quality than we care to admit!” circumstances. Often times they think that knowledge is the answer and that simply attending agile training will be the key to their future success. Many even instantiate an “agile pilot” somewhere within their organization with their recent agile training attendees. The company decouples the pilot from all current process and “administrivia” that puts a drag on other company efforts to ensure the pilot’s success. It works!! Unfortunately, when they try to implement agile within the rest of the organization “agile” fails for them! Just like the boneless chickens in the cartoon … all knowledge and muscle without the bone structure support necessary to move successfully.
Therefore, at LeadingAgile we (highly) encourage organizations to lead with Structure, Governance and Metrics first, THEN train.
We’ve found that there are two basic areas that companies must address to be successful in applying agile at scale:
a) Willingness to establish and maintain dedicated teams; and
b) Flowing work in the form of User Stories that is ready to be pulled/delivered successfully within a sprint by Delivery Team(s).
Structure is about putting in place dedicated teams at the both the Portfolio and Program levels as well as Delivery/Service Team level. Structure in this instance is NOT about re-drawing Org Charts! It is about choosing to bring work to (teams of) people as opposed to bringing people to the work (aka “projects” / managing utilization).
Establishing dedicated team structure demonstrates the organization’s acknowledgement of and commitment to successfully connect corporate strategy/vision to execution in an agile fashion. Governance, in this paradigm, is then how each of these team’s (at each level) “work with each other”. Governance and structure together enable the organization to identify, prioritize and progressively elaborate potential work while limiting overall Work in Process (WIP). They are essential to managing risks/dependencies proactively. Putting structure and governance in place first forces conversations around dependencies (coupling) that, if ignored, put at risk the Delivery team(s) ability to successfully meet commitments. The cadence throughout this agile structure is adjusted to the proven velocity or organization’s capacity to deliver working/tested code that is ready (potentially) be deployed. Finally, Metrics enable the organization to both tie value delivered back to the overall strategy/vision as well as enable business leadership to see the agile transformation’s progress.
Structure, governance and metrics support the organization’s ability to empirically adjust as conditions dictate. They are the critical “bones” that both agile training and coaching hang from as the organization begins its agile walk. Without structure, governance and metrics already in-place the organization doesn’t have the internal support it needs to absorb and respond to the challenges and impediments that always arise when implementing change.
So go on! Ensure your agile chickens aren’t “boneless”! Your agile “pigs” will thank you!
Photo Courtesy of The Far Side © Gary Larson
Ja, es gibt sie, die Scaled Agile Frameworks - also die Modelle, Blaupausen und Ideen, wie man mit Scrum und Kanban ganze Organisationen agilisiert. Ich selbst habe die ersten Ergebnisse dazu auf Konferenzen erzählt und u.a. 2005 in einer verteilten Organisation das Konzept der Chief Product Owner, Chief ScrumMaster, der Product Owner Teams, des Company Backlogs vielleicht nicht als Erster, aber doch zeitgleich mit den damals gerade ablaufenden Entwicklungen in den USA ausgearbeitet. Doch das waren immer Schablonen. Ich bin nie davon ausgegangen, dass man in einer großen Organisation einfach ein Schema F einführen kann und schon ist man fertig. Wäre das so, hätte ich nicht das Buch “Das Scrum-Prinzip” geschrieben, in dem ich zeige, dass jede große Veränderung nur entlang der Widerstände in einer Organisation geschehen kann.
Doch heute wollen viele noch stärker als vor einigen Jahren den Quick-Fix. Es soll von oben Agilität ausgerollt werden. Damit tut man der Organisation und den Menschen in der Organisation Gewalt an. Versuchen wir doch mal, die Blaupausen nur als das zu sehen, was sie sein können: Wegweiser. Wie wäre es, neben diesen Wegweisern noch ein paar Prinzipien einzuführen, die wie von selbst zur Agilität führen? Prinzipien, die zwar nicht auf die Schnelle, aber sicher aus einer Organisation eine agile Organisation machen?Wer Agilität will, muss führen
Zunächst: Wer Agilität einführen will, muss führen. Also eine Vision ausgeben, sich selbst dabei im Klaren sein, warum man das will, und dann voller Begeisterung selbst loslaufen – ohne zu schauen, ob noch jemand mitkommt. Diese Lektion habe ich von meinem Pferd Rubiano gelernt. Wenn ich mich umdrehe, schauen will, ob er mitkommt, bleibt er stehen. Was logisch ist, denn ich sage ihm ja: “Bleib stehen.”
Genauso ist es mit der eigenen Organisation: Wer losläuft, der muss sich sicher sein, dass die anderen mitkommen werden. Und wie ist man sich dessen sicher? Es gibt ein simples Prinzip, auch das hat mir mein Pferd beigebracht: Ein Pferd läuft immer freiwillig mit. Probiert es aus! Versucht doch mal ein Pferd aufzuhalten, dass beschlossen hat, in eine andere Richtung zu gehen als ihr. 500 kg bewegte Masse hält man nicht so einfach auf. Jedenfalls nicht mit einem Führstrick.
Genau das Gleiche – und das meine ich wirklich so – erlebe ich in allen Organisationen, mit denen wir arbeiten, und ich erlebe es in meinem eigenen kleinen Unternehmen. Kollegen gehen mit, wenn sie wollen. Wenn sie sich selbst in die Richtung bewegen wollen, in die ich führe. Und ja – ich führe. Meine Kunden, meine Coachees und meine Kollegen. Jeder Facilitator mag das bestreiten, aber sogar er oder sie führt – immer. Denn der, der den Überblick behält und den Kontext steuert, der führt. Aber der entscheidende Aspekt ist: Zu diesem Prinzip der Führung gehört Freiwilligkeit. Sich dessen wieder klar zu werden ist der erste Schritt zu jeder gelungenen Veränderung hin zu einer agilen Organisation.
Das ist nicht einfach. Ich kann euch dazu nur empfehlen, “Turn the Ship Around” von L. David Marquet zu lesen. In diesem wundervollen Buch sagt Marquet immer wieder, dass es ihm schwer fällt, seine eigenen Überzeugungen zu leben, denn sie liegen quer zu all dem, was wir in der Arbeitswelt der letzten Jahrzehnte gelernt haben. Rückfälle sind also vorprogramiert – na und. Zur agilen Organisation gibt es keinen Weg ohne Sackgassen und Umwege. Wichtig ist das Loslaufen, das Ziel vielleicht vor Augen.
- Mit Kanban kann man alles machen – auch vieles falsch
- Führung ist?
- Entschuldigen Sie bitte, wie lösen Sie Ihre Probleme?
“Forget your perfect offering. There is a crack, a crack in everything. That’s how the light gets in.”
How’s that for a weird quote? I heard it the other day on the radio and it stuck in my head. It has a resonance for me that I just can’t seem to shake. You see, like most folks, I’m intimately familiar with imperfection. I’m faced with it in many of the projects I’m most passionate about: My writing, my career, my boat…
Yeah, I’m building a boat. Technically, it’s my second boat. I think just admitting that qualifies one as insane. The first boat was a mere 9 foot skiff I made for my daughters. It took me almost 3 years to complete it. I should probably mention that I have absolutely no woodworking skills. So after I finished the first one, I decided to build another. This second boat is just for me. Well, me and my brother actually. We’re building it together in his garage. We’re about a year into it so far and it’s coming along pretty well.
OK, honestly it’s a little early to tell. We make a lot of mistakes.
I don’t know what it is about working with wood, but any mistakes you make tend to jump right out at you. Of course, the bigger the project the more room there seems to be for error. I’m discovering that a 17 foot boat leaves lots of room for error. Cutting parts to shape is hard. Getting screws to bite and not strip. Glue everywhere. One false move with a power tool and there are splinters galore. The whole project really is just a glorious catastrophe waiting to happen.
If ever there were a case study in failure, this boat is it for me. Now that might sound terribly defeatist, but it’s not meant to. You see, I’ll finish this boat too, one way or another. It’s just that I’ve got a whole lot of failing to do in between now and the day I finally launch her.
Of course, given all this failing, it’s still pretty astonishing how slowly I manage to learn. For instance, I’m noticing that I don’t seem to give up my standard ways of learning, even in the face of overwhelming evidence that they are not paying dividends. I’m fairly sure I’m not alone in this behavior.
First there is my innate impatience to see quick results. This whole measure twice, cut once thing just doesn’t seem to come naturally. For some reason I’m always in a rush. I find it extraordinarily difficult to slow down and just take my time. Maybe it’s some american thing where we are just impatient with anything that impedes progress…No, I don’t buy that either. I think slowing down is really hard work. It takes discipline to slow down and treat things in a very thoughtful and conscientious manner.
Savoring the moment and appreciating how things feel in the moment is not something that just happens to you. You have to make time for it. I can show you all of the places on the boat where I rushed the job. The places where I tried to drive the screws in with a power drill (I drove them right through the panels – genius!). The areas where the wood split because I didn’t take the time to test the bend first. The evidence of my own impatience is writ large in the construction of this boat.
Do you want to know the really amazing part? I still keep rushing!
Scary. Did I mention that slowing down is hard?
Another area where I struggle to learn: working as a team. Working as a team is hard too. First you have to keep those you are working with in mind all the time. That doesn’t come naturally at all for me. I’ve never really been a good team player. I grew up participating in individual sports like running, wrestling and weightlifting. I operate very well solo. Working as a team has been an alien experience. For example, when my brother and I are working on the boat, I often struggle to figure out what he can do to help. I’ve seen this on software development teams too. Ask a developer what needs to be done, and you will get a detailed list of all of the work that remains. No problem. Ask that same developer how someone else can help them get that work done, and often you will get a blank look. When you are not accustomed to working on a team, it’s hard to picture what teamwork looks like.
To make matters worse, my brother and I have different skill levels when it comes to woodworking. This means that sometimes I need to take the time to show my brother how to do things (or vice versa). I find that hard to do when I’m rushing to get things done (see above). But without taking that time to show him how to do things, I lose the benefit of his help. I lose the teamwork. I’m finding that teamwork takes some serious patience. Ultimately I know I will go faster if both my brother and I can work at the same level, but that means initially I will have to slow down to achieve that goal. Slowing down to go faster.
I’m very lucky to have someone to like my brother to put up with all my mistakes. In a peculiar way, building a boat with him is teaching me a lot about software development. That’s probably good, because God knows if we’re ever going to finish that boat.
Filed under: Agile, practice, Teams Tagged: Agile, boat, brother, failure, improvement, Mistakes, sailing
1. Write a test, it fails (no code to test yet) (Red)
2. Write just enough code to make the test pass (Green)
3. Refactor the code (AND the test code), keeping the test passing
3A. (This is where any simple logic would be written)
When satisfied, start over with a new test.
I find that step 3A is where we lose a lot of folks. Simple logic pretty much includes a calculation or deterministic algorithm. If there is any kind of branch statement - IF, SWITCH, etc. these should all be coded only as a result of new tests.
If we stay with this approach, we will have valuable information about the state of our code and a mechanism to make sure the code actually does what we wanted it to do.
I subscribe to a newsletter from Projects at Work which I rarely read. I happened to open it this month and stumbled upon a gem. 5 Ways to Improve Time Tracking It prompted this post… 5 Reasons to Kill Time Sheets I have a strong dislike to time tracking, especially on software projects and here […]
I sent a Pragmatic Manager email last week, How to Avoid Three Big Estimation Traps. If you subscribed, you’d have seen it already. (That was a not-so-subtle hint to subscribe :-)
If you’re not sure of the value of being on yet-another-email list, browse the back issues. You can see I’m consistent. Not about the day I send the Pragmatic Manager email. I can’t make myself be that consistent. I provide you some great content. I tell you where I’m speaking. I let you know where you can read my writing, and how to find more of my work. That’s it.
In any case, take a look at How to Avoid Three Big Estimation Traps. I bet you’ll like it!
From the excellent Ron Jeffries, we have “Refactoring – Not on the Backlog!“Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Recently I’ve been challenged by the question, “Can you change culture?” I think this is pretty common for folks who work in large organizations. The question of culture and how it blocks or allows us to get things done is a thorny one. There seem to be two opposing schools of thought in the agile community on the subject of culture:
- You can’t change culture, you can only adapt to it (customize your process to fit)
- You can change culture (through influence, good looks, and the right practices)
Of course, perhaps the first question is, “What is this culture thing anyway?” Most definitions of culture are terribly vague and in my opinion not especially useful (although, couched in the delightfully hand-wavy terms of corporate sociology, they usually sound very smart). Just for giggles, here are some definitions:
- Culture is the accepted norms of behavior for a group
- Culture is the collection of social contracts that a group depends on
- Culture is how we treat each other
- Culture = people
I forget where I saw that last definition (Tobias Mayer?), but it’s probably my favorite of the bunch. You see often culture is used in conversation to hide or excuse problems with people. It’s kind of like referring to employees as “resources” (Ooh! Now I can be that irritating agile guy who corrects people’s terminology! A word to the wise: Don’t be that guy). So where was I? Oh yeah, culture. So here’s the deal, I don’t like the term culture because it’s just too damn vague. Often times I get a lot more clarity if I use more specific terms to describe the problem. For example:
- Our culture won’t permit us to do that = Manager X won’t permit us to do that
- Our culture only supports hierarchical decision making = Bob likes to make all the decisions
Once I take the time to replace culture with more specific terms (Who, What, Where, When, Why), I usually find that the problem feels more manageable to me. More human and less onerous. On the one hand, “Our culture” is vague and hard to put strategy around. On the other, influencing Manager X is a simple exercise in winning friends and influencing people. That’s something I know how to do. People I can work with. Culture…not so much.
So if you accept this definition of culture (culture = people), then your ability to change the culture directly depends on your ability to influence people. That’s Dale Carnegie stuff. It’s not easy, but it can be done – one person at a time. When you are in a small company, that’s not too daunting a challenge – win a handful of people over and you are done. However, in a large company, it’s quite a different matter. In a large company you have to win over hundreds or even (heaven forbid) thousands. That’s a very different challenge – and it’s an order of manure…uh…magnitude more difficult. It can be done, but it’s a long term challenge that may take years – and while some strategies you will use with larger groups are the same as for small groups, often they can be very different. If you are accustomed to trying to change the culture in small companies, you almost have to learn a completely new language in order to try and change the culture at large companies.
But seriously, can you REALLY change culture in big companies? One way to answer this question is to look for examples of successful culture change within large corporations. There are one or two that I can think of:
- Richard Semler, SEMCO (As described in the book, “Maverick”)
- James Collins, “Good to Great” (A series of stories of dramatic corporate change)
If you accept these stories as true, then the answer must be that culture change can indeed happen. But perhaps you are an inveterate cynic (like me) and don’t believe everything you read in books. Maybe culture change is just something that people with extraordinary power can achieve (like CEOs). Then what hope do those of us who exist much lower down in the corporate hierarchy have? Two thoughts:
- Sometimes we have to accept that our sphere of influence is limited. Those limitations are things that are very real like geography. You may only be able to influence folks that you work with in your particular office (which makes a lot of sense). Influencing the rest of the organization is going to be much harder. This has nothing to do with culture and everything to do with constraints. Start small, gather your wins, and grow.
- You can just wait. Bide your time. Sometimes you have to wait for the right opportunity. How long should you wait? I don’t know. There is an element of patience when dealing with culture change. You need a lot of patience. Focus, prioritize, and be ready. There’s nothing wrong with that approach.
OK Tom, what if I still don’t buy it. My company is HUGE and there is just no way that I can influence these clowns…er…people. No matter what happens, once an organization gets above a certain number (perhaps the Dunbar number) then it becomes extremely difficult to change. So difficult in fact, that it’s just not worth fighting. If that really is the case (and in many cases it just may be), there really are two approaches:
It may be that there are kinds of change that will never be accepted within some organizations. However, usually, that is a relatively small set of invariants. There usually still remains a broad spectrum of change that can be introduced successfully. Just stay away from the hot buttons. Does it really matter that you introduce every single one of the 12 XP practices? Or would it be enough just to introduce a few (there is still some benefit gained). Can you bring change in small amounts rather than a huge batch? There is plenty of room for creativity in this sort of culture change.
In the end, even after all this, you may come to the conclusion that you can’t change the culture in big organizations. Maybe it’s just too hard. Perhaps you just don’t like Dale Carnegie. I don’t know. That may just be the way it is. If that ends up being the case for you, then saddle up Rozinante. Grab Sancho, and go find some more giants to tilt at. The world is full of them.
Filed under: Agile, Coaching Tagged: Agile, change, change management, Coaching, culture, culture change, Dale Carnegie, definition of culture, large organizations, management, Scrum
Lassen Sie mich diese Aussage entschärfen: Zeitdruck in Meetings tut gut, weil es oft um grobe Abstimmung/Synchronisation und nicht um die perfekte Ausarbeitung geht.Vom guten Gefühl schnell viel zu schaffen
In meiner Abschlussarbeit an der Hochschule habe ich zwei unterschiedliche Prototyping-Prozesse verglichen: Der erste Prozess war detaillierter, mit längeren Phasen für eine genaue Ausarbeitung. Der zweite Prozess war geprägt durch extrem straffes Timeboxing, um eine Iterationsschleife unterzubringen.
Erstaunlich war, dass die Teilnehmer der ersten Gruppe in der anschließenden Befragung überwiegend „mehr Zeit im Prozess wäre für mich hilfreich“ ankreuzten und die Teilnehmer, die dem extremen Zeitdruck ausgesetzt waren sich überwiegend für „mehr Zeit im Prozess wäre für mich nicht hilfreich“ entschieden. Das Experiment war in keiner Weise repräsentativ, aber dieses Ergebnis gab mir zu denken. Auch in Scrum Teams resultiert die Zufriedenheit u.a. daraus, dass Meetings schnell und effizient abgehalten werden und viel Zeit bleibt, die eigentliche Arbeit zu erledigen.
Meetings sind teuer, viele gut bezahlte Experten verbringen Zeit zusammen. Es ist offensichtlich, dass schnell Ergebnisse erzielt werden müssen, um diesen Kostenfaktor zu rechtfertigen. Der Scrum Workflow sieht daher Zeitbegrenzungen für alle Meetings vor. Diese Zeitbegrenzungen werden zu Beginn der Meetings kommuniziert, routinierte Teams sind bereits auf das Timeboxing eingestellt. Der Zeitdruck hilft, die Spreu vom Weizen zu trennen, weil die Teilnehmer automatisch ihre Anliegen und periodisieren und die für sie wichtigsten Themen zuerst ansprechen. Aufgabe des Scrum-Masters ist es, zu erspüren, welche Fragen sofort geklärt werden können und welche Abstimmungsprozesse besser in kleinere Zirkel nach dem Meeting verschoben werden sollten.
Ein sehr schönes Werkzeug zum Visualisieren der Restzeit sind TimeTimer. Diese funktionieren wie eine Eieruhr und stellen die verbleibende Zeit mit einer immer kleiner werdenden Farbfläche dar. Die Anschaffung macht sich schnell bezahlt.Smart Timeboxing
Um Zeitdruck mit Flexibilität zu kombinieren, empfiehlt sich das Smart Timeboxing. Hierbei wird zuerst eine Zeitspanne gewählt, die etwas zu kurz erscheint. Nach Ablauf der Zeit fragt der Scrum-Master die Teilnehmer, ob sie in die Verlängerung gehen wollen. Wird dies bejaht, so wird noch einmal die halbe Zeitspanne der Vorrunde gegeben.
Beispiel: Für ein Sprintplanning #2 rechnen wir grob mit einer Stunde pro Sprintwoche, bei 2-wöchigen Sprints können wir also 2 Stunden für dieses Meeting veranschlagen. Mit Smart Timeboxing wählen wir für die erste Zeitrunde dieses Meetings nur die halbe Zeit. In dieser ersten Stunde ist es wahrscheinlich, dass wir bereits 80% der Abstimmung im Team schaffen. Danach wird gefragt, ob es eine zweite Runde geben soll, die dann nur 30 Minuten dauert:
Erste Zeitrunde im Meeting – 1 Std.
Frage danach: „Benötigen wir mehr Zeit?“ – „Ja!“
Zweite Zeitrunde im Meeting – 30 Min. Frage danach: „Benötigen wir mehr Zeit?“ – „Ja!“
Dritte Zeitrunde im Meeting – 15 Min. Frage danach: „Benötigen wir mehr Zeit?“ – „Nein!“
Dieses Sprint Planning mit Smart Timeboxing hat 105 anstelle von 120 Minuten gedauert, und die Teilnehmer haben trotzdem die Zeit bekommen, die sie benötigten. Gewonnen haben wir eine Viertelstunde .Nicht hetzen, aber Zeitdruck tut gut!
Timeboxing hilft uns und anderen, schnell ins Tun zu kommen und es gibt Teams das gute Gefühl, schnell etwas geschafft zu haben. Weiterhin haben wir durch das Smart Timeboxing Sollbruchstellen in unser Meeting eingeführt, holen uns immer wieder das Commitment des Teams, auch die nächste Zeitrunde fokussiert und produktiv zu verbringen. Wir gewinnen genügend Flexibilität, auch schwierige Fragen ausreichend zu diskutieren und Zeit für die Umsetzung der Ergebnisse aus dem Meeting.
Probiert es aus und berichtet uns von euren Erfahrungen!
- ScrumMeetings moderieren oder „ein ScrumMaster hat nichts zu tun“
- Klassiker | Sprint Planning
- Bericht vom Scrum Meeting
Do a Google search on "servant leadership" and you will get plenty of hits (2.5 million for me just then). So if you don't know what it is cruise on over to http://en.wikipedia.org/wiki/Servant_leadership and check out the 21st century "Cliff's Notes" on the topic.
Disclaimer: as this blog is a from of note keeping for me - an extension of my cognitive model of the universe of knowledge - this article and the series of article may be in great flux until complete (or good enough to quit editing).
Greenleaf's enlightenment of Servant Leadership stems from his reading of Hermann Hesse's short novel, Journey to the East. "Hesse's story is an account of a mythical journey by a group of people on a spiritual quest where the recognition of the true leader of the group takes place as a result of his acts of service and self-sacrifice for the benefit of the whole group. As Spears tells it, upon reading this story, it seemed suddenly clear to Greenleaf that a 'great leader is first experienced as a servant to others, and this simple fact is central to his or her greatness ... true leadership emerges from those whose primary motivation is a deep desire to help others' " (3).
I find it troubling that in Hesse's story the servant leader, Leo, abandons the group and it disbands, failing in it's quest to find the ultimate truth. Our hero of the story later searches and finds Leo, and it turns out that Leo is the leader of the "League" which sat about to test the group's faith with the journey. So is this parable to be emulated, do we wish our servant leader's to test and abandon us when we fail?
I do however like the concept of a leader as servant to the followship and the purpose. I think we should make our diagrams and models reflect this by placing the leaders at the bottom of the diagrams (org charts) with their actions and behaviors supporting the team (followship) within the context of their shared purpose.
This orientation was done on some of the first Org Charts by the railroad.
A Review of Leadership Models
1) Leadership Theory and Practice - 6th Ed. by Peter Northouse.
2) Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness - 25th Ann. Ed. by Robert Greenleaf
3) The Myth of Servant-Leadership: A Feminist Perspective by Deborah Eicher-Catt
We’re often asked which day or days are best for scheduling the Sprint Planning, Review, and Retrospective meetings.
In general, we prefer mid-week sprint transitions. People are most likely to take Monday or Friday off, so it’s easier to get the whole team reliably on Tuesday, Wednesday, or Thursday. Having a couple days to get started with the work for a new sprint and to build some momentum is nice, so I like planning on Wednesdays.
For a one week sprint, it’s possible to do Review, Retrospective, and Planning all on Wednesday morning. Or, you can do the Review and Retrospective in the morning, take a break to reenergize and to build the feedback from the previous meetings into your Product Backlog, and then plan in the early afternoon.
For a two or three week sprint, Review and Retrospective on Tuesday afternoon and Planning on Wednesday morning works well. With longer sprints, the meetings take proportionally longer; I find it useful to break them up across multiple days to maintain energy.
As with anything else in Scrum, you can make this an experiment. Make a hypothesis about what you expect to happen, try something for a while, and adapt if you’re not getting the results you like.
The post Scrum Basics: When Should We Schedule Sprint Transitions? appeared first on Agile For All.
There was a lot of talk about scaling Scrum at Agile 2014. Here's a photo of Dean Leffingwell, creator of the Scaling Agile Framework aka SAFe, and me. People have a lot of opinions about scaling frameworks. Some love them. Some hate them. Alex Brown and I presented a way to think about scaling that would apply to any framework (or lack thereof).
The interest in scaling shows that Scrum is not just about pilot projects any more. It is implemented widely across companies and managers need to start dealing with it as their major responsibility - making their company agile. So they want to know all the details about what they need to do. And they keep on wanting to add things to Scrum to make it more agile. When I ask them "How is that working for you?" they tell me how hard it is to implement Scrum.
What is most interesting to me is what they don't talk about. Scaling Scrum means getting rid of stuff because everything in Scrum is just in time and just enough. Here are a few things that companies are getting rid of.
1. Microsoft is getting rid of test teams
Scrum means you deliver working software in short intervals. That means all testing is completed as part of development so you have shippable code. If testing slides out of a sprint and is done later we have found in the U.S. and Europe that for complex products it takes 24 times as long to test outside a sprint as inside a sprint. And the best companies today are doing continuous deployment, something we started at PatientKeeper a decade ago. Ancestry.com delivers 220 releases to production every two week sprint. Hubspot does 170 live production updates on a slow day. Google has 15,000 developers working on one code branch and runs 75 million automated tests a day. Even Microsoft has a 3000 person Scrum that delivers a production release of all development tool products at the end of every three-week sprint. Testing is core Scrum in these companies.
2. Spotify got rid of DevOps and dependencies between teams
Operations was slowing deployment so Spotify decided to have the teams do all deployment. All teams upgrade their component of the live system at the end of every sprint. And now they are moving to continuous deployment. They still have agile operations teams that provide tools and advice while staying out of the way.
In order to deploy faster, Spotify got rid of dependencies between teams so that they could be as autonomous as possible. Remaining dependencies they identify and manage carefully.
3. Systematic got rid of management meetings
A CMMI 5 company, Systematic delivers Scrum projects at half the cost of their waterfall projects. Customers have a choice. But Systematic is Scrum top to bottom with almost 2000 people, including the senior management team. At the beginning of last year, their senior management Scrum did a cost benefit analysis of all their meetings, which showed that only the standard Scrum meetings had a value which exceeded the cost. So they banned all meetings that were not Scrum meetings.
This is just the beginning of stuff to get rid of because any extra weight slows you down and increases cost. That's why, as a former fighter pilot, I really like the Saab Gripen. Every six months they use Scrum to build a new release of the jet aircraft operating system with new hardware that makes it faster, cheaper, lighter, more efficient, more powerful, with better electronics and more sophisticated targeting. Aviation week calls it the best aircraft in the world and Janes Defense Weekly calls it the cheapest aircraft in the world.
Getting lean is always the hard part. To get there, the best book I've read for agile managers is Musashi's Book of Five Rings - how the world's best swordsman won every fight he ever fought. A close second is Certain to Win: The Strategy of John Boyd, Applied to Business. Boyd was the world's greatest fighter pilot who won every battle in under 40 seconds. Scrum Inc.'s Alex Brown also has an in-depth workshop on Agile leadership.
Agile means faster, better, cheaper, cooler. So throw that old ballast off the boat when scaling and turn Scrum from slow, hard, and painful into fast, easy, and fun!
-- Jeff Sutherland
This simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it. My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise. It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class. I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.
NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!
Pre-requisites: None! No prior Scrum or Agile knowledge or experience required.
Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.
Timing: This simulation takes at least 7 classroom hours. I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.
- Coloured pencils and/or coloured markers
- Black Sharpie fine-point markers
- Scotch tape and/or glue stick
- Blank white printer paper
- Pencils, erasers, pencil sharpeners
- Blank white 4×6 and 3×5 note cards
- Blank white box (e.g. a shirt box from U-Line)
- Planning Game cards (email me if you want a bunch for free!)
Room Setup: Round tables with 4 to 6 chairs at each table. Materials distributed to each table.
Agenda (with facilitator’s notes):
- Lecture: Simulation Overview, Backlog Preparation and Refinement
The purpose of the overall simulation is to learn to create a good Product Backlog in preparation for a Scrum team’s first Sprint. Review the agenda with participants.
- Discussion: Choosing a Product for the Simulation
Give participants four product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons”, “POS for food trucks with social features”, or come up with your own app idea). A table group must agree to one of the options. They will stick with this product for the remainder of the simulation. 5 minutes to decide (usually takes much less).
- Part 1: Product Vision
- Lecture: Innovation Games – Product Box
Talk about the need for a compelling vision as a pre-requisite for high-performance teams, and a way to decide what is in vs. out of a Product Backlog. Introduce “Product Box” as a way to do market research in an Agile compatible way (collaborative, light documentation, quick). Talk about the pattern of a product box: front to attract, back to showcase, sides to deal with objections. Use of online resources / web research is allowed but should not dominate the exercise.
- Exercise: Building Your Product
30 minutes, with warnings at 15 minutes and 5 minutes remaining. Ensure that by 10 minutes in, the group has actually started using the craft supplies and isn’t just talking.
- Exercise: Presenting Your Product
5 minutes – give additional time to allow groups to prepare for a trade show (in their market) presentation where other groups (or yourself) will role-play sceptical trade show participants.
- Discussion: Debrief
- Lecture: Innovation Games – Product Box
- Part 2: Product Users
- Lecture: User Categories
Describe “end users”, “customers” and “admin users” as the three major categories. Users can be in hierarchies where a general user type may have two or more specific sub-types.
- Exercise: Identifying Users
10 minutes. One user of each main type (end, admin and cust), at least 5 users in total. More is okay.
- Lecture: Personas, Usability and Empathy
Introduce Persona concept (great reference: “The Inmates are Running the Asylum” by Alan Cooper). Usability as part of Agile, not separate (i.e. “working software”). Identifying personas as a way to build empathy from the development team to the end users/customers.
- Lecture: User Categories
- Part 3: User Stories
- Handout: User Stories and Splitting
- Lecture: Writing Effective User Stories
Use the example “As a Job Seeker, I can upload my resume, so that I get a job.” Explain the user story template based on the handout. Emphasize the idea of end user functionality. Explain user stories as an important tool, but optional part of Scrum.
- Exercise: Create User Stories
Goal: 20 user stories for each group’s product, at least two user stories for each type of user, all done in 20 minutes. User Stories must be written on 3×5 note cards with a 2cm blank area on right side of each card.
- Discussion: Review User Stories
Workshop examples from each group. Ensure that the “benefit” section of each story does not contain a feature.
- Lecture: Splitting User Stories
Go through each of the “top” six splitting methods. Provide simple examples where the group needs help. E.g. error conditions as an example of splitting by business logic.
- Exercise: Split Some
Goal: result in at least 30 user stories, use each of the top six splitting methods at least once, give 15 minutes.
- Discussion: Review Splitting
- Part 4: Estimation and Financial Modelling
- Lecture: Effort, Value and ROI
Customers and business stakeholders estimate value, Scrum team members estimate effort, and ROI is the calculation of the ration of value over effort. Discuss examples of ordering based on these ratios, e.g. 8/2 vs. 8/4 and 200/20 vs. 20/2.
- Handout: The Bucket System
- Lecture: The Bucket System
Review process based on handout.
- Exercise: Estimating Business Value
10 minutes. Goal: all user stories get a business value estimate written in the top right-hand corner of the user story card.
- Discussion: Debrief the Bucket System
- Handout: The Planning Game
- Lecture: The Planning Game
- Exercise: Estimating Effort
20 minutes. Goal: estimate 3 user stories using the Planning Game. Use the Bucket System to estimate the remainder with the ones already estimated as the reference points.
- Discussion: Debrief the Planning Game
- Handout: Methods of Ordering the Product Backlog
- Lecture: Ordering a Product Backlog
Review ROI as a method to order the PBIs. Reminder that the Product Owner has final authority and can ignore the estimates in deciding on the order.
- Exercise: Calculating ROI and Ordering
5 minutes. Just simple divide-and-conquer calculations of business value divided by effort for all the user stories.
- Lecture: Simulation Wrap-Up – Where Does This Fit?
Reminder of the idea of creating an initial Product Backlog that is “good enough” to start the first Sprint.
- Lecture: Effort, Value and ROI
NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Scrum ist großartig. Entscheidungen werden dort getroffen, wo die größte Kompetenz liegt. Nur was, wenn mein Team das gar nicht so großartig findet? Wenn die Teammitglieder lieber tun, was man ihnen sagt? Dann sind sie hinterher, falls etwas schief geht, wenigstens nicht schuld. Schuldkultur führt zu Pflichterfüllung statt Verantwortungsübernahme. Wenn ich das als ScrumMaster erkannt habe, wie kann ich dann damit umgehen? Wie schaffe ich es, meinem Team Mut zu machen, selbst Entscheidungen zu treffen?1. Rahmen schaffen Sicherheit
Je größer das Sicherheitsbedürfnis, desto enger sollte der Rahmen sein, um kleine Entscheidungen mit geringfügigen Konsequenzen treffen zu können. Mit der Erfahrung kommt das Vertrauen. Das Vertrauen liegt übrigens auf beiden Seiten: Bei demjenigen, der Verantwortung übernimmt ebenso wie bei dem, der Kontrolle abgibt.
Jeder ScrumMaster kennt die Situation am Anfang einer Scrum-Einführung: Im Daily stehen alle Teammitglieder in einem großen Sicherheitsabstand zum Board, niemand will etwas sagen müssen.
Durch die 4 Fragen
- Was hast Du gestern erledigt?
- Was wirst Du heute tun?
- Gibt es etwas, das Dich behindert? und
- Brauchst Du Unterstützung oder kannst Du jemanden unterstützen?
geben wir dem Daily einen engen Rahmen. Die Teammitglieder haben nicht viel eigenen Gestaltungsspielraum. Es entsteht umso mehr Vertrauen, je häufiger Dailies gemacht werden. Der ScrumMaster macht die Erfahrung, dass das Team die 15 Minuten nutzt, um sich auszutauschen. Beim Team entsteht das Vertrauen, dass der Termin nicht dazu gedacht ist, sie zu kontrollieren. Ebenso wie im Beispiel ‘Daily’ funktioniert das mit dem Scrum-Framework als Ganzes. Der feste Rahmen gibt den benötigten Freiraum.2. Schulddiskussionen rigoros unterbinden
Es ist wichtig herauszustellen, dass die Frage, wer schuld ist, gänzlich uninteressant ist. Jedwede Diskussion der Schuldfrage muss vom ScrumMaster sofort unterbrochen werden. Für eine konstruktive Analyse der Ursachen bieten sich die 5-Warums und die Fischgräten-Analyse an. Die Erfahrung, nicht vorgeführt zu werden, wenn etwas nicht wie erwartet funktioniert hat, schafft Vertrauen.
Mein persönlicher Erfolg war, als eines Tages ein Kollege sagte: „Da standen drei Leute aus drei verschiedenen Abteilungen vor dem Gerät zusammen, und statt wie früher drei Tage lang darum zu streiten, wer schuld ist, haben wir innerhalb von ein paar Stunden eine Lösung erarbeitet.”
Lächeln auf den Gesichtern. Stille Freude und Stolz, dass sie es geschafft haben, die lästige Schuldfrage hinter sich zu lassen.
- Scrum Rollen: ScrumMaster | Robin Hood
- Was macht Scrum Teams eigentlich hyperproduktiv?
- Die Skills eines guten ScrumMasters
After some requests (and a little bit of ruby), I’ve decided to bring back the weekend reading posts … which I’m calling the Weekend Edition.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It’s generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
You can get the Weekend Edition delivered directly to you via email by signing up here.
- RT @othertwice: LOL “We spent $500k on SharePoint and people still aren’t collaborating!” ~Dilbert #agile #scrum via…
- RT @othertwice: LOL “We spent $500k on SharePoint and people still aren’t collaborating!” ~Dilbert #agile #scrum via…
- Get the best from your Retrospectives #agile #scrum #kanban what do you think!?
- Read This Book : #Kindle #6655 #5: Scrum: a Breathtakingly Brief and Agile Introduction
- (After a small amount of CMS-wrestling) Upcoming events are now front & center at Where #agile #scrum & #xplives ;-)
- RT @MindtreeFlorida: Hiring! Scrum Master in Gainesville, FL #job #agile #mindtree
- READ BOOK > # Kindle #61 #2: Scrum: a Breathtakingly Brief and Agile IntroductionScrum… http://t.co/H51IEUssTv
- Considering Outsourcing Software Development – a model #agile #scrum
- Read Book : #Kindle #213 #6: Scrum: a Breathtakingly Brief and Agile IntroductionScrum… http://t.co/tiOFHaCdAX
- Nice article