Skip to content


How to make wall-related decisions in Distributed Agile projects

Agile World - Venkatesh Krishnamurthy - Thu, 10/09/2014 - 13:41

I authored the following article for Cutter which got published today. So, it is hot out of the press.

The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.

Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.

====  I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============

Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.

Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter


Categories: Blogs

A Team Named “Sue”

Agile Tools - Thu, 10/09/2014 - 08:32


My daddy left home when I was three
And he didn’t leave much to ma and me
Just this old guitar and an empty bottle of booze.
Now, I don’t blame him cause he run and hid
But the meanest thing that he ever did
Was before he left, he went and named me “Sue.”

-Johnny Cash, A Boy Named Sue

I love this song. It makes me chuckle every time I hear it. Its a story about a man who names his son “Sue” because he knows it will be the source of mockery and make him into a stronger man. It’s a tongue in cheek little rhyme that covers themes of fathers, sons, manhood and what’s in a name.

Today I was looking at a list of team names. Every single team in the list had named themselves after whatever they were working on. For example, there might be names like Printing Team, or UI Team, or Database Team. And check this out: if there was more than one Printing Team, guess what they called the second team? You got it: Printing Team 2.

I shook my head and thought to myself, “Who named you Sue?”

Right off the bat, I have to confess that I’m really a bit mystified by this kind of behavior. I refuse to believe that a normal human being, not coerced by any outside force, would name themselves after whatever they are working on. I’m working on a Mac right now. Maybe I should change my name to Mac too…nope…not gonna do it. It doesn’t make any sense to me (and I’m not really Scottish). I would rather name myself after something fun or aspirational. I’d use things like:

  • Mountains (Team Everest, Denali, or K2)
  • Animals (Team Angus, Viper, or Gerbil)
  • Cartoon Characters (Team Mickey, Goofy, or Donald)
  • Tools (Team Hammer, Bandsaw, or Monkey Wrench)
  • Rock bands (The Police, Metallica, or Tower of Power)

The possibilities are endless…just like my cliches. Often I think that a team is either intentionally or unintentionally given a name by those who are sponsoring or responsible for setting up the team. After all, early in a project, before everyone shows up, you need a name for this new thing. Often this name is used purely for utilities sake, perhaps with the assumption that the team will replace the name with one of their own. The team adopts it by default, because that’s what everyone else calls them, and they never bother to change it again.

I’m sure there are also places that just tell teams what they want them named. Hello, welcome to Acme! We’re going to put you on team “Sue”. I think that’s ridiculous. Here are my rules for team naming (don’t worry, no one will adopt them):

  1. You can’t name yourself after what you are working on
  2. No one individual can name the team. The team must name itself

If you want someone to feel empowered and respected, you really need to let them decide what they are going to be called. If you can’t even do something as trivial as that, then you are probably going to struggle in other areas too.

So what are your rules for naming teams?


Filed under: Agile, Coaching, Teams Tagged: empowered, Johnny Cash, label, naming, Teams
Categories: Blogs

Persönliches geht vor Fachlichem

Scrum 4 You - Thu, 10/09/2014 - 07:30

Im Business ist es wie in anderen Bereichen des Lebens auch: Es funktioniert in erster Linie über persönliche Beziehungen. Mag ich jemanden persönlich, nehme ich sogar fachliche Mängel in Kauf.

Glaubt Ihr nicht? Ich wohne in Prenzlauer Berg in Berlin, da gibt es eine Weinbar, die von einem Italiener geführt wird. Niemand nennt den Namen der Bar, wenn er da hingeht, alle gehen zu Johnny. Johnny begrüßt alle herzlich und persönlich, egal wie groß der Stress ist. Für die persönliche Begrüßung nimmt er sich Zeit. Und er macht ganz klar, dass gerade Du ihm besonders wichtig bist. Außerdem ist Johnny großzügig. Es gibt zu jedem Wein immer ein großes Glas Leitungswasser, das ständig nachgefüllt wird, und zu jedem Getränk gibt es einen kleinen Teller Tapas dazu.

Der Laden ist immer voll. Die Leute mögen es gemocht zu werden und nehmen die mittelmäßige Qualität in Kauf. Die Weine sind so la la. Geraucht werden darf auch, was im Winter in dem kleinen Laden zu tränenden Augen führen kann. Im Sommer sitzt man draußen und ab 22:00 Uhr kommt er alle 5 Minuten vorbei und macht “psst” wegen der Nachbarn. Das hindert niemanden daran, zu Johnny zu gehen.
Wenn ich den Menschen Wertschätzung entgegenbringe, ihnen zeige, dass ich sie mag und gern mit ihnen arbeite, ihre Stärken sehe und kommentiere – dann muss ich mit meiner fachlichen Kompetenz schon sehr neben den tatsächlichen Anforderungen liegen, bevor der Kunde sich gegen eine weitere Zusammenarbeit entscheidet. Solange ich noch etwas finde, was mir bei Johnny schmeckt, Bier statt Wein z.B., werde ich weiter hingehen. So lange ihr einen Mehrwert für den Kunden liefert, wird er einen Grund finden, euch zu halten. Wer sich jetzt an das super-leckere Restaurant erinnert, in dem der Kellner so pampig war, der weiß genau, was ich meine.

Jetzt glaubt ihr mir vielleicht und sagt: “Gut, dann bin ich eben nett zu den Leuten.” Aber es gibt da eine Schwierigkeit. Ich kann nicht vortäuschen, dass ich jemanden mag. Und ich werde die Person nicht mögen, ihre Stärken gar nicht sehen, wenn sie Eigenschaften hat, die ich an mir selbst nicht mag. Das heißt, um stabile, wertschätzende persönliche Beziehungen aufzubauen, werde ich an mir selbst arbeiten dürfen. Schatten integrieren, wie es so schön heißt. Mich also mögen lernen, so wie ich jetzt gerade bin. Johnny hat eine intakte und stabile Familie. Er ist emotional satt und genährt und kann dadurch ganz viel Herzlichkeit verschenken.

Wem es zu anstrengend ist, das Herz des Kunden zu gewinnen, der kann natürlich weiterhin durch hohe fachliche Qualität und zeitliches Engagement den Verstand des Kunden überzeugen.

Wo und wie nährt ihr euch fachlich und persönlich?

Related posts:

  1. S wie Scrum
  2. Mr. Change, könnten Sie meine Gefühle bitte etwas weniger aufwirbeln?!
  3. Reading: Johnny Bunko — The Last Career Guide you´ll ever need

Categories: Blogs

