„Aber ich habe ja so viele Dinge, die ich jeden Tag erledigen muss – da kann ich doch gar nicht ständig einen Zettel schreiben?“ So oder so ähnlich lauteten in einem Projekt die Kommentare, als wir begannen, ein Taskboard auf Management-Level einzuführen. Ich kann das gut nachvollziehen, meine Taskliste von heute sieht so aus:
- Kunde: Backlog mit N.N
- Kunde: Meetings mit N.N. und O.O.
- Kunde: Daily Scrum
- Kunde: JIRA Training – Setup
- Kunde: Arbeit an der Darstellung zur Meeting-Struktur
- Marketing: Review Pressemitteilung Agile Bodensee
- Blog: Brauchen wir noch Daily Standups?
- Blog: Die Generation Y – “Wir wollen unser Leben genießen”
- JIRA Playbook an alle geschickt
- Travel: Flüge für die nächsten drei Wochen gebucht
- Blog: Das Taskboard auf Management Ebene – Warum eigentlich ein Taskboard?
- Intern: HR-Backlog und Unklarheiten besprochen
- Sales: einen Kunden angerufen, und um Feedback gebeten
- Travel: Ersatzreisedokument am Flughafen Berlin besorgt
- Familie: Meine Frau vom Flughafen abholen
Soll ich da wirklich jedes Mal einen Zettel schreiben oder meine kleine 1h-Aufgabe in einem Tool wie JIRA oder Trello ablegen? Ihr könnt euch denken, dass ich vor mich hin schmunzle. Denn während ich das hier schreibe, habe ich ja gerade die Einträge für ein Taskboard erstellt. Das nun auf Klebezettel zu schreiben, oder vielleicht sogar in ein Tool wie JIRA einzutragen, ist sicher genauso möglich. Es ist ein wenig komplizierter, aber nicht sehr. Wer mehr dazu wissen will, wie man das effizient macht, dem sei Personal Kanban empfohlen. Und doch: Management-Teams wehren sich zunächst, diese wenigen Einträge zu machen. Also mache ich sie in meiner Rolle als ScrumMaster in der ersten Woche für das Management-Team. Auf diese Weise sehen sie auch, wie viele Dinge sie erledigt bekommen und wie viele Dinge sie abseits des Üblichen noch so machen.
Ist Euch das auch schon mal aufgefallen? Die meisten Manager machen unendlich viele ad-hoc-Aufgaben, sie stecken zu tief im Tagesgeschäft. Ständige Störungen, permanente Meetings und sie werden von E-Mails überflutet. Konzeptionelles Arbeiten oder gar Führen ist fast nicht möglich. Ich habe schon öfter geschrieben, dass Henry Mintzberg das schon vor Jahren festgestellt hatte:
“Folklore: The manager is a reflective, systematic planner. The evidence of this issue is overwhelming, but not a shred of it supports this statement.
Fact: Study after study has shown that managers work at an unrelenting pace, that their activities are characterized by brevity, variety, and discontinuity, and that they are strongly oriented to action and dislike reflective activities. Consider this evidence: Half the activities engaged in by the five chief executives of my study lasted less than nine minutes, and only 10% exceeded one hour. A study of 56 U.S. foremen found that they averaged 583 activities per eight-hour shift, an average of 1 every 48 seconds. The work pace for both chief executives and foremen was unrelenting. The chief executives met a steady stream of callers and mail from the moment they arrived in the morning until they left in the evening. Coffee breaks and lunches were inevitably work related, and ever-present subordinates seemed to usurp any free moment.“
Trotzdem es ist etwas anderes, das täglich in der Praxis zu sehen. Management-Teams haben also nicht wirklich Zeit, das große Ganze zu sehen. Sie kommen gar nicht dazu, sich um die vielen wichtigen Aspekte zu kümmern, denn sie sind total beschäftigt. Gesehen haben wir ein ähnliches Phänomen in der Vergangenheit bereits bei skalierten Scrum-Implementierungen. Dort mit den Product Ownern konzeptionell zu arbeiten, in Ruhe ein Backlog aufzubauen, vielleicht zwei Tage intensiv daran arbeiten, eine wirklich ausgearbeitete Story Map zu erstellen – das war aufgrund der vielen Störungen gar nicht möglich. In diesen Kontexten hatten wir aber die Schwierigkeiten auf die Komplexität der Produkte geschoben.
Was mir jetzt als ScrumMaster eines Management-Teams auffällt: Es fehlt die Priorisierung. Alles scheint gleich wichtig, als wäre es in einem größeren Unternehmen nicht auch möglich, sich zu fokussieren. Gleichzeitig ist das nicht so viel anders als das, was die Arbeit von vielen Entwicklungsteams in der Vergangenheit gezeigt hat.
Wie kann ich meinem Management-Team dabei helfen: Mit einem Taskboard. Es macht transparent, wie viele Dinge erledigt werden müssen. Damit kann man daran arbeiten, die wirklich wichtigen Dinge zu tun und sich gegenseitig zu helfen. Jetzt brauche ich nur noch Geduld – wie bei allen Teams dauert es ein wenig, bis die Idee des Taskboards angenommen wird.
Henry Mintzberg: The Manager’s Job: Folklore and Fact, HARVARD BUSINESS REVIEW: March/April 1990, p. 163 – 176
- 5 Minutes on Scrum | Transparency
- Prioritäten | Product Owners Tools
- Product Backlog | Templates | Scrum Tools
So you want your organization to change? Then you just might need a change artist. What is a change artist? A change artist is someone who leads change in an organization by sharing example and by influence using visualization. That is to say, a change artist will not mandate or coerce in order to introduce change, but rather they will begin with themselves and demonstrate their own change – thereby providing the example and the potential motivation for others to seek similar change in themselves. The visualizations help to share the story – you need the artist.
I think that people who are able to express their ideas through pictures are particularly well suited to creating the kinds of compelling visualizations that help convey what change might look like. They don’t have to be technically competent as an artist. Just good enough to draw stick figures and tell a story. Its really not that hard once you stop worrying about what people think.
Can we create people like this? Or are they born to it? I don’t think the hard part is the art. Anybody can do that. It’s how they approach change that matters most.
Perhaps there are organizations that would be more receptive to change initiatives that aggressively use visualization techniques. I can’t help imagine that visualization can add a compelling element to any transition engagement. I’ve not see much evidence of that sort of approach on agile transition engagements that I’ve been on. I’ve seen the power of what a simple drawing can do to draw people together and generate discussion. Using some sharpies and some butcher paper I can start a conversation that will continue long after I’m gone. I’ve seen it happen. There isn’t a text document in the world that can compete with a good picture. I’m not talking about Visio diagrams either. There is a quality to the hand drawn diagram that invites people to engage in a way that no sterile electronic diagram ever will. I’ve held two versions of the same diagram, one hand drawn and one electronic, side by side and the preference is almost always unanimous – the hand drawn version wins. I think the magic lies somewhere in the the errors and mistakes in the drawing. They must serve to remind us that we are human. Perfection isn’t necessary, and in fact may be counterproductive.
That’s who I want to help me change the world. Combine the passion for change and the art and I’ll give you a change artist.
Filed under: Agile, Coaching Tagged: Agile, artist, change, change artist, Transition
Some sample pics below:
- Our target date is March 2015, the alternative is June, 2015.
- The open space will be held on a Friday and Saturday.
- We want to hold a Product Owner Masterclass, one or two days before the Open Space event.
- The audience is experienced Product Owners, Agile Product Managers and Lean Startup Practitioners. This is by practitioners for practitioners, not for beginners.
- The event is not profit oriented.
- We are going to get together on skype roughly once every to two weeks to take the event forward.
We have created a backlog to organize our work: Our first objective is the find a leader for the MasterClass, reserve some dates, and start working on the website. After that, priority will be the venue...
Several other people expressed an interest in helping to organize, we will welcome them as they confirm their participation :-)!
Are you interested in participating (or even helping out?) Join our google group to stay informed!
I have a team of 11 developers and 3 Product Owners. Their ideas about how to organize the team are all over the place. Some want to do 1 week sprints. Others want one month sprints. And we pull in resources people so we can get the right velocity to meet our deadlines. This seems like a mess. How much should I let my beginning team self-organize? -- recently asked on a Scrum Discussion Forum. Modifying a complex technique before you have mastered it is a failure pattern. So when you are just getting started, try to get as close to Scrum by the book as you can, without obsessing over it... much. I call this Pretty Good Scrum(tm). ;-)
Yes the team self-organizes... and the Scrum Master is charged with teaching the team and helping them improve. When the team is just getting started, it should follow the lead the of Scrum Master, and the Scrum Master should stay close to the book. As they get better, they'll be better able to inspect and adapt themselves.
Successful teams learn quickly. How do you learn quickly? Short answer: Do short sprints. More in a moment.
Remember, never hit anyone with the book! The rules of Scrum are there to help you, not to threaten or punish people. Be sure you can answer why the rule of Scrum is a good answer. Treat everything as an experiment or learning exercise, so they have the security of knowing they can change things later. That's what retrospectives are for.
It will probably take you three or four sprints to get to Pretty Good Scrum. That's why I recommend one week sprints to start. Why learn in four months what you can learn in 4 weeks?
If I were confronted with the situation above, I would ask five questions and help the team(s) and PO(s) find answers that stay within the constraints defined by Scrum.
1. How big is a Scrum team? 7+/-2. To stay in those bounds, you need two teams. Ask your teams how they want divide themselves, respecting that constraint. By giving them the problem, they become responsible for the solution, so they won't come to you anymore with "yes, but..."! If they talk about limited specialists, ask them how to resolve the problem.
2. How many Product Owners does a Scrum Team have? One, though you might also have a Chief Product Owner role in the case of multiple teams. Ask your product owners how they want to split up their work. And yes, the PO is responsible for the Vision. Do they have one, can they communicate it? Is it shared and supported by the Team and other stakeholders?
3. How long is the Sprint? Normally this is negotiated between PO and Team. And... as Scrum Master you are responsible for the process, which gives you the right to intervene to improve the team. Shorter sprints accelerate learning. So I would suggest starting with a couple of one week sprints. Be sure to get your team to agree to this. I have also had great experiences doing 2 or 3 sprints at 59 minutes each (ask me more about this if you're interested).
4. Who estimates and decides how much work can be accomplished in a sprint? The team. Not the math, not the PO, not the stakeholders and not management. Have them estimate the work, and don't let them take on more than they can chew. Think of highways at rush hour if you want to know why this is a good idea.
5. Whose job is it to make sure that wish and reality are in harmony with each other? The Product Owner. If the desired scope does not match up with the team's reasonable forecast of what they can accomplish by the desired release date (aka deadline), whose job is it to fix the problem? The PO. Given your context, conversations about reducing scope and the impact of product-level multitasking on ROI might be quite fruitful!
Back to the original question: "How much do you let a new team self organize?" The answer is "quite a lot!" The trick is setting constraints that cause people to come up with right answers.
Es gibt sie immer – Menschen, mit denen man nicht gut klarkommt. Seien es Kollegen, Kunden, Berater, Bekannte innerhalb des eigenen Freundeskreises und des öfteren sogar Familienmitglieder. Sie alle sind Teil unterschiedlicher Systeme, in denen man sich bewegt. Jedes Mal, wenn ich eine jener Personen antreffe, merke ich sofort, wie mein Blutdruck ansteigt und ich mich bemühen muss, freundlich und geduldig zu bleiben. Nach jahrelanger Beratertätigkeit, bei der ich schon die unterschiedlichsten Menschentypen angetroffen habe, meine ich nun, ein paar Möglichkeiten gefunden zu haben, um in der Anwesenheit eines (für mich) nervigen Menschen einen kühlen Kopf zu bewahren. Hier meine fünf persönlichen Favourites:
- Durch Beobachtung herausfinden, was es ist, das mich nervt. Sei es eine gemeinsame Historie, Handbewegungen, Dialekt, Körperhaltung etc. Egal – der Fantasie sind hier keine Grenzen gesetzt. Dann sollte man sich selbst fragen, weshalb diese Aspekte einen nerven. Es könnte ja sein, dass man Opfer des Resonanzgesetzes geworden ist.
- Positives Hinterfragen. Was schätzen gemeinsame Bekannte an dieser Person? Welche Aspekte würden dir fehlen, wenn diese Person nicht mehr da wäre? Was müsstest du an Rollen in eurem System übernehmen? Würden Aufgaben auf dich übergehen? Man kann sich auch absurde Fragen stellen wie: „Wenn ich mich in diese Person verlieben müsste, welche Aspekte wären es, die mich anziehen würden?“
- Man könnte versuchen, eine Veränderung im Verhalten der anderen Person herbeizuführen. Dies kann man erreichen, indem man positives Verhalten durch Feedback hervorhebt und bestärkt. Meine Erfahrung ist, dass kontinuierliches Feedback über einen längeren Zeitraum einen wirklichen Unterschied macht.
- Offenlegen. Wie wichtig dieser Aspekt ist, hat mich meine Coachingausbildung gelehrt. Hier ist essenziell, dass man ehrlich ist und beim Feedback bei sich selbst anfängt. Richtig wäre „Liebe Caro, ich habe manchmal das Gefühl, dass wir an einander vorbeireden. Oder “Liebe Caro, manchmal scheint es mir, als würden jene Punkte, die ich anmerke, bei dir nicht das Gehör bekommen, das sie meines Erachtens nach bekommen sollten.“ Zu vermeiden sind Floskeln wie „Das ist so“ oder Worte wie „immer“. Denn das stimmt ja nicht – erstens gibt es immer Ausnahmen und zweitens ist es eine persönliche Meinung. Hier ist es auch wichtig, auf die Kultur zu achten – während man in Österreich eher von der Maschekseite kommen würde, geht es in Deutschland zum Beispiel direkter zu.
- Nach der Offenlegung die Meinung des Gegenübers abholen: „Siehst du das genauso?“ Und anschließend “was können wir tun, um die aktuelle Situation zu verändern?”
Falls keiner der genannten Punkte funktioniert, würde ich empfehlen, einen Systemischen Business Coach aufzusuchen und das Thema mit ihm durchzuackern.
Mit welcher der fünf Optionen hast du schon Erfahrungen gesammelt? Welchen sechsten Tipp würdest du mir raten, in mein Repertoire aufzunehmen?
- Bin ich am Arbeitsplatz zufrieden?
- Erinnerung: Scrum Breakfast diesen Samstag im Quadro!
- Feedback geben können oder warum auch ein alter Hut gut aussehen kann
“Organizations must shift away from repetitive-function hierarchies with rules and enforcement and walls. Instead, we must migrate rapidly to becoming a global ‘team of teams’ that comes together in whatever combination necessary to add the greatest value to the changes underway.” – Bill Drayton
It’s easy to despair that people can not see social structures as anything other than dominance hierarchies. I suppose that makes sense given our primate origins. In college, I spent hundreds of hours observing chimpanzees at the local zoo as part of a research project. It doesn’t take very long to understand the hierarchy within a small colony of apes. The dominant ape spends a significant portion of this time strutting around making sure everyone knows he’s the boss. He uses every tool in the book, from the brutish power of dominance displays, all the way to the subtle selection of who gets to groom him first. He’s the big man on top.
However, the longer you watch, the more you start to detect other hierarchies within the primate social system. Female chimps have their own sub hierarchy that is just as much a power game as that of the dominant male. Within a very short time you are seeing different types of social hierarchy all over the place. I found myself in awe of the number and complexity of the hierarchies that chimpanzees display. I would maintain that the hierarchies and power games played by chimps rivals anything we have in even the most vicious office politics.
Of course, maybe the hierarchy is in the eye of the beholder. Perhaps we humans are wired to categorize things according to certain patterns. Maybe we are just inclined to see everything in terms of hierarchies as some sort of side effect of the way our perceptual systems are set up. I imagine there is some of that at work here. After all, as primates we have been fine tuning our hierarchical behavior for millennia, so it would be no surprise if we tend to see them everywhere we look.
That notion, that hierarchy is a sort of built in default, is a pretty depressing idea if, like me, you aren’t all that fond of hierarchies. There is no doubt that hierarchies have their advantages, but they have disadvantages too. Look how well the hierarchy has worked out for the Chimpanzees. They are well on their way toward extinction, so you could argue that whatever social strategy they are using, it’s not contributing sufficiently to help ensure their survival.
“Male chimpanzees have an extraordinarily strong drive for dominance. They’re constantly jockeying for position.” – Frans de Waal
It may be that because the chimpanzee is so geared toward hierarchy they are unable to utilize other social structures that would allow them to adapt to their changing environment. Perhaps it is their inability to change their behavior that spells their doom. On the one hand, blame the human for killing them. On the other, recognize that this is an adaptive challenge to which the chimpanzee has not found a winning strategy to counter.
Fortunately, humans appear to be capable of a bit more flexibility when it comes to our social and organizational structure. That is, while we still lean strongly toward the hierarchy (call it the default if you will), we seem to be capable of using other ways of organizing ourselves when the need arises.
That’s a good thing, because whether you are a business, or a society, we face a number of challenges as well. Recently a friend introduced me to Ashby’s Law of Requisite Variety,
If a system is to be stable the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled. Ashby states the Law as “variety can destroy variety”
In a nutshell, when a system faces a challenge, the complexity of that system must be equal to the complexity of the threat in order for the challenged system to survive. Let’s take that back to hierarchy now. Hierarchies consolidate decision making and rely on decisions made by the guy at the top. This helps to simplify the number of responses, which can be useful, but may not be the most adaptive strategy when under threat. In a complex environment, a hierarchy is a rather simplistic structure to use. It doesn’t have the requisite variety required to cope with a complex environment where challenges can arise in many different forms. fortunately, nature has provided us with many different models of social organization to choose from.
In a peer network, no one is officially in charge. It doesn’t have a command hierarchy. It doesn’t have a boss. So, all the decisions are somehow made collectively. The control of the system is in the hands of everyone who is a part of it. – Steven Johnson
Take insects, for example, they use a very different structure often described as a swarm. The swarm does not rely on a single individual or a subset of individuals to determine its response to a given challenge. This means that the swarm can use all of the members of its population to dynamically respond to a challenge. This leads to combinatorial explosion of different alternatives, which gives the swarm a huge arsenal of complex responses. It’s probably worth noting that on an evolutionary scale, the insects have been pretty successful using this strategy (and there are those who would argue they are the most likely to win).
Of course people can use these strategies too. Swarming and other social models are much more rarely used by people, but there are examples. Wikipedia is a great example of a swarm where there is no top down direction. Some organizations, like AA are also good examples. While there are not a lot of examples to choose from, with the increasing complexity of our social and business environments one might wonder if we may see an increasing diversity of swarms and other alternative social structures as a result.
Time will tell. I think the recent evolution of various and sundry Agile methods may be a hint that the underlying social structures are broken, and that people see a need for alternative structures to hierarchy in order to meet the challenges of today’s ever more complex challenges. If that is the case, then I expect to see many more of these Agile methods and frameworks arising in the not too distant future.
Filed under: Agile, Process, Swarming, Teams Tagged: Ashby, Behavior, chimpanzees, constellation, dominance, hierarchy, power, swarm, Swarming, variability, variety
If you were to draw a diagram of the entire product development process from start to finish, what would you start with? If you are like me, you’d probably start with the customer, or maybe sales. Then you’d probably pass the idea along to product management and onward to development. Last, but not least, the product would make its way to operations for deployment in production.
It’s pretty straightforward, front to back, end-to-end. Everybody knows how it works. And if we are going to try to improve this process, where do you think we typically start?
At the front? In sales? No.
At the back? With operations? No. Not there either.
Right smack dab in the middle? BINGO! Development always gets the love first.
Now what kind of lunacy is that? Now I’ve been part of a process improvement effort or two, so naturally I start to think I see patterns. Well, hallucinations of some kind anyway. Almost every time we start with the development teams. We do a good job, we get them up and sprinting, train a few scrum masters, console a few managers, and Bob’s your uncle: the dev teams are agile! Then what happens?
Downstream, the operations teams aren’t on board with the whole agile thing. They aren’t going to let you change their release processes just to satisfy some fad. Rapid change? Are you nuts? And what about the other end of the value stream, sales? They’re willing enough if it makes them money, but you’d better deliver (which isn’t happening with the operations guys, so you are screwed).
So lets take a step back and look at the value stream. Where do we typically see the most time spent? It’s not development – we’ve been squeezing development in one way or another for decades. However, you can find the most amazing queues in sales. With the rest of the organization moving so slowly, they naturally develop queues as they wait for the work to get done.
The question is, why don’t we start at the back? Why don’t we make the end of the value stream our focus first? We need to stop starting in the middle. Goldratt would have us chasing the bottlenecks. More power to him. If I speed up operations first, I may not see an immediate increase in productivity, but I have created the runway for success. I have them on board and bought in. Now, we move up the value stream to the Development teams. If we can get them performing, then we have already prepared the runway for them. No longer do we give them a fast car and ask them to drive it into the wall. Now they can deliver and they can do it with proper support from operations.
From there we can continue to move up to Sales and the front end of the value stream. They should be an easy sell at this point. So, the question is, why start in the middle?
Filed under: Agile, Coaching, Process, Teams Tagged: Agile, Process, Transition, value stream
No one wants advice, only collaboration. – John Steinbeck
Imagine you are working as part of a team on a project. One day your manager approaches you and says, “There is this really high priority project that has come up and we need you and your expertise on it. We are going to move you onto that team for the duration of the project. Is that OK with you?”
How would you feel about that? I know how I would feel. I would feel jerked around. I would not feel in control or part of the decision making. I might even feel that the value of my membership to the team that I’m already on is being discounted. In short, it would suck.
How do you think your team would feel about it? Would they feel like they were able to participate in, let alone determine, the membership of their team? They wouldn’t feel in control of anything either. In fact, they might even feel victimized by the whole experience. They might be thinking, “Geez, we are screwed. How are we going to finish this project without Joe?” They might even wonder why you were the one who was chosen. That could lead to all sorts of fun misunderstandings.
So what would you do instead? After all, there is this project or team that needs help. It’s a top priority – a higher priority than anything else you are working on now. How can we manage this situation without destroying the integrity of the team?
Instead of moving individuals we could take the problem to the whole team. Perhaps a manager would come and sit down with the team and describe what they need. They could explain the trade offs and the specifics of what the other team needs help with. Then they might ask, “Could you guys help this other team out…as a team.”
This would have all sorts of advantages. If a team needs help and you send them just one guy, you’ve increased your team size by one person. If instead, an entire team pitches in to help, then you get the resources of 6 or 7 guys. Forget whatever multiplier effect you might get from a closely knit team – which solution is going to deliver results faster? That’s right, the team of 7. And there is more benefit besides productivity. By engaging the team in this fashion you are asking them to remain a team, and to help another team. Team’s helping teams – what a great idea!
You don’t hurt morale. You leave the decisions on how to manage the problem to the teams – so they feel like they own the problem. They are engaged, they are helping someone else. It really does have a lot going for it.
So what about that other project you were working on? You know, the one that you had to put down to help out with that other team? What about that project? Wasn’t it important too? Sure, but it wasn’t as high a priority, so it waits. This encourages the kind of organizational focus where everyone is attending to the most important issues first, rather than scattering their efforts across multiple lower priority issues in the name of higher utilization or productivity.
So if you are currently in the habit of pulling people off of teams in order to solve resourcing problems, I’m here to tell you that there is another way. If you are open minded enough to give it a try, you might just find that it may be a better way.
Filed under: Agile, Teams Tagged: Collaboration, control, micro management, poaching, resource management, Teams
Welcome to our September newsletter and welcome to summer.
This is the first Scrum Coaching Retreat in Africa. It is an opportunity for you to collaborate with other coaches, learning from each other and producing valuable outcomes that will have lasting benefit to our community and customers.
The theme of this retreat is “small improvements”, recognising that most big changes are better embarked on, digested and internalised one step at a time. Transforming the world of work is a big endeavour. We can contribute by meeting our customers where they are and helping them take one next step.
For first-time visitors to South Africa we promise you an awesome experience in the winelands surrounding our Mother City. Come early or linger an extra week to experience this special place in high summer. For local coaches we promise you deep interactions with some of the best Scrum coaches on the planet.
Joanne’s Adventures in Europe
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….more.
Kanban TrainingThe popular Applying Kanban (Foundation) course sold out in record time, and all seats have now been filled. We plan to run another course in May 2015, which we have already started taking bookings for. Reserve your place at the May 2015 Applying Kanban (Foundation) course Kanban foundational course provides insight and visibility to the “why” of doing things – Dean Harvey, Nedbank Ltd. We still have a few spaces available for our Improving & Scaling Kanban(Advanced) certified courses which will be taking place in Sandton on the 23-24 Oct 2014. We are running a 3-for-2 special offer, so be sure to secure your place!
Other News Lean Agile 2014 SA
Scrum Gathering South Africa 20-21 October
Scrum Sense will be at the Scrum Gathering in full force. Catch us presenting on the following subjects:
- Dillon Weyer and Angie Doyle are running a workshop on Vision: Making a good team GREAT
- Peter Hundermak will be talking about Here be Dragons: Scaling Agile
- Joanne Perold, Danie Roux and Kevin Trethewey will be talking about Problem Solving in Complex Environments
Many teams have difficulties doing task planning before they have thought about the technical concept. To address this challenge, I have a strategy I call "Pair and Share".
PreparationGood preparation is half the battle. This means that coming out of Sprint Planning 1, you should have a selected product backlog ("forecast") that consists of reasonably small stories. Six to 10 items in the forecast is a sign that the stories were small enough (assuming it is a good forecast).
Your team has had the conversations with the Product Owner, the Stakeholders, other Subject Matter experts, etc, and the confirmation is reasonably clear, perhaps in the form of a how-to-demo workflow, or other criteria which can be readily turned into an (automated) acceptance test. If you are still discussing the confirmation during the task planning, you probably have a long meeting in front of you ;-) Having said that, there is a reason the Product Owner should be in the room!
Pair and ShareHere's how it works:
As a Scrum Master, I would take a moment to remind the team about the importance of working according to priority, getting things really done (as opposed to getting a lot of stuff sort of but not really done), and of minimizing work in progress, especially unfinished work at the end of the sprint. The goal for this meeting is not to create the definitive technical concept or task planning, but to create enough of each that the team can start working.
Then timebox Sprint Planning 2, the second half of the meeting, to one hour per week of sprint. So for two weeks, that gives you two hours. Divide that again in two halves, in this case 1 hour each for conceptual work and for task planning.
Have the team pair off. So if you have 6 people in the team, you have 3 pairs. Each pair takes two or three stories (what does this say about how big the stories are?). They have 1/2 hour to come up with their initial technical concept for implementing each story. So they timebox their discussion to 10 or 15 minutes per story.
After the first half hour is up, each pair explains how they want to implement each story to the rest of the team. Short Q&A. You are probably timeboxing the presentation to about 5 minutes per story. The rest of the team can ask questions, so this "share" part builds shared understanding and serves as an initial design review. The discussion may cause the team to rethink their solution, which will influence the task planning.
So now an hour has gone by, and you repeat the process, this time for task planning. Split into pairs (possibly different pairs than the first time), take the top stories, and do 1/2 hour of task planning.
During the final half hour, the team meets in front of the task board. One by one, each pair posts and explains their task planning to the rest of the team.
So now, pairs have thought relatively deeply both about the technical concept and the task planning. The whole team is consulted, and the team is well positioned to work forward as a team to start implementing.
BTW 1 - It may be that the team wants to think more about a particular item before committing to that particular concept. That's OK! Just make a task, "Finalize Design" or whatever.
BTW 2 - How did I come up with this? One of my first teams asked themselves this very question, and this is what they came up with! It worked beautifully! So if this doesn't feel right for your team, give them the goals for the meeting and ask them how they want to do it! Maybe you should even do that first!
Let’s just say I was testing the bounds of society. I was just curious. -Jim Morrison (1943 – 1971)
I’ve been contemplating experimenting with some change, but I’m not really sure what is going to work and what won’t. In some ways that dilemma mirrors my coding style. Often when I embark on a project, I’m not entirely clear whether or not what I’m doing will work or not. I mean, I think it will work…but I’m really not absolutely positive. When I code…stuff happens.
I guess I could be accused of rushing into coding without taking care to fully think the problem through. But when I’m swept up in the moment, I want to run with the momentum I have. Call me impulsive. I admire others who have the self discipline to worry through the analysis before they get started, but that’s just not me.
That’s why Test Driven Development has been such a lifesaver for me. It forces me to think about what I’m trying to accomplish before I write the code. It gives my approach a little rudimentary discipline, rather than simply stampeding into the code. Moo.
The question is, can I use TDD to help with organizational change? What would that look like? In order to do TDD we have to start by asking ourselves what the expected outcome of this process or change is. In terms of team performance, that might mean a change among many different metrics (i.e. velocity, throughput, etc.). So first you set up the test: what would the desired outcome of the change be? More software? Happiness? Safety? Openness? Joy? Perhaps it is the absence of something?
Example Change: I want to bring more openness to new ideas to our work.
Next, what are the things that would indicate success? A change in the number of releases? A subjective rating of mood? Maybe a count of unsolicited ideas? Keeping a resistance index (a count of protests per session)? A count of positive/supportive statements. Basically we are looking for some kind of measure that might give us an indication that we are passing our test.
Example Test #1: I will count new ideas that come up in team meetings on a daily basis – If the count is greater than 10, then the test passes
Wacky thought: would it be possible to measure all behavior change in relation to changes in code? How would a subjective notion like enhanced social safety within the team be reflected in the code base? Whoa…I think I just bent something important in my head when I bumped into that last thought.
Of course, just like for code, you probably wouldn’t write just one test for any given change. Like code, change is complex, so we are going to be well advised to create multiple tests for any given single proposed effort.
Example Test #2: I will count the number of new ideas that get shot down daily – if the count is less than 3, then the test passes
Great, now we have some tests, what next? Well in TDD we run the tests first and verify that they all fail. Yes, Martha, all the tests are red. Good! Now, and only now are we ready to create change.
Example Test Run: Day one, test 1: result is 4 new ideas – test fails. test 2: the result is 4 – test fails. We are red.
So we put our change initiative into place. But wait – we must keep in mind rule #1 of test driven development: do only the very simplest thing to pass the test. What does that mean? Well if you want people to be happy, what’s the very simplest thing we could do? Would you go to HR and initiate some sort of peer reward system complete with executive buy-in and a roll out program with sensitivity training? Or…would you make a point each day of telling someone how much you genuinely appreciate working with them? Remember, rule #1: KEEP IT SIMPLE!
Example Change: Add a new rule to the team agreement – you can’t say “no” to a new idea.
Then we run the tests again. Where do we fail? Where do we pass? Now we might have some interesting information!
So, before I forget, there is one last thing we should do: refactor. Now we need to go back and take a look at those tests and see if we can improve them. We also look for ways to improve the changes we made. Maybe instead of telling people how much you appreciate them, you give them a hug instead.
Then just like in TDD, we go back to #1 and repeat.
Of course we can’t call this Test Driven Development because that name is already taken. Maybe we could call it Test Driven Change? TDC…Yeah, that could work. Let’s call it Test Driven Change – if I can get three people to do it, then we’ll call it a movement!
Filed under: Agile, Coaching Tagged: Agile, Behavior, change, change management, Coding, TDD, Test Driven Development, Testing
Edit: I’ve noticed a lot of the Kindle-spam that’s suddenly been appearing. I’ve updated my search rules and edited this post to remove the spam. You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
- 10 Things Every Product Owner Should Know via @crocagile #ProductOwner #Scrum #Agile #PM #PMOT
- 10 Things Every Product Owner Should Know via @crocagile #ProductOwner #Scrum #Agile #PM #PMOT
- RT @RohanCrawford: 10 Things Every Product Owner Should Know via @crocagile #ProductOwner #Scrum #Agile #PM #PMOT
- RT @yochum: Agile Volunteering, Rally Style #agile #scrum
- Change one thing at a time! – #scrum #agile #coaching
- J.D. Meier’s Blog: Ten at Ten Meetings #agile #scrum
- RT @MasterScrum: The Lorax Would Be a Great Product Owner!
Lessons in #scrum from a Dr Seuss classic. #agile
- RT @MasterScrum: The Lorax Would Be a Great Product Owner!
Lessons in #scrum from a Dr Seuss classic. #agile
- #oreilly Save 50% #Agile #Data #Warehousing Project Management
Business Intelligence Systems Using #Scrum
- RT @versionone: The 4 values of the Agile Manifesto explained in this video: #agile #pmot #scrum
- Call it as you want, but don’t call it Scrum if it’s not! #Agile #Scrum #PM #PMOT
- Call it as you want, but don’t call it Scrum if it’s not! #Agile #Scrum #PM #PMOT
- 5 ways Scrum can help you (and 5 it can’t) #Agile #Scrum #PM #PMOT
- 5 ways Scrum can help you (and 5 it can’t) #Agile #Scrum #PM #PMOT
- RT @BrunoSbille: We need your support! Can you please RT ? Call of speakers, #Agile Tour Brussels 2014 #atbru #scrum…
- Agile Canada » Project Manager – NTT Data – Toronto, ON: Scrum Methodologies using Agile… #Canada #Agile #Jobs
- NeuroAgile Quick Links #agile #scrum
- RT @yochum: NeuroAgile Quick Links #agile #scrum
- RT @AgileTurkey: yeni yazı yayınlandı: ‘Zincirleme İletişim Kazası’ @BorVf #agile #scrum
- Why story points are sane after all. @mikewcohn has an explanation involving the kings nose. #scrum #agile
- RT @jorge_abad: Comparto: Principios de Incertidumbres de Requistos, Procesos y Productos de Software #agile #agil #…
- Life as a scrum master as compared with being a parent “Happy Father’s Day” from @GeoffHunt1 #agile #scrum #project
- RT @optimalhq: Life as a scrum master as compared with being a parent “Happy Father’s Day” from @GeoffHunt1 #agile #…
- RT @optimalhq: Life as a scrum master as compared with being a parent “Happy Father’s Day” from @GeoffHunt1 #agile #…
- RT @RohanCrawford: 10 Things Every Product Owner Should Know via @crocagile #ProductOwner #Scrum #Agile #PM #PMOT
- #Agile – Do you know how many tasks has to do an Scrum Master? – http://t.co/MlGELQJzh3
- Subscribe #agile #scrum #projectmanagement
- How #agile should your startup be? #dev #SCRUM
- Agile in a Highly Regulated Organization, Part 1 – #Agile #Scrum
- Interesting #scrum #agile article
“Hardening Sprints. What are they? Do you need them?”
- Principal Agile Scrum Master #usajobs #jobs #jobs4u #hiring #tweetmyjobs #pmot #projectmanagement
- How to Use Scrum in Hardware Development via @scoopit
- Agile by McKnight, Scrum by Day is out! Stories via @RohanCrawford @ErrataReparator
- Epic Sharding (breaking work into smaller pieces) via @pivotallabs #agile #scrum
- Mini book: Confessions of a Scrum Master via @TheAgileNetwork #Agile
- #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Pune, apply now! #job http://t.co/fQ8yVpd0nG
- Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Pune. #Accenture http://t.co/GRjCteOB7t
- New #job opening at #Accenture in #Pune! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) http://t.co/Pxu7nYvEYL
- Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Pune at #Accenture. Apply now! #job http://t.co/AyxPvGiP1C
- RT @TheAgileNetwork: Mini book: Confessions of a Scrum Master via @TheAgileNetwork #Agile
This post is continued from Cost, Value & Investment: How Much Will This Project Cost, Part 1
We’ve established that you need to know how much this project will cost. I’m assuming you have more than a small project.
If you have to estimate a project, please read the series starting at Estimating the Unknown: Dates or Budget, Part 1. Or, you could get Essays on Estimation. I’m in the midst of fixing it so it reads like a real book. I have more tips on estimation there.
For a program, each team does this for its own ranked backlog:
- Take every item on the backlog and roadmap, and use whatever relative sizing approach you use now to estimate. You want to use relative sizing, because you need to estimate everything on the backlog.
- Tip: If each item on the backlog/roadmap is about team-day or smaller, this is easy. The farther out you go, the more uncertainty you have and the more difficult the estimation is. That’s why this is a tip.
- Walk through the entire backlog, estimating as you proceed. Don’t worry about how large the features are. Keep a count of the large features. Decide as a team if this feature is larger than two or three team-days. If it is, keep a count of those features. The larger the features, the more uncertainty you have in your estimate.
- Add up your estimate of relative points. Add up the number of large features. Now, you have a relative estimate, which based on your previous velocity means something to you. You also have a number of large features, which will decrease the confidence in that estimate.
- Do you have 50 features, of which only five are large? Maybe you have 75% confidence in your estimate. On the other hand, maybe all your features are large. I might only have 5-10% confidence in the estimate. Why? Because the team hasn’t completed any work yet and you have no idea how long your work will take.
As a software program team, get together, and assess the total estimate. Why the program team? Because the program team is the cross-functional team whose job is to get the software product to done. It’s not just the software teams—it’s everyone involved in the technical program team.
Note: the teams have to trust Sally, Joe, Henry and Tom to represent them to the software program team. If the teams do not, no one has confidence in any estimate at all. The estimate is a total SWAG.
The delegates to the program team know what their estimates mean individually. Now, they “add” them together, whatever that means. Do you realize why we will call this prediction? Do Sally, Joe, Henry, and Tom have feature teams, service teams, or component teams? Do they have to add time for the experiments as they transition to agile? Do they need to gain the trust of their management? Or, are they already experienced agile feature teams?
The more experienced the teams are at agile, the better the estimate is. The more the teams are feature teams, the better the estimate is. If you are new to agile, or have feature teams, or have a mixed program (agile and non-agile teams), you know that estimate is way off.
Is it time for the software program manager to say, “We have an initial order-of-magnitude prediction. But we haven’t tested this estimate with any work, so we don’t know how accurate our estimates are. Right now our confidence is about 5-10% (or whatever it is) in our estimate. We’ve spent a day or so estimating, because we can spend time delivering, rather than estimating. We need to do a week or two of work, deliver a working skeletong, and then we can tell you more about our prediction. We can better our prediction as we proceed. Remember, back in the waterfall days, we spent a month estimating and we were wrong. This way, you’ll get to see product as we work.”
You want to use the word “prediction” as much as possible, because people understand the word prediction. They hear weather predictions all the time. They know about weather predictions. But when they hear estimates of work, they think you are correct, even if you use confidence numbers, they think you are accurate. Use the word prediction.Beware of These Program Estimation Traps
There are plenty of potential traps when you estimate programs. Here are some common problems:
- The backlog is full of themes. You haven’t even gotten to epics, never mind stories. I don’t see how you can make a prediction. That’s like me saying, “I can go from Boston to China on an airplane. Yes, I can. It will take time.” I need more data: which time of year? Mid-week, weekend? Otherwise, I can only provide a ballpark, not a real estimate.
- Worse, the backlog is full of tasks, so you don’t know the value of a story. “Fix the radio button” does not tell me the value of a story. Maybe we can eliminate the button instead of fix it.
- The people estimating are not the ones who will do the work, so the estimate is full of estimation bias. Just because work looks easy or looks hard does not mean it is.
- The estimate becomes a target. This never works, but managers do it all the time. “Sure, my team can do that work by the end of Q1.”
- The people on your program multitask, so the estimate is wrong. Have you read the Cost of Delay due to Multitasking?
- Managers think they can predict team size from the estimate. This is the problem of splitting work in the mistaken belief that more people make it easier to do more work. More people make the communications burden heavier.
Estimating a program is more difficult, because bigness makes everything harder. A better way to manage the issues of a program is to decide if it’s worth funding in the project portfolio. Then, work in an agile way. Be ready to change the order of work in the backlog, for teams and among teams.
As a program manager, you have two roles when people ask for estimates. You want to ask your sponsors these questions:
- How much do you want to invest before we stop? Are you ready to watch the program grow as we build it?
- What is the value of this project or program?
You want to ask the teams and product owners these questions:
- Please produce walking skeletons (of features in the product) and build on it
- Please produce small features, so we can see the product evolve every day
The more the sponsors see the product take shape, the less interested they will be in an overall estimate. They may ask for more specific estimates (when can you do this specific feature), which is much easier to answer.
Delivering working software builds trust. Trust obviates many needs for estimates. If your managers or customers have never had trust with a project or program team before, they will start asking for estimates. Your job is to deliver working software every day, so they stop asking.
Rally Onboarding Bootcamp: Class of June 2014
“Rally truly practices what it preaches. Volunteering at There With Care touched my heart and made me proud that the company I work for is helping such a wonderful organization. It was amazing how we pulled together as a team and incorporated our Agile training from earlier in the day into our give-back project.” — Terri Barrowcliff, Customer Relationship Manager, Rally Onboarding Bootcamp, June 2014
During my first year at Rally, we’ve experienced exciting growth as a company. When I started in August 2013, we had about 400 people worldwide. Today, we’re over 500 and still growing. With so many people joining the company, we’re continuously refining our onboarding process — adapting it to focus on what newcomers really need to know to succeed at Rally, and introducing a strong dose of company culture. Each month, new employees from around the globe come to our Boulder headquarters to experience Onboarding Bootcamp, Rally style.
Giving back to the communities in which we live and work is among the values on which Rally was founded and holds dear (see 1%: Small Percentage, BIG Impact). Another of our core values, as you might expect, is to Live Agile. So we challenged ourselves to combine the two: create an impactful community service activity that instills the importance of giving back our time and talents that’s also a hands-on learning opportunity in Agile practices.
I reached out to Jodee Spalding, Volunteer Director at There With Care, a Boulder-based nonprofit organization that provides fundamental support services to families and children facing critical illness. I knew that There With Care relies heavily on volunteers to deliver its services and found a willing partner to customize a program for Rally. With Jodee’s help we quickly identified an important need that Rally could fulfill.
“Easy Meal Care Bags are essential to the parents and caregivers of children being treated in the hospital. Instead of leaving for meals, loved ones can stay at the child’s bedside to provide comfort and support, and ensure they don’t miss an opportunity to speak to the child’s doctor. Now that Rally is sending volunteers once a month to create the bags — and funding the cost — we are able to replenish them as needed, and the families are so grateful.” — Jodee Spalding, There With Care
On their first day of Rally Bootcamp, new employees spend two hours with our Agile coaches learning about Agile concepts, methodology, and practices. Later that afternoon at There With Care, we ask the new hires to practice some of those concepts — such as self-organizing teams, collaboration, and inspect/adapt — when assembling the Easy Meal Care Bags. We provide the product requirements and let the team decide how to get the job done, with the following guidance:
- Take time to plan the work and organize as a team
- Focus on quality and process, more than on quantity and speed
- Limit work in progress (WiP) and watch out for bottlenecks
- Respond to change over following a plan
- Consult the Product Owner (Jodee) as much as needed
- End with a retrospective — what did we learn and what could we do better next time?
Rally Bootcamp participants conduct a midpoint review while assembling Easy Meal Care Bags.
Since February, 134 employees have volunteered at There With Care, contributing a total of 201 hours and creating 425 Easy Meal Care Bags weighing in at 3,188 pounds of food and drinks — lovingly delivered to parents stationed at the bedsides of their critically ill children. A grant from the Rally For Impact Foundation covers the cost of the bag contents, which has totaled nearly $5,000 since the partnership started just nine months ago.
“Just as meaningful as the grant is Rally’s donation of more than 200 volunteer hours from new groups of big-hearted Rallyers lending their compassion each month. In appreciation, we’ve honored Rally with our Inspiration Award, presented to individuals and community partners that have contributed outstanding service to There With Care’s mission.” — Jodee Spalding, There With CareGeri Mitchell-Brown
“If you meet the Buddha on the road, kill him!”
This is a popular saying derived from an old Zen koan. When it comes to working with Agile projects I find this saying very appropriate. People who do Agile transformations typically talk about finding the Way (the road) and often speak with almost religious fervor regarding Agile processes.
In fact, Agile is really just one short step away from organized religion. You have daily meetings, attend retrospectives where we examine our patterns of behavior deeply, we worship idols with bizarre names like “Kanban” and “Scrum” and fight (flame) wars over them. We anoint our priests as guardians of that process (yes, I’m talking about you, Scrum Masters), and agonize endlessly over whether we and others are following the right path.
Wow, maybe Agile actually is a religion. That’s pretty scary. I’ve got to go sit down now.
OK, I’m back. What were we talking about? Oh yeah, killing the Buddha. So, given my little digression above, it would be pretty easy to rewrite that old Zen saying like this:
“If you meet an Agile Guru while on your journey (to excellence, improvement, whatever), kill him!”
Now aside from sounding terribly violent, what the heck do I mean by that? It turns out, that having an Agile guru around is pretty limiting when it comes to learning and continuing to grow. Whenever we have a guru like that, what do we do? We defer to his expertise. We wait for him to provide the answer and we stall our own learning journey. Having an Agile guru around can freeze an organization’s development. You end up limited to whatever level the guru is at.
Many organizations have these characters lurking in their midst. Heck, I was one once. I still have a business card with a title of “Though Leader” emblazoned on it around somewhere. I’m here to tell you it can happen to anybody. One day you are a perfectly decent, self-respecting developer and then WHAM! you become an Agile Coach, or a Thought Leader, or a Lean Sensei, or any number of other wacky guru code names.
You become, THAT guy.
And trust me, you don’t want to be that guy. You know the one, the Agile guy? The guy who simply must render an Agile judgment every time he opens his mouth. The guy who everyone defers to when it comes to do all things Agile. To paraphrase the old Life cereal commercial “Is it Agile? Hey, let’s get Mikey. He’ll judge anything!”
…oh brother, I think I just dated myself straight back to the stone age.
So what do you do when you have an Agile guru? You get rid of him! What if YOU are the Agile guru? Now that’s awkward. Well, your mission is to eliminate that perception. How do you do that?
- Keep your mouth shut
- Stop telling people what’s Agile (see #1). Use pantomime or something instead.
- Bring in, find, unearth or otherwise manufacture someone who has more expertise than you do. Understand that by doing this, you will run the very real risk of learning something. Sorry.
- Rinse and repeat until nobody mentions Agile in your presence. Ever.
So if you find yourself or someone you love has become an Agile guru, take heart! There is a cure! The best thing you can do to avoid stifling (and annoying) everyone in your organization trying to get work done is kill the Buddha.
Filed under: Agile, Lean, Process, Scrum Tagged: Buddha, Kanban, Lean, mastery, Scrum, Sensei, Thought Leader
Die beliebte Small-Talk-Frage: „Und was machst Du so beruflich?“ wird für Scrum Coaches, ScrumMaster und Consultants nicht selten zur Bewährungsprobe. „Ich bin ScrumMaster“ erzeugt in unwissenden, weil wenig technischen Berufsgruppen oft nur ein Stirnrunzeln und nicht weniger häufig ein müdes Lächeln ob des ulkigen Fremdwortes – auch gerne begleitet von der Frage, welchen Gürtel man denn da schon habe.
Und dann fängt es im Kopf an zu rattern: Wo fange ich jetzt mit der Erklärung an, bei Adam und Eva? Beim Rugby? Bei Nonaka, Sutherland und Schwaber? Egal, wofür man sich entscheidet, so wirklich trivial wird es selten. Und das obwohl Scrum nichts anderes macht, als die für die Produktentwicklung intuitiv richtigen Dinge in einen Rahmen zu packen und interdisziplinäre Teams in kurzen Zyklen gemeinsam an einer Lösung arbeiten zu lassen.
Hier verhält es sich mit Scrum wie mit jedem anderen Thema auf diesem Erdball: Wenn man nur tief genug drinsteckt, lässt sich der Grad der Komplexität nach Belieben erhöhen und ehe man sichs versieht, hat man die Zuhörer in den Schlaf begeistert. Und nicht nur im privaten Rahmen sind die Erklärungskünste des agilen Prozesshüters gefragt. Es liegt in der Natur seines Berufs, an den Schnittstellen der Scrum-Teams für ein gemeinsames Verständnis sorgen zu müssen und den Prozess weiter ins Unternehmen zu tragen.
Und damit ist es ja längst nicht getan. An dieser Stelle soll die Debatte darüber, ob ein erfolgreicher ScrumMaster technisches Verständnis haben muss oder nicht, nicht angefeuert werden. Fakt ist aber, dass ein Team nicht nur zwischenmenschliche Probleme aus der Welt schaffen muss, um das gemeinsame Ziel zu erreichen.
Wohl demjenigen, der es versteht, Stift und Papier in den Grundfunktionen zu bedienen: schreiben und skizzieren. Es ist kein Zufall, dass sich Boris Gloger Consulting und die Kommunikationslotsen zusammengetan haben, um Scrum Consulting und Visual Facilitation zu einem gemeinsamen Training zu verschmelzen. Für die Teilnehmer bedeutet das: Sie erlernen die bikablo® Grundtechnik und können sie direkt auf ihren Arbeitsalltag im agilen Umfeld anwenden.
Ein Schelm, wer glaubt, hier gehe es lediglich darum, schöne Flipcharts zu malen – getreu dem alten Politiker Schlachtruf „Inhalte überwinden“. Nein, hier geht es darum, sich, seine Teamkollegen, Kunden oder Stakeholder schnell und effektiv zu einem gemeinsamen Verständnis für eine Situation oder der Lösung eines Problems näher zu bringen.
Angenehmer Nebeneffekt: Wenn Sie das nächste Mal jemand fragt, was Sie eigentlich machen, malen Sie es einfach auf!
Tipp: Visualisieren wie ein Meister – mit den Tipps aus unserem Training “Visual Scrum” sind chaotische und inhaltsleere Flipcharts Schnee von gestern. Melden Sie sich hier gleich zum nächsten Termin am 13. & 14. Oktober 2014 in Köln an!
- Visual Scrum
- The five secrets of a successful Scrum training | May 22nd , Recife, Brazil
- Servant Leadership