Skip to content

Feed aggregator

Adventures in Europe

ScrumSense.com - Peter Hundermark - Wed, 09/10/2014 - 22:41
IMG_5392

Denmark trainees

Shortly after joining Scrum Sense in February this year I started my journey to become a Certified Scrum Trainer (CST). The process includes co-training with other CSTs around the world, so that I can get feedback to improve and, once I am good enough, I can get their recommendations that are essential to acceptance. For the past week I have been lucky enough to travel around Europe and co-train with some of the top CSTs and CSCs (Certified Scrum Coaches) in Europe. It has been a wonderful experience for me.

My trip started in Copenhagen, where I spent a wonderful two days with Carsten Feilberg, a friend and an incredible tester. We spent time refining our workshop for Let’s Test Oz where we will be presenting on Communicating Complex Information in Sydney next Tuesday. We have been designing the workshop over mail and Skype for the past couple of months and being together once more re-enforced the Agile principle that face-to-face communication is the best kind. We have come up with a great design and I am really looking forward to our session.

IMG_5393

CSM Aarhus with Bent Myllerup

My next stop was Aarhus also in Denmark. There I met up with Bent Myllerup, a very experienced CST and CSC with agile42. I spent two days co-training a public Certified Scrum Master (CSM) class with Bent in Denmark. Lucky for me the course was delivered in English. We had eight participants and received wonderful feedback. I was able to train some of the modules and learned some new techniques from Bent. I love being in a fresh context, because I can always learn new things and see how different people understand and take in information. It’s also interesting to see the European adoption of Agile, the different industries that are beginning to understand the value of empirical process control and fast feedback loops, and  working with teams instead of individuals. Bent speaks about a truck factor which I thought was a novel way of illustrating the point of resilience. The track factor is the number of people in a team that, if they were hit by a truck or won the lotto and left, the project would have to stop. So if you have only one key team member that knows everything and that information is not shared in some way with the team then you have a truck factor of one. A higher truck factor is better than a lower one. What is the truck factor of your teams?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

From Denmark I went to Berlin. Berlin is an amazing and crazy city. I arrived early on Saturday morning. Half of the city hadn’t woken up yet and the other half hadn’t been to bed. I was lucky enough to get to explore and see some of the sights. Sunday evening I met up with Andrea Tomasini, another very experienced and talented trainer and coach from agile42. We ran through our course plan for another CSM class on Monday and Tuesday. I got the opportunity to see Andrea in action and to train some of the course modules. I really enjoyed the way that both trainers focused not only on Scrum, but also on how important it is to be Agile. Transformation is difficult and changing your mindset early on is important. It’s also interesting to see how many companies both in South Africa and internationally have similar problems. We had 20 participants from all different backgrounds from gaming to building of aeroplanes. Who said Agile is just for software?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

It’s amazing to see how many different contexts are interested in the principles and values of Agile and Scrum, and how many people are really keen and eager to learn. The Training from the Back of The Room approach also helps to encourage people to learn on their own and creates an atmosphere of excitement and energy.

All in all it was an amazing experience. I had the opportunity to work with some great coaches and trainers and to learn new things that I can bring home. I love how supportive and encouraging our community is, both in South Africa and internationally. This is a long and tough journey and I feel that this trip has really helped to get me to the next level.

I am looking forward to co-training the next CSPO course in Johannesburg with Peter starting 30 September. Maybe I will see you there. If not I’ll be speaking at the Scrum Gathering in Cape Town in October, or maybe I will catch you at Let’s Test in Australia next week!

The post Adventures in Europe appeared first on ScrumSense.

Categories: Blogs

Planning Feedback: Don’t Panic!

Agile Tools - Tom Perry - Wed, 09/10/2014 - 08:31

Ring the Alarm

So the other day a VP asked our team for an estimate on a project. Now, putting aside whatever feelings you may have about the usefulness of estimates, we did a little planning, a little investigating, a little debating, and came up with an estimate for the project. I brought the estimate back to the VP and then the fireworks began. Apparently he had been thinking of a different number than we had given him. He wanted it done in half the time that we had forecast.

Whoops.

Now at this point in the story a lot of teams will panic and come back with one of two reactions:

  1. Fight – “We can’t do that! That’s not Agile” (or some variation on that tired theme)
  2. Cave – “We have no choice…”

But wait a second, there is a middle path. You can agree, but ask what can be compromised in terms of scope or other project constraints. You see, a new project is not just a learning process for you. Its also  learning process for the customer too. When  you get that first feedback, DON’T PANIC!

There is one important part of the planning process that I often see get lost: iteration. Doing a single round of planning and then presenting it to your customer as “Take it or leave it” isn’t what I’d call much of a dialog.

What we should be doing is some lightweight planning then review with the customer. “That’s horrible!” They cry, and then you say, “So what number were you thinking of?” And they return with something totally preposterous. OK, that’s cool. “Is there functionality we can drop to hit that date?”

No.

Of course not. So you go back, you scratch your head, cut out all the fluff you can find…and you still are way off the desired estimate. So then you take it back to them and say, “Hey look, I know this isn’t what you wanted, but here is the ABSOLUTE minimum we can get away with.” At which point, the customer looks at you with a tear in their eye and says these magic words, “What CAN you give me?”

Now you have a real negotiation! It may not always play out this way, but hopefully you get the point. You can’t freak out when they give you that first reaction. Stay cool – this is the first time they’ve had to test their fantasies against your capabilities. They need to learn too. So give your stakeholders a chance to work together with you on figuring out just what is possible. Negotiate. The more iterations you go through, the better your chances of coming to an agreement that everyone agrees is the best.


Filed under: Agile, Process Tagged: Agile, estimates, estimation, executives, Feedback, panic, Planning, stakeholders
Categories: Blogs

Say Why to Estimates

Bobtuse Bobservations - Bob MacNeal - Wed, 09/10/2014 - 05:33
Agile estimation surfaces a clash of cultures. Broadly speaking the Agile community consists of makers & managers. The clash between makers & managers distills to motivation: Why &...

Bobtuse can be wildly informative
Categories: Blogs

Dealing With Negative Issues in Retrospectives

Ben Linders - Tue, 09/09/2014 - 19:25
Agile Retrospectives help teams to continuously improve to become better in what they do. As they are a learning experience for the team the atmosphere in a retrospective meeting is usually positive. But when there have been major problems in an iteration, maybe even conflicts between team members, then team morale can be low and negativism can occur in the retrospective meeting. This is the story of how a reader of our book on Valuable Agile Retrospectives dealt with negative issues in his retrospective. Continue reading →
Categories: Blogs

Agile Metrics

Scrum Expert - Tue, 09/09/2014 - 17:54
“You can’t manage what you don’t measure” is an adage that is popular in project management. However, metrics programs are not easy to implement and have their dark sides. In their book “The Agile Culture: Leading through Trust and Ownership”, Pollyanna Pixton, Paul Gibson and Niel Nickolaisen provides some advice about implementing metrics, the Agile way. How do we make sure that the metrics we are using are effective and not just vehicles for giving leaders a feeling of power and control while not achieving anything useful? How do we know ...
Categories: Communities

Acceptance Criteria

Leading Agile - Tue, 09/09/2014 - 16:47
Acceptance Criteria


Did We Build the Right Product? And, Did We Build the Product Right?

Acceptance criteria are an important yet, in my experience, often overlooked or undervalued aspect of the iterative planning process. Acceptance criteria are super important because projects succeed or fail based on the ability of the team to meet their customers documented and perceived acceptance criteria. When we clearly define acceptance criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction.  In other words we’re able to answer these two important questions: Did we build the right product? And, Did we build the product right?