My next Boulder SPC Class Oct 21-24, 2014

Hi Folks,

I’ll be teaching my next SPC certification in Boulder October 21-24. This is the second US  course I’ll be teaching based on SAFe 3.0 and, the first from a recent update to Leading SAFe 8.1. This should be a fun course; at least I’m excited about teaching from the new baseline! It will probably sell out, but there are a few seats left add of today. You can register here.

Hope to see you there.


Categories: Blogs

SAFe Program Consultant Training – Review

Learn more about our Scrum and Agile training sessions on

I want to give some perspective on SAFe and the training that I have been attending these last few days.  The training itself is not actually over, but we are very near the end.  Just one day left, but it is dominated by the SPC exam and open Q&A on advanced topics.  In other words, we have covered the essence of SAFe.

Ad Hoc, Pragmatic and Transformative

When I think about organizations or departments trying to become Agile enterprises, I generally categorize those efforts into three approaches.

The “Ad Hoc” approach is typified by a grassroots movement or an executive decreeing “be Agile” with no one really knowing what that means.  A lot of organizations have some teams in this condition – they try Scrum, try some other Agile-ish things, and have modest successes.  When the enterprise is large enough, these ad hoc approaches reach a natural limit of effectiveness before they become severely blocked by organizational considerations.  Then, the leadership of the organization must turn to systematic approaches to becoming an Agile enterprise: the Pragmatic approaches or the Transformative approaches.

The “Pragmatic” approach acknowledges the difficulty of change, particularly for those in middle management.  There is still a deep acknowledgement of the Agile values and principles, but the pragmatic part is to say that the organization will take quite a long time to adopt those values and principles end-to-end, top-to-bottom.  These pragmatic approaches typically have low risk and good results.  SAFe (Scaled Agile Framework) falls into this category along with DAD (Disciplined Agile Delivery) and possibly others that I’m not aware of.

The “Transformative” approach acknowledges the deep nature of Agile as a cultural transformation that can be done quickly when there is urgency to do so.  There is still an acknowledgement that Agile can be difficult for many people as it requires a change in mindset and deep habitual behaviours.  These approaches are transformative because they require all protagonists in the enterprise to be open to this deep and fast change to a new culture.  LeSS (Large Scale Scrum) and RAP (Real Agility Program) are both systematic transformative frameworks.

SAFe, as a pragmatic approach, has a number of excellent features that will help an organization accomplish its business and technology goals.

Scaled Agile Framework – Practical, Pragmatic, and Still Pure Agile

One big concern I had about SAFe, based on other people’s comments, was that it somehow was compromising the values of the Agile Manifesto.  I want to say clearly and unequivocally that SAFe is most certainly true to Agile.  This fact was demonstrated multiple times and in multiple ways throughout the training:

  • Explicit statements that SAFe is based on the Agile Manifesto.  At one point, Dean Leffingwell emphatically repeated several times that “we live or die by the Agile Manifesto!”
  • Clear examples of SAFe implementations making choices based on the values and principles of the Agile Manifesto.  It was common to talk about situations where SAFe ScrumXP teams, Agile Release Trains and the people involved made decisions based on “individuals and interactions”.
  • Practices and guidelines that implement the values and principles of Agile are pervasive throughout SAFe.  The Inspect and Adapt meeting, Program Increments, daily business collaboration with SAFe ScrumXP teams, customer collaboration through various forms of backlogs, reviews and demos, focus on simplicity and technical excellence with Architectural Runway, Test-Driven Development and other Agile engineering practices.
  • The instructors (not just Mr. Leffingwell) often mentioned their own philosophy of being flexible with the SAFe “framework” by making appropriate context-specific changes to the details.
  • Even participants in the class who have already started using SAFe in their organizations shared stories that clearly indicated a strong emphasis on the values and principles of Agility.

At the same time, SAFe manages to create a relatively simple interface with a traditional management organization.  This is critical and what makes it really effective as a pragmatic approach to enterprise agility.  For example, at the Agile Release Train level, there are nine roles identified (e.g. System Architect, Product Management, Business Owners).  The explicit acknowledgement and identification of these roles and how they interact with the SAFe ScrumXP teams through meetings, artifacts and other processes and tools helps an organization to map Agility at the staff level to traditional concepts at the middle-management level.  This interfacing is also pervasive throughout the SAFe framework and occurs at all levels of effort from individual team members up to high level business leaders.

Some people have grumbled about the complicated diagram as “proof” that SAFe can’t be Agile.  But a different way of looking at the diagram is that it is comfort for management.  I really appreciate this.  Back in 2004 and 2005 when I was consulting at Capital One on their first enterprise attempt at Agile, one of the coaches I was working with shared a story with me about the importance of comfort.  The project manager for an important project was very nervous that there was no Gantt chart in Agile.  At a personal level, she needed the comfort of having a Gantt chart to track the work of the team.  The coach for this project told the project manager “please, make your Gantt chart – just make sure that you let the team organize themselves without being disturbed to help you with the Gantt chart.”  Most Agilists are anti-Gantt.  This was a real eye-opener for me.  That project manager went on to gain confidence in the Agile team and was able to eventually discard the Gantt chart.

SAFe isn’t just a framework, it’s actually a scaffolding.  When you build an arch, you need a scaffold to keep everything in place until the keystone is in place.  In creating an Agile enterprise, you use SAFe as a scaffold to get you to Agility.

Lean, Agile and Leadership

This training has also spent a lot of time discussing Lean thinking, Lean product flow and Lean leadership.  SAFe asserts four principles of Agile Leadership:

  1. Take a systems view
  2. Embrace the Agile Manifesto
  3. Implement product development flow
  4. Unlock the intrinsic motivation of knowledge workers

I like this list.  I might change the wording slightly, but in going through the details of what these mean, it is clear that if leaders could adopt these principles, every organization would be a much better place to work.

There is a fair amount of time spent on helping leaders make the shift in thinking from traditional “scientific management” to “Agile leadership”.  There are a lot of good reading references given in these discussions including “Five Dysfunctions of a Team”.  There is also a lot of time spent on value stream thinking including some great discussion exercises.

Organizational Structure in SAFe

SAFe does not define all the structures throughout the whole organization.  By design, it is not end-to-end, top-to-bottom.  It does define a structure for three levels of activity: the team level, the program level and the portfolio level.

