Skip to content

Feed aggregator

A Team Named “Sue”

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

Johnny_Cash_(1964)

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

Phase-Gates : Trapped in Wagile (part 2 of 4)

Agile Thinking - Dhaval Panchal - Wed, 10/08/2014 - 21:00

In previous article, I outlined three fundamental characteristics of waterfall system. Phase-gates are the most distinguishable characteristic of a waterfall organization.

Recap

 Phases are are strictly linear sequence of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential [...]

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

Interviewing Programmers – start with code

Diary of a ScrumMaster - Tom Howlett - Wed, 10/08/2014 - 12:24

I spent the day yesterday interviewing programmers for a new start-up near Bristol. It’s a job I love. I’m always intrigued to hear about peoples careers and how the approach the challenges we present. For me recruiting a programmer has to start with code. I don’t really care about the CV and the application process for this job involved a quick coding problem. Passionate programmers are able to communicate their ability far more easily through code than by  describing their experiences.

Traditionally interviews usually start with a discussion about the role and the candidate’s past experience. It’s often an uncomfortable conversation, everyone is a bit nervous and out of their comfort zone and I rarely get anything useful from it. I’ve learn’t that if you start with code, sitting side by side, sharing thoughts on the pre-interview problem, good candidates quickly relax. Then is the time to asking questions that go beyond programming. For me these questions focus on how they like to collaborate with others. I’ve noticed the answers I get after we’ve looked at code are very different. Some trust and mutual respect has been established and people tend to share more openly how they really feel.

 


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 met the first Spotify team, and I’m really happy to have been able to influence and participate in their journey!

Here are some sample slides from the talk:

What is Scrum? Screen Shot 2014-10-07 at 08.20.00 Don't go overboard with agile

Categories: Blogs

Living in the Space Between the Notes

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

black-and-white-classic-concert-1601-825x550

“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

Why offshoring Agile development often doesn’t work

Coaching Agile Teams by Lyssa Adkins - Wed, 10/08/2014 - 00:00

Lorraine is a seasoned Agile Coach and Certified Scrum Master with over ten years of Agile experience managing software development and implementation projects. She has published about ‘Agile and offshoring’ and ‘how to improvise Scrum’ in CIO Magazine (tinyurl.com/pvkd99n), ComputerWorld and the Agile Journal.

Lack of communication and teamwork leads to poor productivity and a solution that doesn’t provide value, says Lorraine Pauls Longhurst.

Many enterprises these days are outsourcing software development to offshore teams. Your organisation may have even tried it as a way to get access to highly skilled resources cheaply, and scale development resources up and down as you need them.

But more often than not, I hear of project failures that are blamed on offshoring. People say things like: “The offshore developers just didn’t understand what we needed” or “They developed completely the wrong thing.”

So why is it so hard? The main cause for these types of problems is a failure in communication and lack of teamwork. This has been my experience as an Agile delivery manager and coach.

As an example, let’s take a typical software development project following Scrum (the most popular Agile framework) such as the deployment of a customised ERP system.

The entire team including developers, business analysts, testers and a product owner (who represents the business users) sit together in the same room.

The group should communicate informally and act like a team by following Scrum guidelines such as letting members choose their own tasks on a shared board, and ensuring everyone helps out to meet the bi-weekly (sprint) goals.

The product owner can easily illustrate requirements by writing something on the board or giving a quick verbal example. And when you do it right, Agile enables organisations to develop a solution that can change as the business requirements are adjusted.

It enables you to deliver a working solution to users within a couple months with only the highest priority features to start. Then the team re-aligns the solution by continuously communicating with the business (or product owner).

I was involved in one project where the product owner verbally explained requirements to the onshore developers and wrote down requirements for the offshore developers.

It was pretty clear that rather than trying to resolve communication issues, they were just trying to avoid them. Instead we put tools in place to ensure the product owner was able to easily communicate face-to-face with everyone consistently, in as simple a manner as possible.

Now, take that same ERP deployment, but have the team based offshore. The team members have never met each other, are not all sitting together and do not have the same working hours.

Due to the lack of face-to-face communication, cultural differences and time zone issues, the developers start to misunderstand requirements. In an attempt to close the communication gap, the product owner starts to use more written communication, which causes more misunderstandings.

The next thing that happens is because the team has never met one another, the onshore developers don’t treat the offshore developers as part of the team.

The offshore developers start to work on their tasks independently, become less likely to clarify aspects of the project, and because they feel that they need to fend for themselves, they start to blame each other when something goes wrong.