What are Acceptance Criteria?

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.

We’re not talking about horsheoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.

When are Acceptance Criteria defined?

A trap that I encourage my teams to avoid is writing acceptance criteria after development has started. This leads to merely verifying that the functionality built works rather than verifying that the functionality meets user needs and expectations. If we write and review acceptance criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality.

What makes good Acceptance Criteria?

Acceptance criteria define when a work item is completed and working as expected. Acceptance Criteria should be expressed clearly, in simple language the customer would use, without ambiguity regarding the expected outcome. This sets our testers up for success, since they  will be taking our acceptance criteria and translating them into automated test cases to run as part of our continuous integration build.

What. Not how.

Another trap that I coach my teams to avoid is ‘The how trap.’ Acceptance Criteria should state intent, but not a solution (e.g., “A user can approve or reject an invoice” rather than “A user can click a checkbox to approve an invoice”). The criteria should be independent of the implementation, and discuss WHAT is expected, and not HOW the functionality will be implemented.

Acceptance Criteria Formats

The Given/When/Then format is helpful way to specify acceptance criteria:

Given some precondition When I do some action Then I expect some result

When we write acceptance criteria in this format, it not only provides a consistent structure, but we are also helping testers determine when to begin and end testing for that specific work item.

Sometimes it’s difficult to construct acceptance criteria using the given, when, then, format. Particularly when dealing with system level user stories. In those cases, I’ve found that using a verification checklist works well.

Another advantage to Verification checklists is that they are also simple to individually mark as complete as we implement functionality.

What are some of the challenges or techniques you’ve found when writing acceptance criteria?

The post Acceptance Criteria appeared first on LeadingAgile.

Categories: Blogs

Cost, Value & Investment: How Much Will This Project Cost? Part 1

Johanna Rothman - Tue, 09/09/2014 - 14:48

I’ve said before that you cannot use capacity planning for the project portfolio. I also said that managers often want to know how much the project will cost. Why? Because businesses have to manage costs. No one can have runaway projects. That is fair.

If you use an agile or incremental approach to your projects, you have options. You don’t have to have runaway projects. Here are two better questions:

  • How much do you want to invest before we stop?
  • How much value is this project or program worth to you?

You need to think about cost, value, and investment, not just cost when you think about about the project portfolio. If you think about cost, you miss the potentially great projects and features.

However, no business exists without managing costs. In fact, the cost question might be critical to your business. If you proceed without thinking about cost, you might doom your business.

Why do you want to know about cost? Do you have a contract? Does the customer need to know? A cost-bound contract is a good reason.  (If you have other reasons for needing to know cost, let me know. I am serious when I say you need to evaluate the project portfolio on value, not on cost.)

You Have a Cost-Bound Contract

I’ve talked before about providing date ranges or confidence ranges with estimates. It all depends on why you need to know. If you are trying to stay within your predicted cost-bound contract, you need a ranked backlog. If you are part of a program, everyone needs to see the roadmap. Everyone needs to see the product backlog burnup charts. You’d better have feature teams so you can create features. If you don’t, you’d better have small features.

Why? You can manage the interdependencies among and between teams more easily with small features and with a detailed roadmap. The larger the program, the smaller you want the batch size to be. Otherwise, you will waste a lot of money very fast. (The teams will create components and get caught in integration hell. That wastes money.)

Your Customer Wants to Know How Much the Project Will Cost

Why does your customer want to know? Do you have payments based on interim deliverables? If the customer needs to know, you want to build trust by delivering value, so the customer trusts you over time.

If the customer wants to contain his or her costs, you want to work by feature, delivering value. You want to share the roadmap, delivering value. You want to know what value the estimate has for your customer. You can provide an estimate for your customer, as long as you know why your customer needs it.

Some of you think I’m being perverse. I’m not being helpful by saying what you could do to provide an estimate. Okay, in Part 2, I will provide a suggestion of how you could do an order-of-magnitude approach for estimating a program.

Categories: Blogs

Management Tips from Andrew Homeyer of Waffle

Rally Agile Blog - Tue, 09/09/2014 - 14:00

This post, an interview between Grokky co-founder Dan Abdinoor and Rally engineer Andrew Homeyer, originally appeared at the Grokky blog on September 8. Andrew is product lead and engineering manager of Waffle, a Rally Innovation Labs project created in 2013. Andrew currently manages a team of six and his manager is Rally’s Chief Technology Officer. 

Dan: Andrew, please introduce yourself!

Andrew: I’m an intrapreneur and engineer. As for titles I sometimes go by Chief Waffle Maker. In truth, I balance my time between leading the team building Waffle.io and trying to still do a bit of development myself.

Dan: Waffle is part of Rally Software; what's the story behind that?

Andrew: Waffle.io is an Enterprise Lean Startup; that is, we’re a small team building Waffle like a startup inside Rally Software, following lean startup principles. We’re a team of six today, distributed between Boulder, Colorado, and Raleigh, North Carolina. But our humble beginnings go back to the summer of 2013 when Waffle started as a team of interns, exploring a new market segment for two months.

Dan: How has your management style evolved from when you started Waffle?

Andrew: To borrow from Reid Hoffman’s The Start-Up of You, I’m always iterating on myself. My management style changes every time I interact with different types of individuals, to meet them where they are and to make my team the most effective it can be together.

Recently I’ve been learning from Dan Pink’s ideas of Autonomy, Mastery, and Purpose, taught to me by some great leaders at Rally. What does it look like for you to discover the internal motivation for your team members? What drives them? These questions have caused me to change the way I interact with my team.

Dan: How do you run your one-on-one meetings?

Andrew: First rule of 1:1 meetings is to be consistent, and frequent. I do them weekly, for both remote and local team members. You start building trust and respect, one of our core values, when you put the time into it. Even when there aren’t any burning topics to discuss, it’s worth the investment of a 20-minute meeting every week.

As for the structure, I try to shy away from talking about the work we’re doing. In some cases that’s what we discuss; but talking about team dynamics, personal goals, frustrations and excitements — those are the things that help me discover what someone cares about and how to make our team more effective together.

Dan: What are some of your management suggestions for others?

Andrew: There’s a difference between technical leadership and people leadership. If you’re managing others, make that separate from your role of technical leadership. Yes, mentor others when you’re more experienced and capable at certain things. But, when I’m wearing my people management hat, my goal is to help someone discover what skills they want to nurture and how they can best contribute to the team’s shared vision.

Management ties closely to hiring. If you hire well, it changes how you manage. The question I ask myself when hiring someone is whether they currently are, or have the potential to be, better than me in some given role. If that’s true, then the role of leader becomes to uplift their skillsets or mentor them to fulfill their potential.

I always put the person first. It’s a careful balance between meeting business objectives and a person’s desires, so hire and fire based on building a team that can have that overlap. If you can encourage an individual based on their internal motivation, and help them achieve their personal goals, your team and business will benefit from their dedication and commitment.

Dan: Have you ever had a moment where you felt that you had completely failed as a manager? What have you learned from it?

Andrew: Sure. Several times come to mind when I’ve decided to take personal responsibility for a piece of work, because I’m not satisfied with the quality my team produced. It usually builds frustration and distrust, when I should work with the team to figure out how we can produce better quality work on the right schedule together. One way we work towards this is with a high focus on pairing, whether it be on code or non-dev work. It’s a great way to improve quality and share learning.

Dan: What challenges are you still figuring out as a manager?

Andrew: Realizing that everyone is unique, and not motivated by the same things. How do you create a shared vision that each person takes personal responsibility to accomplish?