At the team level, SAFe relies on a slightly modified version of Scrum and Extreme Programming (XP) that it calls SAFe ScrumXP.  As a Certified Scrum Trainer, I’m confident that the Scrum described is “good enough” to be legitimate Scrum even if there are small variations.  One example is in the idea of commitment.  Scrum espouses the value of Commitment.  In “old” versions of Scrum, the Scrum Team was required to commit to the work of the Sprint (the business scope).  SAFe keeps this concept.  However, if you look in the most recent version of the Scrum Guide, this concept is no longer present.  One thing that I think is absolutely fantastic is that several of the XP technical practices are required practices in SAFe: Test Driven Development, Continuous Integration, Pair Programming, User Stories, Acceptance Test Automation and Refactoring.  I wish that Scrum would get around to officially requiring these practices.  This set of canned answers is sometimes an irritant for Scrum folks, but the fact is that, again, middle managers are often made more comfortable by being provided with concrete answers.  And, in my not-so-humble opinion, SAFe is providing the right answers.  Since all this is at the Team level, middle managers are even more comfortable because they can tell all these staff-level people how to work.

At the program level, SAFe scales the basic concept of a Sprint up to a larger “Program Increment” (PI) concept.  The core concept that holds the program level together is the Agile Release Train which is based on a limit to the number of people who can work effectively in a social network (Dunbar’s number ? 150).  Again, SAFe is quite definitive about process at this level: Sprints are 2 weeks long and PIs are 5 Sprints long (10 weeks).  Timeboxing is explained effectively with the concepts of cadence and synchronization as a way to ensure predictability at the program level.  Unlike the simplicity of the Team level, the Program level in SAFe introduces a number of important connectors to transitional organizations.  This is done through defining several roles that have extremely close analogues to traditional roles (and even use a lot of the same names), and through other artifacts such as vision, roadmap, non-functional requirements, and features.  There are even a number of recommended metrics for evaluating the performance of the program (not the people).

At the Portfolio level, SAFe simplifies again somewhat in that there are no new aspects of cadence or synchronization introduced, and the number of defined roles and artifacts at this level is relatively small.  One important difference at this level compared to the Program and Team levels is the introduction of a Kanban approach used to feed “Program Epics” to the Agile Release Trains at the Program level.  At this level, Kanban is used to drive the flow of value, but there is not as much emphasis on continuous improvement here (although there is when SAFe discusses leadership).  At all three levels, there is a constant emphasis on the lean concept of focusing on value rather than cost.  This comes in many of the details, but may be a bit difficult for middle managers.  Fortunately, the Portfolio level  includes some excellent advice on working with budgets and allocating those budgets to business vs. technical needs and based on the effort required at the Program level with the Agile Release Trains.  SAFe recommends revisiting budgets every six months (I believe this is meant to be every 2 Product Increments) and is the only aspect of cadence and synchronization at the Portfolio level.

The Training

I’ll admit that overall I didn’t particularly enjoy the training.  I love SAFe.  As a trainer myself, I’m too critical perhaps.  Certainly, the training I deliver has evolved over ten years of work with lots and lots of feedback and mentorship.  However, in the Agile community, the overall standard for training has improved greatly over the last 5 years and I would love to see our three trainers who helped with this course improve their delivery.

There are a also some general comments about the training that I would like to make that are about personal preference.

First, I would prefer more small exercises that are experiential.  For example, there was a great deal of time spent on centralized vs. decentralized decision-making and leadership which could have been compressed greatly with a simple exercise like the “Command and Control Walking Simulation” which takes about 5 minutes to drive home the point unequivocally.  The first two days were largely lecture with a couple big exercises (both the lecture and the big exercises were generally good).

Second, the slides.  The slides.  The slides.  The slides… and more slides!!!  Too much by far.  And using the slides for lecture made it very difficult to stay on track for time with lots of slides missed or touched on only very briefly.  This is anxiety-inducing and boredom-inducing for me.  Some people like lots of slides, but most people don’t.

Third, not enough breaks for a 9 to 6 training session.  Usually just one break in the morning and one in the afternoon as well as a short lunch.  Two breaks and a longer lunch would have made it much more tolerable from a personal comfort level.  At one point on the third day I just had to take an extra break and I ended up missing about 30 minutes before I felt ready to come back.

Final Words

I’m happy I invested in this for both myself and for Travis.  We have learned a lot about SAFe, a little about Agile and Lean, and we are both excited about offering SAFe-related services to some of our clients.  At this point I am convinced that it is appropriate and good under some common (but not universal) conditions.

I will probably write several more articles about SAFe as I process the information and start to relate it to more specific aspects of Agile, Lean, organizations, management, leadership, productivity, and, of course, our own Agile Enterprise framework, the Real Agility Program. I’m excited and happy to see that the two frameworks are not competitive or exclusive in any significant way… more about that of course!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Emotional Intelligence is a Key Leadership Skill

J.D. Meier's Blog - Wed, 10/08/2014 - 17:19

You probably already know that emotional intelligence, or “EQ”, is a key to success in work and life.

Emotional intelligence is the ability to identify, assess, and control the emotions of yourself, others, and groups.

It’s the key to helping you respond vs. react.  When we react, it’s our lizard brain in action.  When we respond, we are aware of our emotions, but they are input, and they don’t rule our actions.  Instead, emotions inform our actions.

Emotional intelligence is how you avoid letting other people push your buttons.  And, at the same time, you can push your own buttons, because of your self-awareness.  

Emotional intelligence takes empathy.  Empathy, simply put, is the ability to understand and share the feelings of others. 

When somebody is intelligent, and has a high IQ, you would think that they would be successful.

But, if there is a lack of EQ (emotional intelligence), then their relationships suffer.

As a result, their effectiveness, their influence, and their impact are marginalized.

That’s what makes emotional intelligence such an important and powerful leadership skill.

And, it’s emotional intelligence that often sets leaders apart.

Truly exceptional leaders, not only demonstrate emotional intelligence, but within emotional intelligence, they stand out.

Outstanding leaders shine in the following 7 emotional intelligence competencies: Self-reliance, Assertiveness, Optimism, Self-Actualization, Self-Confidence, Relationship Skills, and Empathy.

I’ve summarized 10 Big Ideas from Emotional Capitalists: The Ultimate Guide to Developing Emotional Intelligence for Leaders.  It’s an insightful book by Martyn Newman, and it’s one of the best books I’ve read on the art and science of emotional intelligence.   What sets this book apart is that Newman focused on turning emotional intelligence into a skill you can practice, with measurable results (he has a scoring system.)

If there’s one take away, it’s really this.  The leaders that get the best results know how to get employees and customers emotionally invested in the business.  

Without emotional investment, people don’t bring out their best and you end up with a brand that’s blah.

You Might Also Like