In my experience, this lack of communication and teamwork leads to poor productivity and a solution that doesn’t provide value.

Make it work offshore

So how can you make Agile work with offshore developers? You need to get back that informal communication and teamwork that is there on a successful Agile team.

You need to overcome the issues that arise due to the fact that the team members have never met one another, are not all sitting together and do not have the same working hours.

All team members must be treated the same, and communicated with in the same manner, whether they are onshore or offshore.

Increase informal communication

In an Agile project, there is usually less written documentation and more face-to-face communication. The product owner verbally explains business value rather than giving the team detailed functional and technical requirements.

If the team understands the value of a requirement (or user story), then they are able to discuss alternative solution options. I believe this is one of the key things that can make an Agile project provide more value than a traditional project approach.

To get the entire team to communicate face-to-face more, I suggest using a ‘blended’ team. Rather than an entire outsourced team, a few offshore resources are embedded within the onshore development team.

The reason I’ve found that a blend of both onshore and offshore resources works well is it’s easier to ensure that requirements are communicated in an Agile manner (not just written down and handed over to the offshore team).

I was involved in one project where the product owner verbally explained requirements to the onshore developers and wrote down requirements for the offshore developers.

It was pretty clear that rather than trying to resolve communication issues, they were just trying to avoid them. Instead we put tools in place to ensure the product owner was able to easily communicate face-to-face with everyone consistently, in as simple a manner as possible.

Video conference is the closest thing to face-to-face communication with offshore team members. When coaching a team, I ensure that team members are talking to each other informally by video conference at least once a day real-time, during the overlapping working hours (instead of by email or instant messaging).

We used a ‘video wall’, where we had a large TV screen permanently on (using Skype or something similar). The entire offshore team sat together in one room so we could easily see everyone.

Onshore developers would walk over to the screen, say ‘hi’ and have a brief chat with the rest of the offshore team.

With Scrum, the team uses a task board to determine what needs to be accomplished in the sprint. Rather than a physical task board, we used an on-line tool to review and update the task board.

Offshore developers chose tasks themselves rather than having them assigned to them and everyone could see who was working on what. When issues arose, everyone pitched in to help out to ensure that all the tasks were complete.

Focus on teamwork

Everyone knows the benefits of teamwork in principle, but in practice it is much more difficult especially when part of the team is based offshore. There are a few methods I use to get everyone to work together towards the same sprint goals.

I have found that the only way people start helping each other out is if they feel like they really know the other team members, and understand what motivates them.

To encourage this kind of social interaction, we did a video conference chair race – India vs Australia. It was a fun way to get the team joking around with each other.

We also brought the offshore team members over to Australia for a few weeks. A little real face-to-face time went a long way.

I mentioned earlier that I believe if the team understands the business value behind a requirement (or user story), then they are able to discuss alternative functional and technical solutions and come up with what is best.

To make this work, all the team members must speak up and act like an equal member of the team.

Early in one of my projects, I found that the team was under-estimating the amount of development work and one of the offshore developers wasn’t able to deliver on time.

Our onshore designer was coming up with innovative user-friendly ideas but what I wanted the developers to do was discuss the designs as a team and come up with the best option that still fit within the timeframes we had.

To help resolve this issue, I asked one of the offshore developers to take a leadership role in the planning session and although he was to listen to the others for their input, it was up to him to give the estimates for the tasks.

The one caveat was that he then had to meet those estimates. This exercise seemed to give him the confidence to speak up much more in later planning sessions and act like an equal team member.

To make offshoring work with Agile, you need to overcome the communication and teamwork issues inherent in a team that have never met each other, are not all sitting together and do not have the same working hours.

Overcoming these issues is a challenge, but with the implementation of a ‘video wall’, an on-line task board, plus some coaching, you can still gain the benefits of Agile with a ‘blended’ team (mix of onshore and offshore developers).

http://www.cio.com.au/article/547142/why_offshoring_agile_development_often_doesn_t_work/?fp=16&fpid=1

This post originally appeared on CIO Magazine on 6/14/2014.

 

Categories: Blogs

Agile Turkey Summit, Istanbul, Turkey, October 24 2104

Scrum Expert - Tue, 10/07/2014 - 18:09
The Agile Turkey Summit is a one-day conference dedicated to the Agile software development and Scrum project management approaches that takes place in Istanbul, Turkey. International and local Agile and Scrum experts provide the content. In the agenda of the Agile Turkey Summit you can find topics like “American Airlines’ Journey to Agile Enlightenment”, ” An Enterprise Transformation Story: Türkiye Finans”, “Water – Scrum – Fall, Unicorns and Fantasy”, “Continuous Improvement Beyond The Two Week Iteration: An Experience Report From The Guardian”, “Delighting Vodafone Turkey’s Customers via Agile Transformation”. Ken Schwaber ...
Categories: Communities