Also, I’m always looking for ways to work with remote team members better. Travel helps; if you don’t see each other face-to-face often enough, you forget who they are as a person and it’s easy to jump to blame when things go wrong. It’s something I try to be aware of and work towards improving.

 

Andrew Homeyer
Categories: Companies

Management Tips from Andrew Homeyer of Waffle

Rally Agile Blog - Tue, 09/09/2014 - 14:00

This post, an interview between Grokky co-founder Dan Abdinoor and Rally engineer Andrew Homeyer, originally appeared at the Grokky blog on September 8. Andrew is product lead and engineering manager of Waffle, a Rally Innovation Labs project created in 2013. Andrew currently manages a team of six and his manager is Rally’s Chief Technology Officer. 

Dan: Andrew, please introduce yourself!

Andrew: I’m an intrapreneur and engineer. As for titles I sometimes go by Chief Waffle Maker. In truth, I balance my time between leading the team building Waffle.io and trying to still do a bit of development myself.

Dan: Waffle is part of Rally Software; what's the story behind that?

Andrew: Waffle.io is an Enterprise Lean Startup; that is, we’re a small team building Waffle like a startup inside Rally Software, following lean startup principles. We’re a team of six today, distributed between Boulder, Colorado, and Raleigh, North Carolina. But our humble beginnings go back to the summer of 2013 when Waffle started as a team of interns, exploring a new market segment for two months.

Dan: How has your management style evolved from when you started Waffle?

Andrew: To borrow from Reid Hoffman’s The Start-Up of You, I’m always iterating on myself. My management style changes every time I interact with different types of individuals, to meet them where they are and to make my team the most effective it can be together.

Recently I’ve been learning from Dan Pink’s ideas of Autonomy, Mastery, and Purpose, taught to me by some great leaders at Rally. What does it look like for you to discover the internal motivation for your team members? What drives them? These questions have caused me to change the way I interact with my team.

Dan: How do you run your one-on-one meetings?

Andrew: First rule of 1:1 meetings is to be consistent, and frequent. I do them weekly, for both remote and local team members. You start building trust and respect, one of our core values, when you put the time into it. Even when there aren’t any burning topics to discuss, it’s worth the investment of a 20-minute meeting every week.

As for the structure, I try to shy away from talking about the work we’re doing. In some cases that’s what we discuss; but talking about team dynamics, personal goals, frustrations and excitements — those are the things that help me discover what someone cares about and how to make our team more effective together.

Dan: What are some of your management suggestions for others?

Andrew: There’s a difference between technical leadership and people leadership. If you’re managing others, make that separate from your role of technical leadership. Yes, mentor others when you’re more experienced and capable at certain things. But, when I’m wearing my people management hat, my goal is to help someone discover what skills they want to nurture and how they can best contribute to the team’s shared vision.

Management ties closely to hiring. If you hire well, it changes how you manage. The question I ask myself when hiring someone is whether they currently are, or have the potential to be, better than me in some given role. If that’s true, then the role of leader becomes to uplift their skillsets or mentor them to fulfill their potential.

I always put the person first. It’s a careful balance between meeting business objectives and a person’s desires, so hire and fire based on building a team that can have that overlap. If you can encourage an individual based on their internal motivation, and help them achieve their personal goals, your team and business will benefit from their dedication and commitment.

Dan: Have you ever had a moment where you felt that you had completely failed as a manager? What have you learned from it?

Andrew: Sure. Several times come to mind when I’ve decided to take personal responsibility for a piece of work, because I’m not satisfied with the quality my team produced. It usually builds frustration and distrust, when I should work with the team to figure out how we can produce better quality work on the right schedule together. One way we work towards this is with a high focus on pairing, whether it be on code or non-dev work. It’s a great way to improve quality and share learning.

Dan: What challenges are you still figuring out as a manager?

Andrew: Realizing that everyone is unique, and not motivated by the same things. How do you create a shared vision that each person takes personal responsibility to accomplish?

Also, I’m always looking for ways to work with remote team members better. Travel helps; if you don’t see each other face-to-face often enough, you forget who they are as a person and it’s easy to jump to blame when things go wrong. It’s something I try to be aware of and work towards improving.

 

Andrew Homeyer
Categories: Companies

“Worum geht’s hier eigentlich?” – Mit der inneren Landkarte erfolgreich kommunizieren

Scrum 4 You - Tue, 09/09/2014 - 07:48

"Und das ist alles nur in meinem Kopf." Andreas Bourani

In kritischen Gesprächen stellt man sich häufig die Frage, was im Kopf des Gegenübers denn so vorgeht. Wie kommt der/die dazu, so aggressiv zu reagieren, sich trotzig zurückzuziehen, oder alles wieder mal ganz anders zu „sehen“ als ich. Keine Einigung in Sicht, aneinander vorbei reden. Eskalationsgefahr, Frust und du stehst auf dem Schlauch. Deinem Gegenüber aber geht es vielleicht ganz genauso. Wenn Du nicht jemand bist, der dem anderen schnell die Schuld an den Schwierigkeiten in die Schuhe schiebt, stellst Du Dir vielleicht einige (selbst-) kritische Fragen. Zumindest im Nachhinein: Was lief da schief? Was hat der/die andere wohl gedacht? Bin ich ihm/ihr ungewollt auf die Füße getreten? Was war dem/der wirklich wichtig? Und wie ging es mir eigentlich selbst in dem ganzen „Ping Pong“? Warum habe ich so und nicht anders reagiert, evtl. effektiver?

Kleines Beispiel Teil 1: Ein Teamleiter führt spontan zwischen “Tür und Angel” ein Gespräch mit einer Mitarbeiterin. Er kommuniziert seiner relativ neuen Mitarbeiterin sehr sachlich seine Einschätzung, dass ihre Leistung in der ersten Jahreshälfte bei Weitem nicht ausreichend gewesen sei (war schon vor einem Vierteljahr Thema), er aber die deutliche Steigerung im zweiten Halbjahr ganz super finde. Zwei Tage später erfährt er über eine andere Mitarbeiterin, dass die Kollegin ganz geknickt ist und sich von ihrer Führungskraft nicht richtig anerkannt fühlt. Evtl. herrscht Demotivationsgefahr. Er ist sehr erstaunt und kann sich die Reaktion nicht erklären, er wollte doch eigentlich nur loben und stärken.

Gelungene Kommunikation lebt vom gegenseitigen Verständnis. Das heißt, die jeweils vorhandenen subjektiven Informationen und Botschaften möglichst auf einen gemeinsamen Nenner zu bringen. Ein „gläserner Kopf“, die Möglichkeit des Blicks in die Gehirne der Gesprächspartner wäre hier sehr hilfreich, aber das bleibt ein frommer Wunsch. Oder vielleicht Menschenkenntnis? Obwohl, ich bin seit weit mehr als zwanzig Jahre ein durchaus erfolgreicher Coach, weiß aber bis heute nicht, ob ich eine besonders gute Menschenkenntnis habe. Eher die Fähigkeit, im direkten Kontakt schnell in etwa zu erfassen, was den anderen bewegt (oder bewegen könnte, auch Unausgesprochenes, ja Unbewusstes) und mich meinerseits klar auszudrücken, halbwegs eindeutige Botschaften zu senden. Statt Menschenkenntnis, Menschenerkenntnis. Mir hilft hier z.B. immer das Kommunikationsmodell der „inneren Landkarte“ als Orientierungsrahmen weiter. Es hilft mir, genau hinzuhören, genau hinzuschauen, genau wahrzunehmen.

Jeder hat seine inneren Landkartenmuster