10 Emotional Intelligence Articles for Effectiveness in Work and Life

Emotional Intelligence Quotes

Positive Intelligence at Microsoft

Categories: Blogs

Large Program? Release More Often

Johanna Rothman - Wed, 10/08/2014 - 15:47

I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month.

Yes, have a real, honest-to-goodness release once a month.

I bet that for some of you, this is counter-intuitive. “We have lots of teams. Lots of people. Our iterations are three weeks long. How can we release once a month?”

Okay, release every three weeks. I’m easy.

Look, the more people and teams on your program, the more feedback you need. The more chances you have for getting stuck, being in the death spiral of slowing inertia. What you want is to gain momentum.

Large programs magnify this problem.

If you want to succeed with a large agile program, you need to see progress, wherever it is. Hopefully, it’s all over the program. But, even if it’s not, you need to see it and get feedback. Waiting for feedback is deadly.

Here’s what you do:

  1. Shorten all iterations to two weeks or less. You then have a choice to release every two or four weeks.
  2. If you have three-week iterations, plan to release every three weeks.
  3. Make all features sufficiently small so that they fit into an iteration. This means you learn how to make your stories very small. Yes, you learn how. You learn what a feature set (also known as a theme) is. You learn to break down epics. You learn how to have multiple teams collaborate on one ranked backlog. Your teams start to swarm on features, so the teams complete one feature in one iteration or in flow.
  4. The teams integrate all the time. No staged integration.

Remember this picture, the potential for release frequency?

Potential Release Frequency

Potential for Release Frequency

That’s the release frequency outside your building.

I’m talking about your internal releasing right now. You want to release all the time inside your building. You need the feedback, to watch the product grow.

In agile, we’re fond of saying, “If it hurts, do it more often.” That might not be so helpful. Here’s a potential translation:  “Your stuff is too big. Make it smaller.”

Make your release planning smaller. Make your stories smaller. Integrate smaller chunks at one time. Move one story across the board at one time. Make your batches smaller for everything.

When you make everything smaller (remember Short is Beautiful?), you can go bigger.

Categories: Blogs

If you are start up, think beyond one user

Agile World - Venkatesh Krishnamurthy - Wed, 10/08/2014 - 15:22

As I am coaching and mentoring a few start ups in Melbourne and elsewhere, I have noticed common pattern of issues across the board.

  • All start up founders are really enthusiastic and dream of becoming rich –> Nothing wrong with it
  • All start up founders have a strong idea in mind ---> Nothing wrong with it
  • Most start up founders believe that their idea would take over the world, even though they have never tested beyond one user   ---> Something wrong with it

Recently read a story about startup failure “Patient Communicator”.   The founder built fantastic features applying iterative development method, however, it was never tested beyond his father’s medical center.

As the founder shares his experience, PC began as a product for my father’s medical practice.  Plain and simple, I never assessed the market need for a patient portal.  It’s extraordinarily difficult to take a product that was built perfectly for a particular user and commercialize that into a broader market.

If you are in start up journey, think beyond one particular user !  

Categories: Blogs

What is Scrum? (slides from my talk at KTH)

Henrik Kniberg's blog - Wed, 10/08/2014 - 10:10
Here are the slides for my talk “What is Scrum?” at KTH (Royal Institute of Technology). It was a guest talk at a course called Projektstyrning. Hoping to inspire young entrepreneurs to plant agile DNA in their companies from the very beginning. Last time I spoke at KTH was 6.5 years ago, that’s when I read more »
Categories: Blogs

Living in the Space Between the Notes

Agile Tools - Wed, 10/08/2014 - 08:26


“The most critical aspect of the work, both artists said, was not the objects themselves, but the space between objects.”

-Daniel J. Levitin, This is Your Brain on Music

As I was reading Levitin’s book this evening I came across the quote above and had to pause. Levitin does an excellent job of explaining musical concepts like pitch, timbre, tempo and harmony in an easily accessible way. He was making the point that the art in music can be just as easily found in the absence of things as in the presence of the aforementioned properties. The moment between each note being just as much a part of the music as the actual notes themselves.

It made me wonder where “the space between objects” could be found in our teams and our processes. I think there are a few different ways you could interpret that sort of space in terms of how we work with teams. With any methodology that you practice, there are well established notes that you play. There is a cadence or rhythm to the standup meetings. You find a tone or pitch of the conversation. And sometimes, if you get really lucky, you just might find harmony.

So what would we find in that space between the notes? If I’m assessing a value stream, then you could describe the work steps as the notes and the delay between steps as the waste or absence of value adding work – the empty space, if you will. Can a value stream have a rhythm and a meter? In other words, although you can reduce waste, perhaps even eliminate some of it, you never get rid of all of the waste. The speed with which work flows through the process increases, and you have a faster tempo.

Another way of considering the space between notes would be to observe that all of our work gets done at a different pace depending on what we are trying to accomplish. There are times when the pace is slow, when we are learning and struggling with new ideas. And there are times when the pace is fast, and life goes all “Heavy Metal” on us. What varies is the slack that you give yourself when you work. I find that when I want to come up with ideas, I need a fair amount of slack, or unscheduled time. I need to doodle and noodle and put spit wads on the ceiling. I need space to think or perhaps more importantly, to NOT think. On the other hand, when the work is coming fast and furious, I know that I’m very likely going to have a hard time creating anything new, let alone remembering what I had for lunch.

The real work lies in the space between our ceremonies. What sort of tune are you playing?

Filed under: Agile, Process Tagged: Agile, music, notes, rhythm, space, Teams, work
Categories: Blogs

Zwei Jahre Scrum bei EWE

Scrum 4 You - Wed, 10/08/2014 - 07:30

Mit Neugier und Aufregung hat die easy+ Mannschaft von EWE am 8. Oktober 2012, also genau vor 2 Jahren, ihr erstes Scrum Intro Training erlebt. Inzwischen sind bis zu 12 Scrum Teams für die Weiterentwicklung des Abrechnungs- und Kundenmanagement-Systems zuständig. Wir sind stolz, dass wir diese großartige Mannschaft in den letzten zwei Jahren begleiten durften! Alle haben mutige Schritte zur Agilität gemacht, mit den unvermeidlichen Höhen und Tiefen – vor allem aber hat es auch viel Spaß gemacht. In unserer Case Study könnt ihr nachlesen, welchen Weg wir gegangen sind. Inzwischen sind im Konzern andere Initiativen entstanden, die von Lean und agilen Prinzipien inspiriert sind. Um den Austausch zwischen diesen Initiativen zu fördern, haben wir vor Kurzem sogar eine Community of Practice gegründet.