SpiraPlan and SpiraTeam 4.2 Released

Scrum Expert - Tue, 10/07/2014 - 17:53
Inflectra is pleased to announce the release of SpiraTest, SpiraPlan and SpiraTeam, the latest version of their requirements management, test management and agile project-planning ALM suite. This new version provides a completely redesigned Scrum and Kanban planning board as well as enhanced source code integration and project planning. SpiraTest provides a complete Quality Assurance solution that manages requirements, tests, bugs and issues in one environment, with complete traceability from inception to completion. SpiraPlan is a complete Project Management System in one package, that manages your project’s requirements, releases, iterations, tasks and ...
Categories: Communities

Scrum Gathering Australia, Sydney, Australia, October 21–22 2014

Scrum Expert - Tue, 10/07/2014 - 17:22
Scrum Gathering Australia is a two-day conference for anyone interested in the Scrum Agile project management framework in Australia. In the agenda of the Scrum Gathering Australia you can find topics like ” Scrum Mythbusters”, “Succeeding with Scrum at the Australian Central Bank”, “40 Agile Methods in 40 Minutes”, “How not to do Agile – Fixed Scope and Deadline, welcome to the death march”, ” Product Ownership – the cornerstone of Scrum”, “Agile Antipatterns: The Scrum Master’s Guide to Traps, Tripwires, and Treachery”, “Scrum Scaling Options – How it works at ...
Categories: Communities

Announcing The Swarming Development Method

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

music-music-player-musical-instrument-566-824x550

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:

Swarming

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

Evaluating the ROI of Scrum

Scrum Expert - Mon, 10/06/2014 - 15:58
As Scrum is the most popular framework adopted by organization adopting an Agile approach for project management, many companies are trying to find financial facts that justify its adoption. This article discusses the topic of evaluating the return on investment (ROI) of using Scrum and suggests some hints about mistakes to avoid and on how to get meaningful results from this activity. Author: Neri Lavi, QualiTest Group, http://www.qualitestgroup.com/ Many strategies are supported as the “best” management of a software development process. While each programmer has his favorite way to code and every ...
Categories: Communities

XP Days Germany, Hamburg, Germany, October 16-18 2014

Scrum Expert - Mon, 10/06/2014 - 15:42
XP Days Germany is a three-day conference focused on Agile software development. With its eXtreme programming background, it contains interesting technical best practices material for Scrum practitioners and Agile software developers. All the talks are in German. In the agenda you can find topics like “The Whole Nine Yards – Integration Tests for the Software Developer”, “TDD with Contracts – an Experience Report”, “Agile Jukebox”, “The new Job of QA”, “Architectural Katas”, “Hands-On Test-Driven Infrastructure As Code Development”, “Extreme Continuous Delivery at Unruly”, “Essentially Agile”, “ScALeD – Scaled Agile and Lean ...
Categories: Communities

Environments for Swarming

Agile Tools - Tom Perry - Mon, 10/06/2014 - 08:19

143491-425321_140863459444798_1708757280_n1

What kind of environment would best suit a swarming team? I just stumbled across something called the SOLE toolkit while researching this topic. SOLE stands for Self-Organized Learning Environment. It’s designed for children (start ‘em young) and provides instructions for setting up this special learning environment. The kit recommends the following:

  • One computer per 4 kids
  • A whiteboard
  • Paper and Pens
  • A name tag

I love this! So our self organizing work environment is configured to encourage shared learning on a single machine (pairing anyone?),  plenty of whiteboards (Yes! information radiators), Paper and pens (do stickies and sharpies count?), and a name tag (team identification perhaps?). These very simple environmental constraints are all that are needed to create a self-organizing learning environment (oh yeah, don’t forget the kids).

These sorts of rules are already pretty common on some Agile teams. The pairing, many whiteboards, and lots of notes are hallmarks of enriched learning environments. So this is a great starting point for creating an environment for swarming too. If you haven’t seen the TED talk and the SOLE Toolkit, you should definitely check it out.

 


Filed under: Agile, Swarming Tagged: Collaboration, environment, kids, Learning, self-organization, TED
Categories: Blogs

Adaptive Licensing – Zulassung medizintechnischer Produkte als Lernprozess