In der Kommunikation geht es immer um einen ganzheitlichen Erfahrungsprozess. Beide Gesprächspartner sehen, hören, denken, fühlen und wollen in jedem Moment des Kommunikationsprozesses, ob ihnen das bewusst ist oder nicht. Die sinnlichen Wahrnehmungen werden an das Gehirn weitergeleitet, dort verarbeitet und als situative oder mehr oder weniger dauerhafte Erfahrungs- und Wissensinformationen abgespeichert.“ Diese „inneren Landkartenmuster“ konstruieren wesentliche Elemente der Realität, können jedoch niemals das gesamte Gebiet in seiner Komplexität abbilden. Sie wirken und aktualisieren sich in jedem Gesprächsmoment in höchst subjektiven, gefilterten und selektierten Abbildungen der Realität! Willst Du also etwas über Dein Gegenüber erfahren, erforsche seine „innere Landkarte“. Willst Du ihm/ihr Einblick in Deine „Welt“ geben, sprich über deine „innere Landkarte“. Wenn die Bilder, Worte, Gedanken, Gefühle, Intentionen für euch beide transparent und nachvollziehbar werden, entsteht gegenseitiges Verstehen und Verständnis.

compass-429772_1280

Welches sind nun hilfreiche Elemente der „inneren Landkarte“, um Kommunikation im Sinne von gegenseitigem Verständnis zu bereichern? Um nachvollziehen zu können warum andere so und nicht anders handeln, reagieren, agieren, brauchen wir Wahrnehmungen, Denken, Gefühle, Intentionen.

Unsere Wahrnehmungen in Kommunikationsprozessen sind die Informationen, die wir von außen aufnehmen – also das, was wir in einer Situation sehen, hören, spüren. Unsere Sinnesorgane liefern uns allerdings selektierte und gefilterte Informationen. Wir können überhaupt nur einen Bruchteil der möglichen externen Informationen aufnehmen und bewusst oder unbewusst speichern. Diese Impulse von außen treffen natürlich nicht auf ein „leeres Blatt“, sondern auf bewusste und unbewusste Informationen, die wir über die Jahre unserer Biographie gesammelt und gespeichert haben, und die sozusagen ein „beschriebenes Blatt“ ergeben.

Diese Kombination aus äußeren und inneren Informationen bestimmt nun folgerichtig unser Denken in Form von mehr oder weniger komplexen Assoziationen, Hypothesen, Deutungen, Phantasien etc. Gebe ich in einem meiner Kommunikationstrainings zehn Teilnehmern z.B. den Begriff Italien vor, erhalte ich spontan mindestens sieben unterschiedliche Assoziationen von Pizza, über Strand bis hin zu Amore? Die Wahrnehmungen und Gedanken aktivieren wiederum unsere Gefühlswelt oder umgekehrt. Und Gefühle haben eine immens hohe Bedeutung für so ziemlich alles, was uns bewegt und zum Handeln bringt. Allerdings, bevor wir handeln, schalten sich unsere Intentionen, unser Wollen und Wünschen zu. Und meist mit mehreren bewussten und unbewussten Optionen. Was ist mir wichtig, was erwarte ich, welche Optionen habe ich zur Auswahl. Jede Information von Bedeutung durchläuft diesen inneren Prozess und gestaltet ganz situativ unsere subjektive „innere Landkarte“. Kompliziert und oftmals schwierig wird das Ganze, da sich dabei sowohl bewusste als auch unbewusste Informationen vermischen.

Was könnte der Umgang mit dem Modell der „inneren Landkarte“ nun für unser Beispiel oben heißen?

Hätte der Teamleiter seine junge Mitarbeiterin genauer wahrgenommen, hätte er vielleicht einschätzen können, dass ihre „innere Landkarte“ allgemein oder auch situativ eher auf Kritik als auf Lob reagiert oder situativ reagiert hat und sie daher eher negative Hypothesen entwickelt. „Der ist unzufrieden mit mir, dem kann ich es nicht recht machen. Ich bin ihm zu langsam.” Damit wechselt sie schnell in einen negativen Gefühlszustand. Dies hätte er evtl.an ihrem Sprachmuster oder ihrer Körpersprache erkennen können. Also wäre es eventuell besser gewesen, den Hinweis auf das kritische erste halbe Jahr ganz wegzulassen und nur Anerkennung auszusprechen. Oder er hätte zuerst nachfragen können, wie sie selbst ihre Leistung über den entsprechenden Zeitraum einschätzt. Oder ob jetzt der richtige Zeitpunkt für ein teils kritisches Feedback ist. So hätte er Informationen über ihren aktuellen Zustand, ihre aktuelle „innere Landkarte“ bekommen. Die viel besprochene Empathie ist hier vielfach hilfreich, um das Feedback danach auszurichten – vielleicht sogar zu verschieben, weil es im Moment ihre Intention war, jetzt damit in Ruhe gelassen zu werden. Hätte er seine innere Landkarte gecheckt, hätte ihm sein Bauchgefühl einen stimmigen Hinweis gegeben. Denn Feedback ist vor allem dann effektiv, wenn es “richtig” ankommt und eine Perspektive im Sinne von Entwicklung anstößt.

Fazit: Seid in Euren Kommunikationsprozessen Forscher – Erforscher der „inneren Landkarten“ eurer Partner und Partnerinnen und eurer eigenen. Und nehmt Euch die Zeit, um mit Aufmerksamkeit und Empathie euch und den anderen Chancen zu geben, ein gemeinsames Verständnis für das nicht immer eindeutig und transparent Gesagte, aber Gemeinte, Gedachte, Gefühlte, Gewünschte zu erreichen.

Tipp: Geführte Expeditionen auf das Gebiet der inneren Landkarten bietet das Training “Discussion plus” - Informationen dazu gibt es hier

Related posts:

  1. Die wertvolle Meetingzeit sinnvoll nutzen, effektiv kommunizieren (Teil 2)
  2. Stürmische Zeiten – über den Umgang mit den eigenen Emotionen in Konflikten
  3. Mit dem Inneren Team Probleme lösen

Categories: Blogs

Radical Transparency

Agile Tools - Tom Perry - Tue, 09/09/2014 - 05:02

cokin-filter-field-hand-1050

 

 

 

 

 

 

 

 

I’ve always been a big fan of transparency in Agile projects. I love the idea of project stakeholders having an unobstructed view into the work that the team is doing. Of course, what does transparency really mean? To me, transparency means that anyone, whether or not they are a member of the team, can easily see for themselves the current state of the work. That includes all work completed, work in progress, and work remaining to be done. It includes all impediments, risks, and retrospective action items. In short, the customer should be able to see all of the artifacts that the team produces. That’s the idea anyway.

But what happens in practice? Well, if you are intimately acquainted with the team then you will have no trouble reading their stories, understanding their acceptance criteria, and otherwise deciphering whatever agile artifacts just happen to be pinned to the wall.

But what if you have multiple projects taking place at once? Suddenly any given story, of the hundreds of stories in progress, is likely to be completely opaque. Without the context of what the team is working on, coming in as an outsider can be disorienting. Try it out yourself. Walk into a team room of a team you don’t ever work with. March up to their task board and see if you can understand just what the hell they are working on. The odds are pretty darn good that you won’t have a clue.

Actually this makes a lot of sense if you consider that the backlog and the task board are a reflection of the learning that the team has done as they work to deliver a project. Together the team shares a collective set of lessons learned that has been acquired over the duration of the project. You really can’t expect someone to come into a project midway through and understand everything that the team is currently working.

Teams create their own shared understanding of the work they are doing. They often develop a shorthand to describe what they are doing that is difficult for an outsider to initially understand. If we understand team learning this way, then is it really reasonable for a team to have meaningful “transparency” once they have made significant progress on a project?