Ich habe ein paar Kollegen bei EWE gefragt, was sie für sich und das Team mitnehmen, wenn sie auf die letzten zwei Jahre zurückblicken:

“Rückblickend finde ich es spannend, dass ich von einem Skeptiker (“Wie soll das denn für eine Organisation unserer Größe funktionieren?”) zu einem Verfechter des agilen Mindsets geworden bin und mir nun gar nicht mehr vorstellen könnte, so zu arbeiten wie früher.” Nils Mathiesen, ScrumMaster of ScrumMaster, EWE swb ISIS GmbH

“Ich habe nicht geglaubt, dass wir in nur zwei Jahren so viel erreichen könnten. Und auf dem Weg ist uns klar geworden, dass wir noch viel mehr auf immer höheren Ebenen bewegen können. Ich bin sehr zuversichtlich, dass wir noch einen langen und lohnenswerten Weg vor uns haben. Vor Kurzem war ein Kollege aus einem anderen Bereich bei uns. Er war gerade ziemlich im Stress bzw. unsicher in einem neuem Projekt, bei dem gerade niemand die Anforderungen kennt. Er wusste einfach nicht, mit welchem Vorgehen er dieses Projekt angehen könnte. Ein Kollege und ich arbeiten jetzt schon seit 2 Jahren mit Scrum und haben oft die Rolle des PO übernommen, daher waren wir von dieser Situation wenig überrascht. Sofort hatten wir eine Vorstellung davon, wie wir damit umgehen würden: ein Discovery Workshop mit Kunden, ein erstes Backlog Grooming, etc.” Markus Theilen, Domain Architekt easy+, EWE swb ISIS GmbH

“Im richtigen Moment gab es immer den richtigen Gloger, um uns zu unterstützen.” Nils Nussbaumer, Domain Product Owner, EWE isis swb GmbH

Danke, dass wir diese Entwicklung begleiten durften und dürfen!

Gemeinsam mit Markus Theilen berichten wir auf der OOP 2015 am 27. Januar 2015 in München über unsere Erfahrungen (Track Di 6.2). Hier geht es zum Abstract.

Related posts:

  1. Mehr wissen! Moderationstraining
  2. Coaching Ausbildung – Contrain – Mantz/Rösner
  3. Ich bin aus jenem Holze

Categories: Blogs

Lean Change Management: A Truly Agile Change Management approach

Software Development Today - Vasco Duarte - Wed, 10/08/2014 - 05:00

"I've been working in this company for a long time, we've tried everything. We've tried involving the teams, we've tried training senior management, but nothing sticks! We say we want to be agile, but..."

Many people in organizations that try to adopt agile will have said this at some point. Not every company fails to adopt agile, but many do.

Why does this happen, what prevents us from successfully adopting agile practices?

Learning from our mistakes

Actually, this section should be called learning from our experiments. Why? Because every change in an organization is an experiment. It may work, it may not work - but for sure it will help you learn more about the organization you work for.

I learned this approach from reading Jason Little's Lean Change Management. Probably the most important book about Agile adoption to be published this year. I liked his approach to how change can be implemented in an organization.

He describes a framework for change that is cyclical (just like agile methods):

  • Generate or gain insights: in this step we - who are involved in the change - do small experiments (like for example asking questions) to generate insights into how the organization works, and what possible things we could use to help people embrace the next steps of change.
  • Define options: in this step we list what are the options we have. What experiments could we run that would help us towards our Vision for the change.
  • Select and run experiments: each option will, after being selected, be transformed into an experiment. Each experiment will have a step of actions, people to involve, expected outcomes, etc.
  • Review, learn and...: After the experiments are concluded (and sometimes right after starting those experiments) we gain even more insights that we can feed right back into what Jason call the Lean Change Management Cycle.

The Mojito method of change

The overall cycle for Lean Change Management is then complemented in the book with concrete practices that Jason used and explains how to use in the book. Jason uses the story of The Commission to describe how to apply the different practices he used. For example, in Chapter 8 he goes into details of how he used the Change Canvas to create alignment in a major change for a large (and slow moving) organization.

Jason also reviews several change frameworks (Kotter's 8 steps, McKinsey's 7S, OCAI, ADKAR, etc.) and how he took the best out of each framework to help him walk through the Lean Change Management cycle.

The most important book about Agile adoption right now

After having worked on this book for almost a year together with Jason, I can say that I am very proud to be part of what I think is a critical knowledge area for any Agile Coach out there. Jason's book describes a very practical approach to changing any organization - which is what Agile adoption is all about.

For this reason I'd say that any Agile Coach out there should read the book and learn the practices and methods that Jason describes. The practices and ideas he describes will be key tools for anyone wanting to change their organization and adopt Agile in the process.

Here's where you can find more details about what the book includes.

Categories: Blogs

When Agile Meets a “Non-Agile” Vendor

Illustrated Agile - Len Lagestee - Tue, 10/07/2014 - 21:57

Complications, contention, and complexities will often emerge when attempting to integrate a non-Agile vendor implementation within an Agile organization or team. From my experience, many vendors already have a phased project plan template established for their portion of the work and this can seem somewhat. What is an Agile team to do if they are dependent on a vendor for a piece of an overall solution?

While this can be a challenging scenario, here are the elements I look at when establishing a framework for “blending” agility between seemingly dissimilar frameworks and mindsets:

Shared Language. Establish a common and shared language. Are we going to have a period of requirements gathering or product discovery? Are we going to use function points or story points to size and scope? Remove any ambiguity between the two groups. Infuse as much “agility” into the language as possible. Developing a language map will anchor and guide our future conversations and frame the context of our working relationship. While a coach may need to initially help with this, developing a language map works best when co-created by those performing the work. Ideally, this language is worked into the contract but this often happens after the contract has been signed.

Note: Without establishing this shared context, everything else becomes challenging.

Roles. Ensure roles are clear and concise across all team members. Is there a Scrum Master locally but a Project Manager coming from the vendor? Will testing be performed by local testers or by the vendor? Does everyone understand their role and how each role should interact with each other? Here is an exercise to develop role clarity if you need one.

Developing empathy between roles and understanding the expectations of each role is important here. For example, the Project Manager from the vendor is most likely being requested for specific information and status from vendor leadership. What can we do to help them get what they need while still aligning to Agile values and principles?

Work Products. Each role, spanning both groups, should know what they are responsible to create or build. Will we have a project plan, product roadmap, or a release plan (or all three…or none of the three)? How will requirements be captured? Will we be writing user stories or work items? Will we have one shared product backlog or will there be a separate one for the vendor? Much of this can be resolved by aligning around the common language established together.