Scrum 4 You - Mon, 10/06/2014 - 07:30

Wer  ein medizintechnisches Produkt auf den Markt bringen möchte, muss einen langen Atem und viel Geld mitbringen. Die zwei wichtigsten Zulassungsbehörden – die FDA in den USA und die EMA in Europa – verlangen Nachweise dafür, dass das Produkt korrekt funktioniert und dass die Vorteile für die Gesundheit die bekannten Risiken überwiegen.

Keiner zweifelt an, dass eine solche Qualitätskontrolle in der Medizintechnik notwendig ist. Und doch gibt es in letzter Zeit vermehrt Überlegungen, wie der Zulassungsprozess sinnvoller gestaltet werden kann.
Derzeit werden Zulassungen erteilt, nachdem Nachweise über Funktionsweise und Wirksamkeit vollständig erbracht worden sind. Unter dem Schlagwort “adaptive licensing” wird eine Alternative verfolgt, die von einer stufenweisen Zulassung ausgeht. So könnten Medikamente oder Geräte zu einem frühen Zeitpunkt für eine Zielgruppe freigegeben werden, die davon in besonders hohem Maße profitiert und daher bereit ist, auch ein höheres Risiko einzugehen. Im Gegensatz zu klassischen klinischen Studien, in denen nur wenige Probanden zur Verfügung stehen, würde das Produkt unter produktionsnahen Bedingungen getestet werden. Die Herstellung würde unter Serienbedingungen, die Anwendung in verschiedenen klinischen Umgebungen laufen, und die Wirkung könnte anhand einer breiten, repräsentativen Bevölkerungsschicht getestet werden.

Zulassung als lernendes System

Eine solche, frühe Zulassung in begrenztem Umfang würde aus dem Zulassungsprozess ein lernendes System machen, das nicht eine, sondern mehrere Zulassungsstufen mit unterschiedlichen Akzeptanzkriterien kennt. Die Vorteile dieser Herangehensweise liegen auf der Hand: Patienten, die nicht mehr Jahre warten können, bekämen Zugang zu medizintechnischen Innovationen. Hersteller können bereits vor der finalen Zulassung umfangreiche Informationen zu Funktion und Wirksamkeit sammeln und Anpassungen noch während des Entwicklungsprozesses vornehmen. Und die Zulassungsbehörden bekämen mit jeder Zulassungsstufe ein akkurateres Bild davon, ob das Produkt die Anforderungen für die finale Freigabe erfüllt. Dadurch sollte die Anzahl an Recalls (Produkte, die nach der Zulassung wieder vom Markt genommen werden müssen) sinken. Am Ende profitieren alle davon.

Die Reform des Zulassungsverfahrens wird nicht von heute auf morgen geschehen. Doch das hindert uns nicht daran, die Produktentwicklung schon jetzt so zu gestalten, dass eine stufenweise Zulassung im Prinzip möglich wäre. Mit Scrum haben wir eine iterative und inkrementelle Produktentwicklung, mit der das Produktdesign kontinuierlich validiert werden kann. So ist die Prüfung der Machbarkeit kein Konzept mehr, sondern empirisch nachweisbar. Das Produkt ist zu jedem Zeitpunkt auf einem Stand, auf dem es prinzipiell ausgeliefert werden könnte. Projektfortschritte sind nachvollziehbar und der geschaffene Wert lässt sich beziffern.

Der genaue Weg dorthin wird in den nächsten drei Beiträgen genauer beschrieben:
1) Lieferung von Produkt- statt Komponenteninkrementen
2) Aufbau eines cross-funktionalen Teams, damit 1) machbar ist
3) Einsatz von Reviews, um Validierung nach IEC 62366 zu erlangen

Referenz: If everyone hates the FDA approval process, let’s fix it

Related posts:

  1. Scrum | Level of Done | Die Organisation
  2. 5 minutes on regulations – wie gute Prozesse in der Medizintechnik Innovation verhindern
  3. Was Unternehmen die Zukunft kostet

Categories: Blogs

Swarming Resources

Agile Tools - Tom Perry - Sun, 10/05/2014 - 05:34

architecture-books-building-2757-828x550

Here are some of the books and web sites that researched as part of my investigations into swarming. There are a few that I should probably re-read too. That said, if you are interested in swarming, you could use some of these references for starting points.

Books

The Wisdom of Crowds – James Suroweicki

Suroweicki’s book was my introduction to the power of self-organizing groups. He is a very engaging writer. It’s a fun read and serves as a good starting point for further research.

Bioteams – Ken Thompson