I think it depends on the information that one is looking for. It’s probably reasonable to expect to see a burn down chart and be able to understand what it tells us, even without knowing anything at all about the work the team is doing. You should be able to at least answer the question, “Are these guys going to deliver everything they are working on in this sprint?” There are a few artifacts that fit this description:

  • Burn down charts
  • Release burn down charts

Yikes! That’s not much to work with! But just about anything else you look at is very likely to be opaque if the project is even reasonably complex. It’s doubtful you will recognize what is in the product backlog (but not unreasonable, because we hope it is expressed in business terms). My experience is that teams start adding their own material to product backlogs fairly quickly. Once they start adding their own stories, they’re starting to share in the learning with the product owner. They are starting to alter their collective knowledge of the problem (aka learning). Some teams will be able to keep the backlog in business terms that everyone can understand, but that actually seems to be pretty rare. Teams tend to switch into their own shorthand fairly quickly.

OK, so maybe the backlog is transparent (maybe not). How about the task board? I can almost guarantee that the task board is going to be a complete mystery to your average project stakeholder who hasn’t been involved in the day to day development of the project. That’s OK, they usually don’t want to know the gory details anyway.

I used to have a notion of radical transparency when it came to development projects. Now I find myself questioning the utility of that notion. Not all the information that is important to the team is necessarily important to the team stakeholders. This seems to be especially true the larger the number of teams that you have working together.


Filed under: Agile, Scrum, Teams Tagged: Agile, Metrics, radical transparency, Teams, transparency, visibility
Categories: Blogs

Using the Scrum Rules Against the Boss

Scrum Expert - Mon, 09/08/2014 - 17:54
Some managers think that Scrum is invented to make developers work harder. This is a lie. Scrum was invented by developers to keep managers away so that developers get time to do actual work. Learn how the Scrum rules can be used against your boss to get a realistic workload and more coding time without interruptions.Video producer: http://www.ndcoslo.com/
Categories: Communities

Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly (Part 1 of 4)

The Agile Management Blog - VersionOne - Mon, 09/08/2014 - 17:16

Consider these five very different types of organizations:

1.  An organization with fairly hierarchical management structure, traditional Project/Program Management Office (PMO) trying to transition from traditional waterfall development to agile development.  Some teams have just a few months of experience with Scrum, and perhaps worked with few XP or Lean practices.  Budgets are done on an annual basis.  Senior management pays lip service to agile transformation and treats agile as a silver bullet.

2.  A government contractor is used to delivering projects on a fixed-price basis.  The government agency has now asked the contractor to use agile methods for large-scale agile projects.

3.  The CIO and CEO of an enterprise are strongly committed to agile-lean development and have given a top-down marching order to follow agile methods.  All teams have been ordered to follow a two-week iteration cadence, while members of some teams come from an offshore outsourcing vendor.

4.  A company has found that their main competitor will be Amazon.com.  The release cycle for most of its IT projects is six months, and they know that unless they drastically reduce this, Chapter 11 is not far away.

5.  A startup company realized that unless they validate their assumptions about who the real customers are, and what the real needs of real users are, they have no viable business.  They decide to follow the Lean Startup method by rapidly developing a series of Minimum Viable Products (MVPs) in rapid succession.  Even after the first release of the product, the company must stay ahead of competition and deal with rapid changes in market conditions.

With the vast diversity of organizations and their projects, a cookie-cutter approach (or prescriptive recipe for all types of projects and situations) will not work.  Each agile project developing a product or solution has a unique context: assumptions, situation, team members and their experience and skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.

No_to_straight_jacket_agile

Many agile development teams now have some experience of team-level agile practices using Scrum, XP, Lean, Kanban or Scrumban frameworks.  Some of these organizations have experience with Scrum of Scrums (that is, two to as many as nine Scrum teams working together on a product or solution). These teams and their organizations are now setting their horizons to undertake large-scale agile projects where several (10 to 1,000) teams must collaborate to implement the common vision of a product or a solution.

In the last few years, there has been increasing interest in scaling agile-lean methods beyond individual teams or Scrum of Scrums to programs and portfolios of teams, as well as being able to compose new applications by stitching together a set of services developed by independent teams.  The recent Agile 2014 conference had numerous presentations on the topic of scaling agile.  I attended as many of them as my schedule allowed, and caught much of the rest as recorded sessions.

Many of these sessions raised the issue of ‘which scaling agile framework is best?’ I came away thinking that every large-scale agile project creates a unique situation. To tackle this question, there are really two broad approaches you can take to select the right agile-lean process for your project:

APPROACH #1: Select a well-known, scalable agile framework listed below.

A. Scaled Agile® Framework (SAFe™) by Dean Leffingwell and his associates at Scaled Agile Inc.
B. Large-Scale Scrum (LeSS) by Larman and Vodde
C. Disciplined Agile Delivery (DAD) and Agility at Scale by Scott Ambler and his associates
D. Matrix of Services (MAXOS) by Andy Singleton

If necessary, extend or adapt or customize the framework to suit your unique needs. As you gain experience, inspect and adapt for ongoing refinements and further customization. “Scaling Agile Your Way” does not mean that each new large-scale agile project must develop its own agile processes from scratch.

APPROACH #2:  Develop a customized approach from scratch.

Or, if your project has truly unique needs that cannot be satisfied by any available framework (such as SAFe, LeSS, DAD, MAXOS) even after customization of the framework, you may need to develop a set of new processes from scratch customized to your unique needs, and then sustain and maintain those processes.

In many organizations, not many in-house people have this kind of expertise that would actually work.  Moreover, this approach would be expensive and may not be cost-effective.  As such, this approach to large-scale agile projects should not be undertaken on the ground of ideological purity, but should be based on solid business reasons.

It is important to state what “Scaling Agile Your Way” does not mean.  It does not mean that each team in a program is free to choose and optimize its own agile method, practices, cadence, release duration, metric and reports, etc., without any coordination with and consideration of other teams in the program.  If this were done, although each team may end up optimizing its own way, that may ignore what is good for the higher level program.  Similarly, optimizing at the program level without any regard to the higher portfolio or enterprise level is not “Scaling Agile Your Way”.   Those kinds of decisions (disregarding the system level optimizations and trying to optimize only at a subsystem level) might amount to “Agile my way or highway”, irrespective of Approach # 1 or # 2 described above.  Systems thinking is important for Scaling Agile Your Way.

This blog series is not a tutorial on or an in-depth review of SAFe, LeSS, DAD or MAXOS.  I will provide a brief overview of these frameworks for getting started.  I will then present a set of 25 scaling parameters (organized into 6 scaling aspects) that need to be considered to decide what scaling approach and methods are best suited for your specific situation, and what kind of customization will be needed.

SAFe: SAFe is a popular agile scaling framework for “enterprise-class,” large-scale agile projects.  It has great market momentum going for it, with extensive information available in the public domain, and training/certification programs from the Scaled Agile Academy and its partners.  SAFe is a proven and publically available framework for applying agile-lean practices at scale.  Many agile project lifecycle management tool vendors (such as VersionOne and Rally) support SAFe.  I will cover SAFe’s Sweet Spot, Challenge Zone and Unfit Zone, and give examples of how to customize SAFe for your situation in this blog series.

SAFe is often criticized, rather harshly and often unfairly, as being overly prescriptive and hence not suitable for many large-scale agile projects.  In some situations, SAFe is a good fit (Sweet Spot), while in some other situations, SAFe may be in a “Challenge Zone” where some effort (such as enhancement and customizations) will be needed to overcome those challenges.  But even with that effort, you may be better off using SAFe, compared to developing your own set of agile processes and practices from scratch.  However, in some situations, SAFe may be in an “Unfit Zone,” i.e., it is either not applicable or will not work well.  Full disclosure: I am a certified SAFe Program Consultant (SPC).

