Skip to content

Feed aggregator

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

Suggest a Valuable Rule, Win a SonarQubeT-Shirt

Sonar - Wed, 10/08/2014 - 11:58

Is there a rule you’d like to turn on in SonarQube, but you just can’t find it? Well, wish no more, just tweet your missing rule and if its valuable, we’ll implement it.

With coverage of more than 15 languages, developing our own source code analyzers to deliver the most valuable coding rules and bug detection mechanisms is a key mission at SonarSource. In the past, we’ve mainly worked to offer better covererage of rules offered by other rule engines like JSLint, PMD, Toad, CodeSniffer, PHPPMD, CPPCheck, and so on. But the time has come to fly, and now we’d like to know what rules you’re dreaming about.

How to participate

To participate, just tweet the title of your rule and a link to a short description using the tags #1rule1tshirt. If we like it:

  • We’ll add this rule to our Rule Repository, the well from which all new SonarSource rules are drawn.
  • We’ll send you a SonarSource t-shirt.
  • And obviously we’ll do our best to implement this rule and make it available quickly.

That’s it !

Really want few additional details ?
  • The rule can target any language currently covered by SonarSource: Java, C/C++, JavaScript, C#, COBOL, Objective-C, Python, PL/SQL, PHP, ABAP, Android, Flex, Groovy, HTML, PL/I, RPG, VB.Net, XML.
  • You can use whatever’s convenient to host the rule description, such as a Google doc to provide a short description of the rule.
  • The goal of the rule can be either to reinforce a coding practice or to detect some bugs.

Whether or not a rule is valuable is subjective. Like any benevolent dictator, ours will be the final word. :)

Let the tweeting begin!

Categories: Open Source

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 - 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

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

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

Why does Agile Obsess about Product Features being 100% Done?

BigVisible Solutions :: An Agile Company - Tue, 10/07/2014 - 15:38

High functioning agile teams are able to complete stories in an iteration. Newer teams struggle, with stories spilling over from iteration to iteration. Why does this matter? Well, focusing on things being done is an effective approach to risk management. When something is 100% done, you’ve eliminated some risk associated with the development of your […]

The post Why does Agile Obsess about Product Features being 100% Done? appeared first on BigVisible Solutions.

Categories: Companies

Product Owner Decision Making

Growing Agile - Tue, 10/07/2014 - 14:11

The most important thing a Product Owner needs to do is say NO. If they don’t it results in a huge backlog with lots of items, and usually pressure to deliver more than is realistically achievable.

Many people fail to realise that Scrum is not about building the same stuff faster. The Chaos report tells us that 60% of features are never or rarely used. The point of Scrum is to identify this 60% early and to not build them in the first place. If you do this, you have doubled your productivity by doing nothing except saying no.

I drew the following PO decision tree to help new PO’s understand how often they need to say no.



PODecisions Product Owner Decision MakingIf you are still not convinced that you need to say no, here is a simple exercise based on queuing theory:

Cycle time (the amount of time customers wait for a requested item) is related to the length of the queue. Think about grocery shopping or the bank. The longer the queue, the longer you have to wait right?

What happens for you when you wait in a long queue? Do you enjoy it? I usually start tweeting about how poor the service is icon wink Product Owner Decision Making

At this point I’m hoping you agree – a short queue is a good idea.

Now consider your current queue. Either your backlog, or your ticketing system, or your bug tracker – whatever holds the list of all the work your team needs to do.

  1. What is the current size of that queue (open or in progress items)?
  2. What is the input rate. i.e. how many new items are created each month?
  3. What is the output rate i.e. how many items are closed each month?
  4. What will your queue look like in 6 months time
Let’s take an example.

Imagine your ticket system currently has 1000 items open. 100 tickets are opened per month and 50 are closed each month.

In six months time your queue will be 1000 + (100 – 50)*6 = 1300

That means customers will be waiting even longer. On average they will wait 26 months for their ticket to be solved! (queue size / output rate) Chances are they won’t be a customer anymore after that amount of time.

What if you only wanted customers to wait max 1 month?

In this example, you would need a max queue size of 50 (monthly output rate).

If you wanted your queue size to be 50 in six months time, what would you need to do? For the sake of this example you can’t just throw more people at it. (And usually that is not an answer).

You would need to say no to some requests.

How many would you have to say no to?

Currently you have 1000 requests. You will get another 600 in the next 6 months, so in total you have 1600 requests.

Your team can do 300 requests in 6 months, and you will allow 50 to be in the queue. So you can accept 350 requests.

You need to say NO to 1250 out of 1600 requests, or 78% !!!

You might think this is unrealistic, but what is unrealistic is believing that you can service 1600 requests. Don’t fool yourself or lie to your clients. Start saying no, so that you can say Yes to the 20% of the work that is essential to your customers and products.

Categories: Companies

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

Why 'Why' Is Everything

Xebia Blog - Mon, 10/06/2014 - 21:46

The 'Why' part is perhaps the most important aspect of a user story. This links to the sprint goal which links ultimately to the product vision and organisation's vision.

Lately, I got reminded of the very truth of this statement. My youngest son is part of a soccer team and they have training every week. Part of the training are exercises that use a so-called speedladder.


After the training while driving home I asked him what he especially liked about the training and what he wants to do differently next time. This time he answered that he didn't like the training at all. So I asked him what part he disliked: "The speedladder. It is such a stupid thing to do.". Although I realised it to be a poor mans answer I told him that some parts are not that nice and he needs to accept that: practising is not always fun. I wasn't happy with the answer but couldn't think of a better one.

Some time passed when I overheard the trainers explaining to each other that the speedladder is for improving the 'footwork', coordination, and sensory development. Then I got an idea!
I knew that his ambition is to become as good as Messi :-) so when at home I explained this to my son and that it helps him to improve feints and unparalleled actions. I noticed his twinkling eyes and he enthusiastically replied: "Dad, can we buy a speedladder so I can practise at home?".  Of course I did buy one! Since then the 'speedladder' is the most favourable part of the soccer training!


The goal, purpose and the 'Why' is the most important thing for persons and teams. Communicating this clearly to the team is one of the most important things a product owner and organisation need to do in order to get high performant teams.

Categories: Companies

Agile Enablement: Leadership Everywhere is Essential for an Agile Organization

BigVisible Solutions :: An Agile Company - Mon, 10/06/2014 - 20:19

Leadership is an essential ingredient for a high-performing, self-organizing agile team, but not necessarily in the way leadership is traditionally envisioned, with a designated individual providing the leadership. On agile teams, leadership is expected of all team members. This is a relatively new and potentially challenging idea to grasp, but once mastered can lead to […]

The post Agile Enablement: Leadership Everywhere is Essential for an Agile Organization appeared first on BigVisible Solutions.

Categories: Companies

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

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.