Ceremonies. Determine how and when we will communicate and synchronize with each other. Will we have daily stand-ups or weekly check-ins? When and how will we demonstrate working software? This is often when it gets tricky as the vendor may pull out their phased project plan and expect the Agile team to wait until they complete a phase before seeing any progress. Again, fall back to the common language and find opportunities to see progress frequently and iteratively.

Activities. Determine the activities each role will need to do to support the creation of the work products and facilitate the ceremonies. Who will be facilitating the ceremonies? Who will be responsible for grooming the backlog, how will we size the work, etc.? When will we plan, build, and test together? Be explicit but modify and improve as you go.

Information Radiation. Establish the means to communicate our progress and be accountable to each other. Vendor teams are often remote so this obviously means setting up some kind tool for shared visibility and interaction.

Escalation. Establish the approach to escalate impediments across all groups involved. Who needs to know what and when? What is the protocol when the team can’t solve something or doesn’t have what they need?

Have you worked with a vendor to create a blended agile environment? What worked for you? What didn’t? Would love you hear your thoughts.

Becoming a Catalyst - Scrum Master Edition

The post When Agile Meets a “Non-Agile” Vendor appeared first on Illustrated Agile.

Categories: Blogs

About SAFe – Lyssa Adkins

Learn more about our Scrum and Agile training sessions on

Lyssa Adkins, the “Agile Coaches’ Coach” has written a fantastic article sharing her feelings and perspective on SAFe.  (Thanks to Gerry Kirk for bringing this article to my attention!)

As you know, dear readers, my colleague Travis and I are at SAFe Program Consultant training with Dean Leffingwell this week in London, UK.  I have lots of notes even after my first day and I will write one or two articles this week giving you my impressions and highlights.  I have already reviewed all the course materials including appendices, ahead of the actual training. I can say this so far: SAFe has a lot of great things in it, and overall, I think it is a fantastic example of a Pragmatic approach to Enterprise Agile Adoption.  I will definitely be writing more on this idea of Ad Hoc, Pragmatic and Transformative approaches.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Getting Small Stories - Tue, 10/07/2014 - 12:04

In a thread about estimation in hours and whether it’s a good idea (IMO it’s not the best idea by far), this morning Robin Dymond tossed me this challenge:

You have advocated for years that teams should be able to slice stories to the point where they can complete a story in a day. My request is that you show the Agile community how to do that in writing and some exercises that use non trivial examples. I would appreciate learning more about how you do this.

Here, off the cuff, is one reply:

Single Acceptance Test

The most elegant way to do this that I know of is to consider acceptance tests for the feature. Then do them one at a time, simplest first. I first became aware of this idea from Neil Killick (one of the #NoEstimates guys), though I’d like to think I’d done it automatically a million times.

But there is another fun way.

One Dumb Idea

I’m often challenged to come up with something that could be done, even in a week, and that would look like the product. It’s rare that I can’t come up with something. But what happens next is what’s interesting. An example, from memory, cleaned up a bit to make the story clear at small expense to the facts:

Chet and I were visiting a cable TV company. Their challenge was about something they had already done, the old way: “What if our product was pay-per-view movies? The viewer has to be able to select any movie from a menu of them, watch the movie, pause it, wind it back, …” They went on and on. Then they said, “There’s no slice of that that could be done in a week.”

We talked a bit. I asked, “At the beginning of this project, did you have the ability to play a movie over a channel?” They said that they did, because (of course) they had movie channels playing all the time.

So I said, “What if the first slice is that you’re playing some movie on some secret channel, all the time, and if the viewer wants to watch it, he clicks that channel. That would nearly be done already.”

Some of them hated that example. Some liked it. There were lots of objections to how one could imagine that as “done”. The objections were all about additional features of pay-per-view: “He doesn’t get to see the movie from the beginning.” “What if he wants a different movie?” “What if we don’t know his credit card?”

Chet and I probably said a few times “Well, rewinding the movie is a new story,” or “Not switching to the secret channel without his credit card is a new story.” I remember that at one point we said “What if we started just using your boss’s credit card for everyone?”

Pretty soon — in minutes, not hours or days — some engineer in the room said “Well, that wouldn’t work, but what we could do is …” and described something they could have done.

That’s what always happens. Someone comes up with a stupid example of a story that could be done in a day or a week, whatever the then-current target is. That someone is usually me, because I am full of stupid ideas and I don’t mind putting them out there.

Suddenly things change. We’ve gone, in one step, from “impossible” to knowing a stupid, but possible, thing to do. The tone of the meeting changes, instantly, from “no way to do that” to improving the idea or bettering it.

Chet and I have done this, time and again, separately or together, in domains of all kinds. One dumb idea that could almost work is enough to switch the team from “can’t be done” to “yeah, but this would be a better way.”

The Real World

Referring to Alistair Cockburn’s “Elephant Carpaccio” exercise, Robin said:

I am familiar with Alistair’s elephant carpaccio, however his exercise uses a calculator, and developers just don’t think the example is applicable to their problems.

They always think that

A million examples, not in their domain, and they’ll still think that.

Yes, but in the real world, we have to deliver every movie ever recorded, to anyone’s house, in real time, together with all the reviews from the major outlets, with or without surround sound, wide or narrow screen, 3D or flat, with subtitles in every known language including FORTRAN, color-enhanced to support red-green color blindness, using every major credit card plus any authorized Canadian grocery store coupons, with the naughty bits either covered or enhanced, with pause and zoom in available, in fast motion and slow motion as well as regular everyday motion, using no wires or cables of any kind, without emitting any electromagnetic radiation on any spectrum, delivering to any television, computer, tablet, phone, watch, or pinkie ring, at any location in the solar system, with zero delay. You can’t do that in the real world.

Yeah, well, we just did. I doubt it took an hour.


All you need is a stupid idea, or one acceptance test. I’d typically start trying to get one story that a PO could imagine was nearly “end to end”, that can be done in a week. A day probably isn’t something the team can do right out of the box.

Or is it? In our CSD class, we do a real application and we run 90 minute Sprints. The teams deliver multiple stories in those Sprints. Not the first Sprint, mind you. :)

Yabbut …

Robin, of course, seemed to be asking for a more comprehensive compendium of ways to slice stories. I think he just wanted me to go away for a while. It might be fun to generate a whole list of examples. They would all have the same characteristics, though. It seems like you have to sit with the team and talk with them, or at least get them to talk among themselves.