MAXOS: A relatively new agile-lean framework called MAXOS allows you to scale a particular type of agile methodology called “Continuous Agile,” where teams release working code several times in a day. In fact, after each change, the code becomes releasable shortly, thanks to automated testing, continuous integration, and developer-centric teams.  All teams continuously integrate their code into an enterprise-wide common code base, with a very large number of automated test sets running continuously in a cloud computing environment.  MAXOS is being used at many leading high-technology companies, such as Google, Amazon, Hubspot, and Edmunds.com.   MAXOS is particularly well-suited for large-scale Software-as-Service (SaaS) for consumer mass markets, and for lean startups (based on Eric Ries’ Lean Startup methodology).  MAXOS offers a radically different approach to scaling agile compared to SAFe.  MAXOS also has its own Sweet Spot, Challenge Zone and Unfit Zone, as I will explain in this blog series.  The Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS are very different.  The contrast between SAFe and MAXOS is breathtaking.   If your competition has started to use MAXOS and you are still using SAFe, your competition couldn’t be happier!  On the other hand, if you insist on using MAXOS in situations where SAFe excels, you would be making a poor decision.  Many practices from MAXOS (such as test automation and continuous integration) can be incorporated within SAFe.

At present, MAXOS doesn’t seem to have formal training and certification programs.  I attended MAXOS presentation by Andy Singleton at the Agile 2014 conference, and have reviewed most of the public information about MAXOS, including the eBook on Continuous Agile method.

LeSS: LeSS is regular Scrum applied to large-scale development.  LeSS is developed by Larman and Vodde.  A key message of Scrum is to avoid a cookbook of defined process. Realize that each team and each product will have to inspect and adapt their own Scrum adoption, which will evolve sprint by sprint. Therefore, the suggestions offered by LeSS are no more than that—suggestions.

DAD: DAD is a process decision framework developed by Scott Ambler and his colleagues.  The DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, enterprise-aware, and scalable.  DAD leverages proven strategies from several sources (Scrum, Lean, XP, Kanban, SAFe, DevOps, Agile Unified Process or AgileUP, Agile Modeling, etc.), providing a decision framework to guide your adoption and tailoring them in a context-driven manner.

Although there are differences among SAFe, LeSS and DAD, those differences are dwarfed by their differences from MAXOS.  For example, while SAFe, LeSS and DAD are predicated on cross-functional teams with a number of meetings required, MAXOS advocates developer-centric, highly empowered teams (developers, not QA, decide to release!), and “management automation” to eliminate many meetings.  As LeSS and DAD are not as popular as SAFe at this time, I will not cover them further in this blog series.

You can use the Agile Scaling Knowledgebase (ASK) decision matrix to access a template for comparing SAFe, DAD, LeSS and other scaling agile frameworks.

SAFe and MAXOS cover a fairly large territory of vastly different types of large-scale agile projects.  Once you understand SAFe and MAXOS, and your own unique situation, you may be better off using one of those (with appropriate customizations as needed), rather than creating one from scratch and sustaining your own custom agile processes (an expensive and risky proposition).

There may be unusual situations where neither SAFe nor MAXOS may be a good fit for a large-scale agile project.  I will cover this topic in Part 3 of this series.  If you believe that your large-scale agile project has unique requirements that render both SAFe and MAXOS totally useless, and you have no choice but to create, maintain and sustain your own custom processes for your large-scale agile project, please let us know.  I would be very interested to know about your unique situation and what led you to prefer custom processes from scratch.

Customization approach:  Scrum at Scale (meta)-framework developed by Jeff Sutherland and Alex Brown starts with the basic premise that Scrum is an object-oriented framework.  Scrum at Scale framework is aimed at extending Scrum for large-scale agile projects, while retaining Scrum’s object-oriented architecture.  Scrum at Scale framework, along with its pattern library, are aimed at allowing agile projects to develop their own unique and customized methods for scaling Scrum to large-scale projects.  In Part 4 of this blog series, I will explain salient aspects of Scrum at Scale, and how its object-oriented approach may be used for customizing SAFe for your own unique needs.

Agile Scaling Aspects and Parameters:  Any large-scale agile project needs to consider a number of scaling parameters in order to decide which scaling framework would be most appropriate for its unique needs, or whether it needs a totally custom set of agile processes.  Table 1-4 shows a set of 25 scaling parameters, grouped into 6 scaling aspects:

1.  Teams

2.  Customers/Users

3.  Agile Methods and Environments

4.  Product/Solution

5.  Complexity

6.  Value Chain

The list is a fairly comprehensive, but by no means, exhaustive.  If some of the 25 parameters are not appropriate for your large-scale agile project, you need not consider those parameters.  If any scaling aspect or parameter is missing from the list, please let me know.  Each scaling parameter may take one more values from range of options. For example, “Number of teams” parameter associated with “Teams” scaling aspect has a value in the range of 10 to 1,000.  “Composition of teams” parameter associated with “Teams” scaling aspect can select a value in its range of options: Developer-Centric, Somewhat Cross-Functional with Guest Experts, or Fully Cross-Functional.  Multiple options can also be selected as long as they are not contradictory.  For “Composition of teams” parameter, only 1 out of 3 possible values can be selected.  On the other hand, for “Agile method of choice and required tool support” scaling parameter of “Agile Methods and Environment” scaling aspect (see Table 2), multiple choices are possible, such as Scrum, Scrumban, and Scrum+Lean.

Many of 25 scaling parameters are considered by ASK, DAD and Scrum at Scale frameworks.  Tables 1-4 use the following legend to indicate which scaling parameter is covered by ASK, DAD or Scrum at Scale.

  • A:  ASK
  • S: Scrum at Scale
  • D: DAD/Agility at Scale

Note that some of the 25 scaling parameters are not covered by any of these frameworks.  For example, “# 5. Composition of Teams: Fully Cross-Functional” scaling parameter is covered by all A (ASK), S (Scrum at Scale) and D (DAD); while “# 5. Composition of Teams: Developer-Centric” scaling parameter is not covered by ASK, Scrum at Scale or DAD.

Table1b

Table2b

Table3b

Table4

As you review the information in Tables 1-4, you will realize that the “scaling agile” space is complex and very rich with many choices.  Each organization or a large-scale project is likely to select a different combination of these scaling parameters as relevant; moreover, the value or range of values for each scaling parameter for a project or an organization is likely to be unique.

What agile-lean scaling approach are you considering: SAFe, LeSS, DAD, MAXOS, or something else?   What are your customization needs, and does your selected approach fit well with those needs?  I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com). I’m also on Twitter@smthatte.

Part 2: Scaling Agile Your Way – SAFe vs. MAXOS

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

Part 4Scaling Agile Your Way – How to develop and implement your custom approach

Categories: Companies

Design Thinking für Product Owner – Teil 3: Der Design-Thinking-Raum

Scrum 4 You - Mon, 09/08/2014 - 07:30

Product Owner sind vielen und vielem verpflichtet: Dem Kunden, dem Nutzer, dem Entwicklungsteam und der Profitabilität. In diesem Spannungsfeld auf Knopfdruck kreativ zu sein, um neue nützliche und gewinnbringende Produktideen zu schmieden, gelingt kaum einem Menschen.

Design Thinking will radikale, disruptive Neuerungen kreieren, Ideen und Potentiale sollen sich entfalten, daher benötigen Menschen und Prozess eine andere Umgebung.