The Thompson book is the first that I found that attempts to apply the theory of swarming to teams of people. It’s oriented to the use of mobile devices and does a good job of positing the simple rules that might be used by swarming teams.

Emergence – Steven Johnson

Steven Johnson’s book is similar to Suroweiki’s, but Johnson’s work is more thorough and academic in tone. He does a great job of explaining some very complicated ideas well.

Micromotives and Macro Behavior – Thomas Schelling

 This guy is a nobel laureate in economics, so I guess he knows what  he’s talking about. I loved the introductory chapters, but after that he lost me. It gets really dense really fast.

The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations – Ori Brafman and Rod Beckstrom

I really loved this book. Brafman and Beckstrom did a fabulous job of writing a very engaging book about self-organizing…organizations. This book does the best job of giving you real examples of groups of people swarming.

Swarm Creativity – Peter Gloor

Peter Gloor’s book is mostly focused on swarming as a way of driving innovation in teams. He also examines ways that we can find collaborative networks (COINS) within existing organizations.

Swarm Intelligence: A Whole New Way to Think about Business – Eric Bonabeau and Christopher Meyer

Bonabeau and Meyer have made the transition from academics to business. They take the principles of swarming and apply them to business problems.

Web sites

BioTeams – Companion to the book

Systems Thinking – A catalog of systems theory and emergent behavior links

CalResCo Complexity Writings – a collection of academic papers on emergent and complex behavior

Swarm Theory –  a great Nat Geo article about swarming

Wikipedia article on swarms

Rules for Flocking Behavior

Boids – If you want to play with simulations of swarming behavior, this is a great start

The Science of Biological Swarms

Swarm Creativity – companion site to Peter Gloor’s book

Research Project from the MIT Center for Collective Intelligence

Links on Complexity, Self-Organization and Artificial Life

Swarm Intelligence – more links

NY Times article on swarming


Filed under: Agile, Swarming Tagged: books, online, research, resources, Swarming, web sites
Categories: Blogs

Project Anarchy

Agile Tools - Tom Perry - Sat, 10/04/2014 - 06:23

anarchy-32917_640

Recently I’ve been writing a series of posts on a rather radical methodology that I call Swarming. I describe it as a method that enables individuals to become part of whatever team they like and work on whatever they want. They can follow their passions wherever they choose (in fact they must) without interference or even guidance from a hierarchy (managers, coaches – nobody). I’m quite keen on the ideas, but it occurred to me that what I’m advocating might be indistinguishable from anarchy!

So I hustled over to wikipedia to look up anarchy. Here’s what I found:

The word anarchy comes from the ancient Greek ἀναρχία, anarchia, from ἀνan, “not, without” + ἀρχόςarkhos, “ruler”, meaning “absence of a ruler”, “without rulers”).

Oh my. That is what I’m talking about! One of the fundamental rules of swarming is there is no single controlling entity or “ruler”. So swarming could indeed be described as a form of anarchy by this definition. Now it turns out that anarchy has more than one definition, and in common parlance, the word seems to be mostly associated with the political definition:

Proponents of anarchism (known as “anarchists”) advocate stateless societies based on what are sometimes defined as non-hierarchical organizations, and at other times defined as voluntary associations.

That’s interesting. That is pretty much what I have been advocating. Maybe I am an anarchist after all. But I’m from Seattle, and here in the Northwest we know what anarchists are. We have a bunch of them around here. Anarchists are gangs of masked hooligans that roam the streets and break shop windows whenever the WTO comes to town. They’re a real pain in the ass. I’m not one of those clowns.

However, strangely enough, as I become more experienced with software development projects, the less I find myself trusting traditional management institutions. I yearn for a place that is free of hierarchy (non-hierarchical organizations), where we have the opportunity to pursue whatever tickles our fancy.

But allow me to make this argument: Swarming does have very simple rules. I don’t think of anarchy as having rules, so I don’t believe that Swarming can be called anarchy. Actually there is a variant of anarchism that fits my notion of Swarming rather well: anarcho-syndicalism.

Syndicalists consider their economic theories a strategy for facilitating worker self-activity and as an alternative co-operative economic system with democratic values and production centered on meeting human needs.

Ooh! That’s much more like it! What a mouthful. I especially like the “meeting human needs” part. Wow. So that’s what I am. Damn, I guess Brian Marick was right.

300px-Anarchist_flag.svg


Filed under: Agile, Swarming Tagged: anarchy, freedom, non-hierarchical, politics, Swarming
Categories: Blogs

Scrum Knowledge Sharing

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