My way requires someone to have a dumb idea, which isn’t that hard, but it also requires them to say it, which is harder. And — I’m just guessing here — they have to be respected enough, or enough of a stranger, to get the idea discussed instead of dismissed out of hand.

Neil’s way, doing a single acceptance test, might be better. I’ll know when I’ve tried it a few times. My way is more fun, though. I’m sure of that.

Categories: Blogs

Announcing The Swarming Development Method

Agile Tools - Tue, 10/07/2014 - 07:53


By now, you’ve probably figured out that I’m laying out all the guidance for using Swarming as a legitimate, full-fledged, Agile method. It looks like this:


There you have it. A complete method for swarming. Wrap it up and ship it.

“But wait!” you say, “You’re not a real methodologist, your just some guy with a blog!” You are absolutely right. What gives me the right to propose a new agile methodology? What kind of egomaniac thinks he can just pop up with a completely new method of team development? Well, actually, it’s not that new. I pulled a lot of the material from a variety of existing sources. I copied the format for the Values and the principles from the Agile Manifesto. Nothing here is all that original. After all, if I’m right, bugs have been doing this stuff without the benefit of my genius for millions of years. Why would I do this?

First, I’d like to state this as emphatically as I can: ANYBODY CAN DO THIS! We can all be copying methods and tweaking them – and we should. No real experience is required. After all, that’s how the guys who came up with Scrum, and Kanban, and XP did it. They copied ideas from Takeuchi and Nonaka, Ohno, Demming, Goldratt, and a whole bunch of others. We need to keep doing that – copying and stealing and mixing and removing bits until we find methods that work even better. Take this opportunity to make a methodology that is an expression of your beliefs. Heck, maybe it expresses the vision of your entire team…or company.

Secondly, there just aren’t enough methodologies out there. Having scrum taking over 80% of the agile project management ecosystem is really, really…boring. Ken Schwaber, one of the creators of Scrum, has always maintained that something better will come along one day. I’m sure that’s true, but it won’t happen unless we are creating a vibrant ecosystem of competing methods. Just having Scrum and Kanban isn’t enough.

So feel free to take this methodology – it’s yours. Run with it (careful, it’s pointy), copy it, break it, fix it, and for God’s sake, make something wonderful.

Filed under: Agile, Swarming Tagged: creation, Manifesto, methodology, practice, Swarming, theft
Categories: Blogs

Skalierung aus der falschen Richtung

Scrum 4 You - Tue, 10/07/2014 - 07:45

Wer darüber nachdenkt, wie man Scrum in großen Projekten macht, fängt meistens mit dem klassischen Bild an: Der Product Owner erstellt das Backlog und dann wird es priorisiert … bla, bla, bla – das ist euch allen mittlerweile klar. Wenn ich aber darüber nachdenke, wo die meisten Features herkommen, wer die Fehler findet, wer sich im Review mit dem Kunden auseinandersetzt, dann wird schnell klar, dass die meisten Backlog Items von den Entwicklungsteams geschrieben werden. Sie müssen sowieso von ihnen entwickelt werden. Schaut man in den Design Thinking Prozess von IDEO, dann wird auch dort sehr deutlich, dass das Entwicklungsteam sich selbst überlegt, was der Kunde am Ende benötigt.

Die Entwicklungsteams selbst erstellen die Backlog-Einträge und priorisieren sie auch selbst. Obwohl ich mir das Video über IDEOs Shopping Cart bestimmt 100 Mal angeschaut habe, hat es nicht wirklich Click gemacht. Mir fällt sogar auf, dass ich in jedem Training immer wieder sage, dass das Team die eigentlichen Backlog Items schreibt, aber – wie gesagt – das Klick, das Heureka, fehlte. Dabei lag es schon seit Jahren auf der Hand. Der Product Owner war in den meisten Projekten damit überfordert, wissen zu müssen, was das richtige Feature ist. Er weigerte sich auch oft, das Backlog zu priorisieren und wusste häufig nicht, ob die Kunden das Feature wirklich wollen. Er brauchte immer das Entwicklungsteam, damit er die richtigen Entscheidungen treffen konnte. So weit so schön, wir haben dann immer tolle Erklärungen gefunden, warum der Product Owner, obwohl er keine Ahnung von der Materie hat, dem Entwicklungsteam sagen müsste, was es zu entwickeln hätte.

Dieses Bild hat ausgedient – Skalierung funktioniert so nicht!

Das geht nur so lange gut, wie man nicht skalieren muss. Dann fällt das ganze Kartenhaus zusammen – in einem solchen Fall mit Product Ownern zu arbeiten, die sich inhaltlich nicht auskennen und daher keine Entscheidungen treffen können, führt zu den gleichen Effekten wie im klassischen Projektmanagement: niemand will Entscheidungen treffen. Der Klick kam bei mir, als mich ein Kunde etwas fragte. Dafür bin ich ihm wirklich dankbar.

In diesem Projekt hatten wir es mit 150 Beteiligten – Wissenschaftlern, Entwicklern, Programmierern, Managern – zu tun. Wir rangen mit tausenden kleinerer und größerer Probleme, und wir machten das durch das Aufstellen von Backlogs transparent. Weil das Management die Sicht auf das Ganze haben wollte (was verständlich und nachvollziehbar ist), tauchte die Frage auf, ob man denn so etwas wie ein Master Backlog habe und ob nicht mit entsprechenden Filter-Funktionen in JIRA sichergestellt werden könne, dass alles wirklich abgearbeitet wird? Die gängige Erklärung ist: Sicher, das geht! Das findet sich auch in allen vorhandenen Bildern zur Skalierung von Scrum. „Aber wieso eigentlich?“, fragte ich meinen Kunden. Das Master Backlog sei doch keine Input Queue, sondern bilde nur die Realität ab. Wir müssten unbedingt vermeiden, dass der Product Owner des Master Backlogs dieses priorisiert. Die Verwunderung war groß, denn jedes Bild in Scrum suggeriert, dass die Macht beim Product Owner liegt. Er füllt den Sprint. Der Product Owner kann dieses Backlog aber gar nicht in eine korrekte Reihenfolge bringen. Es sind zu viele Einträge. Der Product Owner müsste bei einem großen Projekt gottgleich alles beantworten können. Solche Typen gibt es, sie sind aber sehr selten und ihr Gewicht wird in Gold aufgewogen.

Gleichzeitig gibt es dennoch – ob der Product Owner es kann oder nicht – zwei Fragen zu lösen:

  • Sind die neuen Features sinnvoll – sind es also die richtigen Features?
  • Können die Teams diese Features überhaupt umsetzten?