Der Ort für Design Thinking

Die Anforderungen an den Ort für erfolgreiches Design Thinking sind vielfältig: Ein großer Raum, eine Mischung aus Werkstatt und Wohnzimmer, mobile Einrichtungsgegenstände, große Fenster für viel Tageslicht und ein angenehmes Raumklima. Alle Wände dürfen genutzt werden, Bastelmaterial, Papier, Stifte und Getränke sind reichlich vorhanden.

Einige Studien besagen, dass die besten Ideen außerhalb der Arbeitsstätte und außerhalb der Arbeitszeit entstehen. Daher verlassen wir die angestammten Räume. Der neue Arbeitsraum ist lediglich ein Container, um die Erfahrungen, die wir mit dem Nutzer machen, zu bündeln und zu verarbeiten. Es ist der Boden, auf dem wir Ideen wachsen lassen und die kritischen Aspekte unserer Ideen in Prototypen überführen, die erneut am Nutzer getestet werden.

Im Laufe des Design-Thinking-Prozesses wird dieser Raum also gefüllt, denn Design Thinking erzeugt viele physische Ergebnisse: Mitgebrachte Artefakte, Dekorationen und natürlich Hunderte von Haftnotizen, die an Wänden und Fenstern kleben und in immer wieder neuen Sortierungen die gesammelten Erkenntnisse verdichten, bis Schmerzen und Freuden der Zielgruppe wie in einem offenen Buch vor dem Design-Thinking-Team liegen. Gearbeitet wird dabei grundsätzlich im Stehen, auch dazu gibt es Studien, die die positiven Effekte belegen. Gesessen kann in den Pausen werden – diese gibt es reichlich, da im Design Thinking mit striktem Timeboxing gearbeitet wird, um viele kurze Phasen höchster Konzentration zu erreichen.

Mobiles Mobiliar hilft dabei, den Raum jederzeit passend umzuformen: Whiteboards, Stehtische, Sofas, Regale … all dies lässt sich mit Rollen ausstatten, so dass die Sitzecke im nächsten Moment zum Prototyp eines Bahnwagens werden kann oder Arbeitsergebnisse an einer Pinnwand für den späteren Gebrauch zur Seite geschoben werden können.

Besonders wichtig ist eine breite Angebotspalette an Prototyping-Material, denn Ideen werden im Design Thinking umgehend testbar gestaltet, um sofort Nutzer-Feedback zu sammeln. Eine Anregung für Materialien finden Sie in der Checkliste am Ende dieser Seite.

Für ein konzentriertes Arbeiten ist eine ruhige Atmosphäre angenehm, dennoch soll Design Thinking nicht still sein. Lachen und klatschen ist eindeutig erwünscht, mit etwas Musik im Hintergrund lässt sich die Stimmung gut steuern.

Solch ein Raum ist keineswegs ein Garant für gute Ideen, wirkt aber in der Regel beschleunigend und unterstützend. Es gibt bereits einige große Konzerne, die an ausgewählten Standorten solche Räume installiert haben (z.B. Telekom & SAP).

Frei-Räume für Design Thinking

Um den angedeuteten Raum mit einer kreativen Teamkultur füllen zu können, bedarf es einiger weiterer Zutaten:

Zeit
Design Thinking wird oft als “langsam” empfunden. Besonders im Scrum-Umfeld, in dem Kunden schnelle und regelmäßige Lieferungen gewohnt sind, ist es schwierig, das Verständnis für den Zeitaufwand bei einer undefinierten Lieferung zu rechtfertigen. Es ist aber sehr wichtig, gerade in der Anfangsphase des Design-Thinking-Prozesses genügend Zeit für die “Entdeckung” zu haben, um auch Techniken wie “Cultural Probes”, “Diaries” & “Observation” einzusetzen. 
Ist die Zeit knapp, ist der Design Thinker versucht, lediglich ein paar Interviews zu führen und verpasst womöglich die interessantesten Einsichten über den Nutzer.

Verhalten und Regeln
Es gibt ein paar Vorgaben, um das Zusammenwirken zu vereinfachen. Es ist wichtig, dass die Teammitglieder sich an diese Regeln halten, ggf. werden sie vom Design-Thinking-Coach darauf hingewiesen. Es ist sinnvoll, diese Regeln groß ausgedruckt an verschiedenen Stellen im Raum aufzuhängen:

  • Arbeite visuell
  • Nur einer spricht
  • Fördere verrückte Ideen
  • Stelle Kritik zurück
  • Quantität ist wichtig
  • Bleib beim Thema
  • Baue auf den Ideen anderer auf
Einfach anfangen …

Zugegeben, die Ansprüche an den Raum für erfolgreiches Design Thinking sind hoch. 
Aber der physische Ort und der Freiraum sind gleich nach dem Design-Thinking-Team der wichtigste Erfolgsfaktor.
Suchen Sie nicht nach Gründen, warum es nicht geht. Suchen Sie lieber Wege, so viel wie möglich davon wirklich zu machen:

Verlassen Sie den angestammten Arbeitsort, gehen Sie mit Product Owner und Design-Thinking-Coach zum Kunden und treffen Sie Ihre Nutzer. Okkupieren Sie für zwei Tage einen geräumigen Eingangsbereich oder eine Lagerhalle mit viel Licht. Stellen Sie Stehtische auf und kleben Sie Packpapier an die Wände (Haftnotizen kleben gut daran). Beziehen Sie die Menschen, die fragend gucken, in Ihre Arbeit ein. Stellen Sie die Fragen und lernen Sie!

Der PO und der Kunde profitieren am Ende am meisten: Durch den Aufwand zu Beginn eines Projekts oder Release (je nach Komplexität 2 Tage bis 2 Wochen) sind die Bedürfnisse des Nutzers klar und die Lösungsansätze bereits vom Nutzer getestet. Das spart viel Zeit am Ende der Umsetzungsphase mit Scrum, da weniger nachgebessert werden muss und der Gedanke an den Nutzer durchgehend in den Köpfen präsent ist.

Checkliste für einen passenden Design-Thinking-Raum
  • Location: Nahe den Orten, an denen man die relevanten Nutzer treffen kann
  • Raum: Genügend Platz für alle Teilnehmer, Arbeitsmaterialien, Aktivierungs-Spiele (ab 8qm pro Person, gerne mehr)
  • Beleuchtung: Hell! Große Fenster und viel Tageslicht
  • Luft: Gute Belüftung, Vorsicht bei Klimaanlagen: Nicht zu warm und trocken einstellen (20°-22°C genügt beim Stehen und in Bewegung)
  • Akustik: Ruhig, ohne Echo
  • Tische und Stühle: Stehtische (große Arbeitstische) und Barhocker/Stehstühle beflügeln die Konzentration
  • Pinnwände, Whiteboards und Flipcharts: Viele davon! Leicht, mobil und magnetisch
  • Nadeln & Magnete: Für die Boards
  • TimeTimer: Zum visualisieren der Timebox
  • Gong oder Zimbeln: Zum “Zusammenrufen”
  • Laptop & Internet: Für Recherchen
  • Standard Material:
    • Papiere (A4 & A3 in weiß, A4 bunt & Karton, große Rollen Packpapier)
    • Haftnotizen (so groß wie möglich, unterschiedliche Größen, mindestens 5 verschiedene Farben)
    • Stifte (Board & Flipchart Marker, Permanent-Marker, Filzstifte in verschiedenen Farben, Bleistift) Stifte unbedingt vorher testen und Schlechte aussortieren
    • Scheren, Klebeband (Malerkrepp), Locher, Klammeraffe
    • Küchenrolle
  • Prototyping Material:
    • Zeitungen und Magazine mit vielen Bildern zum ausschneiden
    • Pappkartons
    • Klebe (Flüssig- & Heißkleber, Klebebänder von der Rolle in transparent & farbig)
    • LEGO® oder DUPLO®
    • Knete
    • Pfeifenputzer
    • Geschenkbänder
    • Strohhalme
    • Stoffreste, Bettlaken
    • Verkleidungsmaterial (Hüten, Perücken, Brillen, Schürzen etc.)
    • Dicke Aluminiumfolie
    • _______________________
    • _______________________
    • _______________________

Da nun im Raum alles klar ist, sehen wir uns im nächsten Teil  den Design-Thinking-Prozess an. Ich freue mich über Fragen, Anregungen und Diskussionen!

Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?

Design Thinking für Product Owner – Teil 2: Das Design-Thinking-Team

Related posts:

  1. Produktfindung mit Design Thinking
  2. Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?
  3. Design Thinking für Product Owner – Teil 2: Das Design-Thinking-Team

Categories: Blogs

Can a Project Be Beautiful?

Agile Tools - Tom Perry - Sun, 09/07/2014 - 23:07

What would make a project beautiful? What sort of aesthetic would we seek? Would would make a beautiful plan? What would make a beautiful backlog? What would make a beautiful team? What would make a beautiful delivery?

I imagine it might be different for everyone…

The Plan

For me, a beautiful plan would be something that covers a wall of a team or war room. It would have requirements, wireframes, architectures, acceptance criteria, impediments.

mess

 

 

 

 

 

It would tell a graphic story of the evolution of the project over time. It would be a graphic history in multiple dimensions, worthy of Edward Tufte. But it would not be perfect. It would reflect rough edges, rapid sketching, mistakes, blind alleys, rough annotations everywhere.

istock_000019366898small

 

 

 

 

 

 

 

 

It would also reflect the growth and improvement of the team. Items from retrospectives would be incorporated into the timeline. There would be different ways that the team measured their own performance. It would be a glorious mess!

OLYMPUS DIGITAL CAMERA

 

 

 

 

 

 

 

The Backlog

A beautiful backlog would be on it’s own wall. It would reflect dialog with the customer, questions from the team, user profiles and scenarios.

tumblr_ly5c4tDfnr1qfg8uu

 

 

 

 

 

 

 

 

 

It would be shaped like an inverted pyramid, with rich detail at the top, tapering down to sparse sets of one line ideas and proposals below. It would have color (LOTS of color) and use different shapes to indicate stories, epics, features, etc.

writing-on-wall

 

 

 

 

 

 

 

The Team

A beautiful team is tight. The team works physically closely together, eliminating all barriers, focusing on collaborative activity over solo activity. They work together, they eat together, they respect each other. They share roles and responsibilities promiscuously.

teamroom

 

 

 

 

 

 

 

 

 

They pair, they mob, they swarm!

8666.pp-Team-Room_4C3230AF

 

 

 

 

 

 

 

 

 

 The Delivery

A beautiful delivery is smooth and effortless: friction free. It happens on demand – with the ease of a thought. Work flows through to production almost inevitably. It’s a downhill slide, not a grind uphill.

Free-Mattress-Delivery-Farmington-Hills

 

 

 

 

 

 

 

 

 

 

 

What does a beautiful project look like to you?


Filed under: Agile, Process, Teams Tagged: beauty, Collaboration, efficient, great projects, Process, projects
Categories: Blogs

When Impediment Management Won’t Work

Agile Tools - Tom Perry - Sun, 09/07/2014 - 05:25

IMG_2191

 

 

 

 

 

 

 

 

 

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Stating the desired change is too risky
  • Action can’t be taken because projects are too important
  • Only certain people can take action

I’m sure this could be a much longer list. The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.


Filed under: Agile, impediment, risk Tagged: culture, Impediments, mismatch, risk
Categories: Blogs

Project Management with Kanban Class Curriculum

David J. Anderson & Associates - Sun, 09/07/2014 - 02:49

This is the first look at one of our new role-based training classes. This is specifically targeted at project managers and related roles such as service delivery manager, program manager, and anyone with responsibility for delivering projects, product releases and similar batches of packaged creative or knowledge work. This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Project Management with Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.

read more

Categories: Companies

Kanban Coaching Professional Masterclass Curriculum

David J. Anderson & Associates - Sat, 09/06/2014 - 04:10

For the first time, I'm posting our curriculum for the Kanban Coaching Professional Masterclass. This new curriculum is scoped within the Modern Management Framework and takes effect in Masterclasses offered after November 1st 2014.

read more

Categories: Companies

Software Developers Are Storywriters

WALL.E - a Pixar MovieOften ( always? ) developers are perceived ( even by themselves !) as translators of  requirements into code. The art and craftsmanship of developers is recognised in respect with the "skilfulness" of their translation : Clean Code,  Test Coverage,  Test Driven Development , Design Driven Development, and so on. But developers are not only translators,  they are the real writers of  the software product story they are about to code . Agile User Stories,  Wall-E  and T-StoryOne of Agile's favorite artefacts is the User Story . Every member of an Agile Team works on User Stories. Well..hmmm? Do they ? Is it really so? How many "User Stories" like that did you see :
"As the e-B3-threadComputing I need to call the GarbageCollector in order to improve my memory management performance with 30%"
WOW ! When I first read a story like that I thought : "Great , this is a product about robots and this user story is about E-VE falling in love with WALL-E". As Pixar created "Toy Story",  Agile Software Development invented the T-Story ( as "Technical" , of course ) . Some time after meeting the first T-Story of my life I became confused.... Because there were many of them... in all software products, regardless of the company's business that develops that software.Now, that's interesting,  how come all humans in the world need exclusively products about wall-E , E-Ve and their cousins? How that did happen?! 
 Refactoring the Mindset My little idea is that it happened because organisations and companies treated software developers as "translation automates" of  "functional requirements" in programming languages.  The outcome of this mindset is a target product that is about automates . And the first version of the product risks high to leave business people speechless on a puzzle question : "How the hell did they build such an absurd product "?  Well, business people, they built a robotic product that highly make little sense from an user perspective because we might have treated developers as producers of "abstractions".If we want to build products that make sense for humans, there is one think to refactor : the "automate translation" mindset. And grow a software development culture that acknowledges that software products are stories about real people .
Software Products Are Stories About HumansThe "User" side of "User Story" is the key of a great software. Gojko Adzic says that un-experienced teams create T(ethnical) -stories instead of user stories. I think is more than experience , is a question of mind set. Just shift your mind from the T-Story to a real person next to you that experiences the service you're about to implement and think about how does that feel differently.  The mind shift from technical layers and composants to small pieces of code that are meaningful from a user experience perspective is hard. Nevertheless , the only way to build shippable products at the end of each sprint is to stick to this rule : every user story is a new - enhanced- experience for the user. How to do that ? If you like methods, Gojko defined the Hamburger Method . It's my favorite.  Beyond the "How to" , though, the secret of succeeding is the way we think about the software protect.  Because it's not a collection of code,  it tells a story where human users are heroes.This is  why I strongly believe software developers are writers of stories co-created together with Product Owners, Business People and whoever needs to hang around. Agile people say teams are more performant when they are collocated. If this is true it is because the fireplace where products stories are told needs to stay vivid. The software code embeds a story. Would you like the story your code tell to be awesome ?


Categories: Blogs

Hello managers, coaches, and other change agents

Henrik Kniberg's blog - Fri, 09/05/2014 - 16:28
Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work read more »
Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.