In großen Projekten ist darüber hinaus drittens auch noch die Frage entscheidend, ob man überhaupt alle Abhängigkeiten zwischen den Teams berücksichtigt hat.

Können die Product Owner diese Fragen nicht selbst lösen, dann müssen sie wohl oder übel die Teams selbst fragen. Doch was, wenn die Product Owner es ihren Teams nicht zutrauen, diese Fragen zu beantworten? Sehr oft haben die Product Owner damit auch recht. Häufig gibt es externe Kollegen in den Teams und die wissen gar nicht all das, was die Product Owner wissen. Sie können es noch gar nicht wissen. Dann bleibt nur, die wenigen Experten in den Teams zu fragen, und schon hat man einen Infinite Loop geschaffen.

Mit Selbstorganisation hat das gar nichts zu tun – nur mit noch mehr Kontrolle

Der Wahn, alles müsste transparent und rückverfolgbar sein, auch nach Monaten oder Jahren müsste noch klar sein, welche Zeile Code von welchem Entwickler geschrieben wurde – dieser Wahn ist heute von vielen Entwicklern umgesetzt worden. Dank JIRA, Bamboo, Team Foundation Server und anderen Tools lässt sich ja alles rückverfolgen. All das hat zu noch mehr Kontrolle und noch weniger Selbstverantwortung der Kollegen geführt. Das Schreiben eines JIRA-Tickets ist einfach – da kann ich als Teammitglied schnell das Denken abschalten, denn es wird ja von einem anderen entschieden, ob ich dann daran arbeiten soll. Wieder wird die Verantwortung nach oben delegiert. Die Entscheidung liegt erneut beim Product Owner, der aber nicht für jede Kleinigkeit geradestehen kann. Wo kommt dieser Anspruch eigentlich her? Denn das sollte er in Scrum gar nie können. Nonaka und Takeuchi hätten nicht beschrieben, wie man einen interdisziplinären, cross-funktionalen Management-Prozess entwickeln kann (den Jeff Sutherland zu Scrum ausgebaut hat), wenn sie dabei gleichzeitig an volle Kontrolle gedacht hätten.

In vielen Scrum-Skalierungsansätzen wird aber genau das Gegenteil propagiert. Was mich dabei erstaunt: In Deutschland sind die Modelle, die das Top-Down-Prinzip in der Skalierung von Scrum erklären (SAF) beliebter als in den USA. Hier werden mehr Bücher dazu gekauft, als in den USA (sagt mein Verlag). Da ist was faul. Übrigens funktioniert es auch nicht. Was gut funktioniert: Skaliert wird durch Abgeben der Verantwortung bei gleichzeitiger Standardisierung, und die Berater verdienen damit viel Geld.

Wenn die Backlogs nicht vom Product Owner und seinen Product-Owner-Kollegen aufgestellt und in die „richtige“ Reihenfolge gebracht werden, wer macht es dann? Genau, die Entwicklungsteams! Skalierung ist dann ganz einfach, denn diese Kollegen wissen sehr gut, was als Nächstes getan werden muss. Sie wissen, ob es heute sinnvoller ist, den Defect zu fixen, oder das nächste Feature anzufangen. Sie haben den Kontakt zu den Usern und können viel besser verstehen, was dort gebraucht wird. Können wir aber den Teams trauen? Wie verhindern wird dann Wildwuchs? Wie verhindern wir, dass Dinge gemacht werden, die niemand braucht? Wie verhindern wir, dass die Entwickler nicht businessgetrieben arbeiten, sich in Lösungen verfangen, einer interessanten Idee nach der anderen nachgehen?

Meine provokante These: Lassen wir doch einfach zu, dass es Schwund und Fehlentwicklungen gibt. Es ist viel billiger, als alles überwachen zu wollen. Die teuren Management-Runden, in denen sich Product Owner erklären lassen, was das Richtige ist, ergeben wenig Sinn. Scrum selbst ist das Korrektiv. Wenn eine Entwicklungsmannschaft nicht liefert, keine Lösungen, keine Ergebnisse, keine neuen Erkenntnisse, wenn sich die Entwicklungsteams ums sich selbst drehen, dann wird das doch im Review sichtbar. Dann kann das Management doch eingreifen. Aber es in die Teams hinein zu kontrollieren, das funktioniert nur bedingt. Dabei wäre das sogar möglich: Wer Qualitätsmanagement als Lernprozess versteht und gefundene Fehler nicht als Versagen von Menschen, sondern als gegebene Realität sieht, wer vergossene Milch als Verlust abschreibt und nach vorne schaut, der kommt auch damit klar, dass Nicht-Liefern eine Information ist. Eine Information ans Management, dass gehandelt werden muss.

Aber das erklärt noch nicht, wie Firmen nun selbstorganisiert skalieren können, oder doch? Ich denke schon! Der Trick besteht darin, sich selbst steuernde, cross-funktionale Teams zu etablieren, die innerhalb eines Kontexts nur auf eine einziges Ziel hinarbeiten können. Dieses Ziel wird durch die Vision geschaffen, doch der Weg dahin bleibt den Teams überlassen. Die Teams müssen sich standardisierte Schnittstellen überlegen. So wie das in der Bauindustrie und in der Elektroindustrie doch auch funktioniert. Diese Übergaben werden trainiert, geschult und zertifiziert. Diese Standards zu verändern ist mühsam, aber so können funktionierende, vielleicht nicht immer perfekte Lösungen gefunden werden. Die Rahmenbedingungen werden von der Organisation gesteckt und die Teams so lange darauf geschult, bis sie die Rahmenbedingungen verstanden haben. Teams, die liefern, werden belohnt und die anderen werden lernen, was erfolgreich ist und werden es kopieren. Gleichzeitig überlässt man mehr und mehr Verantwortung den kleineren Funktionseinheiten, den Teams. Ist das perfekt? Ich weiß es nicht, aber Amazon und Google, Facebook und 3M fahren mit diesem Ansatz ziemlich gut.

Related posts:

  1. 5 min on Scrum | Business Value
  2. Dr. Scrum – antwortet
  3. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight

Categories: Blogs

Toyota Kata

TV Agile - Mon, 10/06/2014 - 19:22
Toyota Kata is a structured way to create a culture of continuous learning and improvement at all levels. It is an organizations daily habits or routines forming its “muscle memory” for continuous learning and improvements. The daily habits/routines help us to strive towards our vision, or our state of awesomeness in small focused experiments. What […]
Categories: Blogs