Skip to content

Feed aggregator

Awesome Explanation of Why Refactoring is NOT on the Product Backlog!!!

Learn more about our Scrum and Agile training sessions on

From the excellent Ron Jeffries, we have “Refactoring – Not on the Backlog!

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

Kanban should be the default choice for DevOps teams

Xebia Blog - Wed, 08/06/2014 - 15:59

We had a successful workshop on DevOpsDays 2014. Our main point was that Kanban should be the default choice for DevOps teams. The presentation can be downloaded here.

DevOpsDays 2014 was a success

On the 19th, 20th & 21st of June 2014 the second edition of DevOpsDays Amsterdam was held in Pakhuis De Zwijger in Amsterdam. This year I was asked to teach a course there on Kanban for DevOps. At the 2013 edition I also gave a presentation about this subject and it was nice to be invited back to this great event.

With the Open Source mindset in mind I teamed up with Maarten Hoppen en Bas van Oudenaarde. Our message: Kanban should be the default choice for DevOps teams. 

The response to this workshop was very positive and because we received a lot of great feedback I thought I’d share the slide deck. The presentation assumes you are working in an environment where DevOps might work or is already being implemented. 

Main points of the presentation

DevOps is about Culture, Automation, Measurement and Sharing (CAMS). These four values require a way of working that looks past existing processes, handovers and role descriptions. 

The Kanban Method is about looking at your organization in a different way. From a point of:

  • Sustainability: by shaping demand and limiting Work in Progress
  • Service-Orientation: by creating an SLA based on past results and data
  • Survivability: create an improvement mindset in the organization to respond to rapidly changing environments

The three different ways the Kanban Method makes you look at your organization makes it an extremely powerful solution for DevOps.

If you are interested to learn more about the workshop, check out the slides here:

Categories: Companies

Agile Change Artistry - Esther Derby workshop, September

Agile Scotland - Wed, 08/06/2014 - 15:54
Hi everyone, 
And now for something special:  Esther Derby is running a workshop on Change Artistry on the 10th of September as part of the LeanAgileScotland conference.  This is a VERY GOOD opportunity which IMHO you should seriously consider pouncing on NOW.

Categories: Communities

Unit Test Execution in SonarQube

Sonar - Wed, 08/06/2014 - 15:26

Starting with Java Ecosystem version 2.2 (compatible with SonarQube version 4.2+), we no longer drive the execution of unit tests during Maven analysis. Dropping this feature seemed like such a natural step to us that we were a little surprised when people asked us why we’d taken it.

Contrary to popular belief we didn’t drop test execution simply to mess with people. :-) Actually, we’ve been on this path for a while now. We had previously dropped test execution during PHP and .NET analyses, so this Java-only, Maven-only execution was the last holdout. But that’s trivial as a reason. Actually, it’s something we never should have done in the first place.

In the early days of SonarQube, there was a focus on Maven for analysis, and an attempt to add all the bells and whistles. From a functional point of view, the execution of tests is something that never belonged to the analysis step; we just did it because we could. But really, it’s the development team’s responsibility to provide test execution reports. Because of the potential for conflicts among testing tools, the dev team are the only ones who truly know how to correctly execute a project’s test suite. And in the words of SonarSource co-founder and CEO, Olivier Gaudin, “it was pretentious of us to think that we’d be able to master this in all cases.”

And master it, we did not. So there we were, left supporting a misguided, gratuitous feature that we weren’t sure we had full test coverage on. There are so many different, complex surefire configuration cases to cover that we just couldn’t be sure we’d implemented tests for all of them.

Plus, This automated test execution during Java/Maven analysis had an ugly technical underbelly. It was the last thing standing in the way of removing some crufty, thorn-in-the-side, old code that we really needed to get rid of in order to be able to move forward efficiently. It had to go.

We realize that switching from test execution during analysis to test execution before analysis is a change, but it shouldn’t be an onerous one. You simply go from

mvn clean install
mvn sonar:sonar


mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install -Dmaven.test.failure.ignore=true
mvn sonar:sonar

Your analysis will show the same results as before, and we’re left with a cleaner code base that’s easier to evolve.

Categories: Open Source

Hot news for GitHub lovers

tinyPM Team Blog - Wed, 08/06/2014 - 14:35

Finally happened! Over 6 million users & over 14 million repositories of GitHub integrated with tinyPM? It’s more than possible now. Imagine product management integrated with the largest code host on the planet. All in one – from vision to implementation. You absolutely have to check it out!


Why should you try it out?

Integration with GitHub allows you and your team to link commits in GitHub with user stories in tinyPM. This carries your team through the latest development work and the whole history of commits for each story. When you push your changes to GitHub, it will forward your commit to tinyPM offhand. By including a special text in the commit message you can indicate whether this commit is related to a user story or task in tinyPM.

Stay up to date and tie your commits easily to user stories

To enable GitHub integration with tinyPM just activate tinyPM Service in your GitHub repository:

  • In GitHub open a repo you manage and click on Settings
  • Select Webhooks & Services
  • Click Add service and select tinyPM from the available services
  • Add your URL – copy it from the “Application Settings” page in your tinyPM






Linking commits to user stories

Simply include a user story #id in the commit message #512 and the commit will show up on this story card.

Example commit message:


Linking commits to tasks

To add a reference link to a commit, just include a label like task:123 in the commit message.

Example commit message:

Move tasks via commit messages

Add a message like completed task:123 and tinyPM will update the task status when you push your commit.

Example commit messages:


Good day & good luck! :-)


Categories: Companies

Culture Club

Agile Tools - Wed, 08/06/2014 - 09:23








Recently I’ve been challenged by the question, “Can you change culture?” I think this is pretty common for folks who work in large organizations. The question of culture and how it blocks or allows us to get things done is a thorny one. There seem to be two opposing schools of thought in the agile community on the subject of culture:

  1. You can’t change culture, you can only adapt to it (customize your process to fit)
  2. You can change culture (through influence, good looks, and the right practices)

Of course, perhaps the first question is, “What is this culture thing anyway?” Most definitions of culture are terribly vague and in my opinion not especially useful (although, couched in the delightfully hand-wavy  terms of corporate sociology, they usually sound very smart). Just for giggles, here are some definitions:

  • Culture is the accepted norms of behavior for a group
  • Culture is the collection of social contracts that a group depends on
  • Culture is how we treat each other
  • Culture = people

I forget where I saw that last definition (Tobias Mayer?), but it’s probably my favorite of the bunch. You see often culture is used in conversation to hide or excuse problems with people. It’s kind of like referring to employees as “resources” (Ooh! Now I can be that irritating agile guy who corrects people’s terminology! A word to the wise: Don’t be that guy). So where was I? Oh yeah, culture. So here’s the deal, I don’t like the term culture because it’s just too damn vague. Often times I get a lot more clarity if I use more specific terms to describe the problem. For example:

  • Our culture won’t permit us to do that = Manager X won’t permit us to do that
  • Our culture only supports hierarchical decision making = Bob likes to make all the decisions

Once I take the time to replace culture with more specific terms (Who, What, Where, When, Why), I usually find that the problem feels more manageable to me. More human and less onerous. On the one hand, “Our culture” is vague and hard to put strategy around. On the other, influencing Manager X is a simple exercise in winning friends and influencing people. That’s something I know how to do. People I can work with. Culture…not so much.

So if you accept this definition of culture (culture = people), then your ability to change the culture directly depends on your ability to influence people. That’s Dale Carnegie stuff. It’s not easy, but it can be done – one person at a time. When you are in a small company, that’s not too daunting a challenge – win a handful of people over and you are done. However, in a large company, it’s quite a different matter. In a large company you have to win over hundreds or even (heaven forbid) thousands. That’s a very different challenge – and it’s an order of manure…uh…magnitude more difficult. It can be done, but it’s a long term challenge that may take years – and while some strategies you will use with larger groups are the same as for small groups, often they can be very different. If you are accustomed to trying to change the culture in small companies, you almost have to learn a completely new language in order to try and change the culture at large companies.

But seriously, can you REALLY change culture in big companies? One way to answer this question is to look for examples of successful culture change within large corporations. There are one or two that I can think of:

  1. Richard Semler, SEMCO (As described in the book, “Maverick”)
  2. James Collins, “Good to Great” (A series of stories of dramatic corporate change)

If you accept these stories as true, then the answer must be that culture change can indeed happen. But perhaps you are an inveterate cynic (like me) and don’t believe everything you read in books. Maybe culture change is just something that people with extraordinary power can achieve (like CEOs). Then what hope do those of us who exist much lower down in the corporate hierarchy have? Two thoughts:

  1. Sometimes we have to accept that our sphere of influence is limited. Those limitations are things that are very real like geography. You may only be able to influence folks that you work with in your particular office (which makes a lot of sense). Influencing the rest of the organization is going to be much harder. This has nothing to do with culture and everything to do with constraints. Start small, gather your wins, and grow.
  2. You can just wait. Bide your time. Sometimes you have to wait for the right opportunity. How long should you wait? I don’t know. There is an element of patience when dealing with culture change. You need a lot of patience. Focus, prioritize, and be ready. There’s nothing wrong with that approach.

OK Tom, what if I still don’t buy it. My company is HUGE and there is just no way that I can influence these clowns…er…people. No matter what happens, once an organization gets above a certain number (perhaps the Dunbar number) then it becomes extremely difficult to change. So difficult in fact, that it’s just not worth fighting. If that really is the case (and in many cases it just may be), there really are two approaches:

It may be that there are kinds of change that will never be accepted within some organizations. However, usually, that is a relatively small set of invariants. There usually still remains a broad spectrum of change that can be introduced successfully. Just stay away from the hot buttons. Does it really matter that you introduce every single one of the 12 XP practices? Or would it be enough just to introduce a few (there is still some benefit gained). Can you bring change in small amounts rather than a huge batch? There is plenty of room for creativity in this sort of culture change.

In the end, even after all this, you may come to the conclusion that you can’t change the culture in big organizations. Maybe it’s just too hard. Perhaps you just don’t like Dale Carnegie. I don’t know. That may just be the way it is. If that ends up being the case for you, then saddle up Rozinante. Grab Sancho, and go find some more giants to tilt at. The world is full of them.

Filed under: Agile, Coaching Tagged: Agile, change, change management, Coaching, culture, culture change, Dale Carnegie, definition of culture, large organizations, management, Scrum
Categories: Blogs

Timeboxing: Zeitdruck tut gut

Scrum 4 You - Wed, 08/06/2014 - 07:39

Lassen Sie mich diese Aussage entschärfen: 
Zeitdruck in Meetings tut gut, weil es oft um grobe Abstimmung/Synchronisation und nicht um die perfekte Ausarbeitung geht.

Vom guten Gefühl schnell viel zu schaffen

In meiner Abschlussarbeit an der Hochschule habe ich zwei unterschiedliche Prototyping-Prozesse verglichen: Der erste Prozess war detaillierter, mit längeren Phasen für eine genaue Ausarbeitung. Der zweite Prozess war geprägt durch extrem straffes Timeboxing, um eine Iterationsschleife unterzubringen.
Erstaunlich war, dass die Teilnehmer der ersten Gruppe in der anschließenden Befragung überwiegend „mehr Zeit im Prozess wäre für mich hilfreich“ ankreuzten und die Teilnehmer, die dem extremen Zeitdruck ausgesetzt waren sich überwiegend für „mehr Zeit im Prozess wäre für mich nicht hilfreich“ entschieden.
Das Experiment war in keiner Weise repräsentativ, aber dieses Ergebnis gab mir zu denken. Auch in Scrum Teams resultiert die Zufriedenheit u.a. daraus, dass Meetings schnell und effizient abgehalten werden und viel Zeit bleibt, die eigentliche Arbeit zu erledigen.

Timeboxing in Scrum Meetings

Meetings sind teuer, viele gut bezahlte Experten verbringen Zeit zusammen. Es ist offensichtlich, dass schnell Ergebnisse erzielt werden müssen, um diesen Kostenfaktor zu rechtfertigen. Der Scrum Workflow sieht daher Zeitbegrenzungen für alle Meetings vor. Diese Zeitbegrenzungen werden zu Beginn der Meetings kommuniziert, routinierte Teams sind bereits auf das Timeboxing eingestellt. Der Zeitdruck hilft, die Spreu vom Weizen zu trennen, weil die Teilnehmer automatisch ihre Anliegen und periodisieren und die für sie wichtigsten Themen zuerst ansprechen. Aufgabe des Scrum-Masters ist es, zu erspüren, welche Fragen sofort geklärt werden können und welche Abstimmungsprozesse besser in kleinere Zirkel nach dem Meeting verschoben werden sollten.

Ein sehr schönes Werkzeug zum Visualisieren der Restzeit sind TimeTimer. Diese funktionieren wie eine Eieruhr und stellen die verbleibende Zeit mit einer immer kleiner werdenden Farbfläche dar. Die Anschaffung macht sich schnell bezahlt.

Smart Timeboxing

Um Zeitdruck mit Flexibilität zu kombinieren, empfiehlt sich das Smart Timeboxing. Hierbei wird zuerst eine Zeitspanne gewählt, die etwas zu kurz erscheint. Nach Ablauf der Zeit fragt der Scrum-Master die Teilnehmer, ob sie in die Verlängerung gehen wollen. Wird dies bejaht, so wird noch einmal die halbe Zeitspanne der Vorrunde gegeben.

 Für ein Sprintplanning #2 rechnen wir grob mit einer Stunde pro Sprintwoche, bei 2-wöchigen Sprints können wir also 2 Stunden für dieses Meeting veranschlagen. Mit Smart Timeboxing wählen wir für die erste Zeitrunde dieses Meetings nur die halbe Zeit. In dieser ersten Stunde ist es wahrscheinlich, dass wir bereits 80% der Abstimmung im Team schaffen.
 Danach wird gefragt, ob es eine zweite Runde geben soll, die dann nur 30 Minuten dauert:

Erste Zeitrunde im Meeting – 1 Std. 
Frage danach: „Benötigen wir mehr Zeit?“ – „Ja!“
Zweite Zeitrunde im Meeting – 30 Min.
 Frage danach: „Benötigen wir mehr Zeit?“ – „Ja!“
Dritte Zeitrunde im Meeting – 15 Min. 
Frage danach: „Benötigen wir mehr Zeit?“ – „Nein!“

Dieses Sprint Planning mit Smart Timeboxing hat 105 anstelle von 120 Minuten gedauert, und die Teilnehmer haben trotzdem die Zeit bekommen, die sie benötigten. Gewonnen haben wir eine Viertelstunde .

Nicht hetzen, aber Zeitdruck tut gut!

Timeboxing hilft uns und anderen, schnell ins Tun zu kommen und es gibt Teams das gute Gefühl, schnell etwas geschafft zu haben. Weiterhin haben wir durch das Smart Timeboxing Sollbruchstellen in unser Meeting eingeführt, holen uns immer wieder das Commitment des Teams, auch die nächste Zeitrunde fokussiert und produktiv zu verbringen. Wir gewinnen genügend Flexibilität, auch schwierige Fragen ausreichend zu diskutieren und Zeit für die Umsetzung der Ergebnisse aus dem Meeting.

Probiert es aus und berichtet uns von euren Erfahrungen!

Related posts:

  1. ScrumMeetings moderieren oder „ein ScrumMaster hat nichts zu tun“
  2. Klassiker | Sprint Planning
  3. Bericht vom Scrum Meeting

Categories: Blogs

Servant Leadership Model

Agile Complexification Inverter - Tue, 08/05/2014 - 22:17

Do a Google search on "servant leadership" and you will get plenty of hits (2.5 million for me just then). So if you don't know what it is cruise on over to and check out the 21st century "Cliff's Notes" on the topic.

Disclaimer:  as this blog is a from of note keeping for me - an extension of my cognitive model of the universe of knowledge - this article and the series of article may be in great flux until complete (or good enough to quit editing).

Greenleaf's enlightenment of Servant Leadership stems from his reading of  Hermann Hesse's short novel, Journey to the East. "Hesse's story is an account of a mythical journey by a group of people on a spiritual quest where the recognition of the true leader of the group takes place as a result of his acts of service and self-sacrifice for the benefit of the whole group. As Spears tells it, upon reading this story, it seemed suddenly clear to Greenleaf that a 'great leader is first experienced as a servant to others, and this simple fact is central to his or her greatness ... true leadership emerges from those whose primary motivation is a deep desire to help others' " (3).

I find it troubling that in Hesse's story the servant leader, Leo, abandons the group and it disbands, failing in it's quest to find the ultimate truth.  Our hero of the story later searches and finds Leo, and it turns out that Leo is the leader of the "League" which sat about to test the group's faith with the journey.  So is this parable to be emulated, do we wish our servant leader's to test and abandon us when we fail?

I do however like the concept of a leader as servant to the followship and the purpose.  I think we should make our diagrams and models reflect this by placing the leaders at the bottom of the diagrams (org charts) with their actions and behaviors supporting the team (followship) within the context of their shared purpose.

This orientation was done on some of the first Org Charts by the railroad.

See Also:

A Review of Leadership Models


1) Leadership Theory and Practice - 6th Ed. by Peter Northouse.

2) Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness - 25th Ann. Ed. by Robert Greenleaf

3) The Myth of Servant-Leadership: A Feminist Perspective by Deborah Eicher-Catt
Categories: Blogs

Scrum Basics: When Should We Schedule Sprint Transitions?

Agile For All - Bob Hartman - Tue, 08/05/2014 - 17:34

We’re often asked which day or days are best for scheduling the Sprint Planning, Review, and Retrospective meetings.

In general, we prefer mid-week sprint transitions. People are most likely to take Monday or Friday off, so it’s easier to get the whole team reliably on Tuesday, Wednesday, or Thursday. Having a couple days to get started with the work for a new sprint and to build some momentum is nice, so I like planning on Wednesdays.

For a one week sprint, it’s possible to do Review, Retrospective, and Planning all on Wednesday morning. Or, you can do the Review and Retrospective in the morning, take a break to reenergize and to build the feedback from the previous meetings into your Product Backlog, and then plan in the early afternoon.

For a two or three week sprint, Review and Retrospective on Tuesday afternoon and Planning on Wednesday morning works well. With longer sprints, the meetings take proportionally longer; I find it useful to break them up across multiple days to maintain energy.

As with anything else in Scrum, you can make this an experiment. Make a hypothesis about what you expect to happen, try something for a while, and adapt if you’re not getting the results you like.

The post Scrum Basics: When Should We Schedule Sprint Transitions? appeared first on Agile For All.

Categories: Blogs

Scaling Scrum - What People Are Not Talking About!

Scrum Log Jeff Sutherland - Tue, 08/05/2014 - 16:42
Me and Dean Leffingwell  with a copy of my new book
There was a lot of talk about scaling Scrum at Agile 2014. Here's a photo of Dean Leffingwell, creator of the Scaling Agile Framework aka SAFe, and me. People have a lot of opinions about scaling frameworks. Some love them. Some hate them. Alex Brown and I presented a way to think about scaling that would apply to any framework (or lack thereof).

The interest in scaling shows that Scrum is not just about pilot projects any more. It is implemented widely across companies and managers need to start dealing with it as their major responsibility - making their company agile. So they want to know all the details about what they need to do. And they keep on wanting to add things to Scrum to make it more agile. When I ask them "How is that working for you?" they tell me how hard it is to implement Scrum.

What is most interesting to me is what they don't talk about. Scaling Scrum means getting rid of stuff because everything in Scrum is just in time and just enough. Here are a few things that companies are getting rid of.

1. Microsoft is getting rid of test teams

Scrum means you deliver working software in short intervals. That means all testing is completed as part of development so you have shippable code. If testing slides out of a sprint and is done later we have found in the U.S. and Europe that for complex products it takes 24 times as long to test outside a sprint as inside a sprint. And the best companies today are doing continuous deployment, something we started at PatientKeeper a decade ago. delivers 220 releases to production every two week sprint. Hubspot does 170 live production updates on a slow day. Google has 15,000 developers working on one code branch and runs 75 million automated tests a day. Even Microsoft has a 3000 person Scrum that delivers a production release of all development tool products at the end of every three-week sprint. Testing is core Scrum in these companies.

2. Spotify got rid of DevOps and dependencies between teams

Operations was slowing deployment so Spotify decided to have the teams do all deployment. All teams upgrade their component of the live system at the end of every sprint. And now they are moving to continuous deployment. They still have agile operations teams that provide tools and advice while staying out of the way.

In order to deploy faster, Spotify got rid of dependencies between teams so that they could be as autonomous as possible. Remaining dependencies they identify and manage carefully.

3. Systematic got rid of management meetings

A CMMI 5 company, Systematic delivers Scrum projects at half the cost of their waterfall projects. Customers have a choice. But Systematic is Scrum top to bottom with almost 2000 people, including the senior management team. At the beginning of last year, their senior management Scrum did a cost benefit analysis of all their meetings, which showed that only the standard Scrum meetings had a value which exceeded the cost. So they banned all meetings that were not Scrum meetings.


This is just the beginning of stuff to get rid of because any extra weight slows you down and increases cost. That's why, as a former fighter pilot, I really like the Saab Gripen. Every six months they use Scrum to build a new release of the jet aircraft operating system with new hardware that makes it faster, cheaper, lighter, more efficient, more powerful, with better electronics and more sophisticated targeting. Aviation week calls it the best aircraft in the world and Janes Defense Weekly calls it the cheapest aircraft in the world.

Getting lean is always the hard part. To get there, the best book I've read for agile managers is Musashi's Book of Five Rings - how the world's best swordsman won every fight he ever fought. A close second is Certain to Win: The Strategy of John Boyd, Applied to Business. Boyd was the world's greatest fighter pilot who won every battle in under 40 seconds. Scrum Inc.'s Alex Brown also has an in-depth workshop on Agile leadership.

Agile means faster, better, cheaper, cooler. So throw that old ballast off the boat when scaling and turn Scrum from slow, hard, and painful into fast, easy, and fun!

-- Jeff Sutherland

Categories: Blogs

Full-Day Product Owner Simulation Exercise

Learn more about our Scrum and Agile training sessions on

This simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it.  My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise.  It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class.  I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.

NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!

Pre-requisites: None!  No prior Scrum or Agile knowledge or experience required.

Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.

Timing: This simulation takes at least 7 classroom hours.  I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.

Materials Needed:

  • Coloured pencils and/or coloured markers
  • Black Sharpie fine-point markers
  • Scissors
  • Rulers
  • Scotch tape and/or glue stick
  • Blank white printer paper
  • Pencils, erasers, pencil sharpeners
  • Blank white 4×6 and 3×5 note cards
  • Blank white box (e.g. a shirt box from U-Line)
  • Planning Game cards (email me if you want a bunch for free!)

Room Setup: Round tables with 4 to 6 chairs at each table.  Materials distributed to each table.

Agenda (with facilitator’s notes):

  • Lecture: Simulation Overview, Backlog Preparation and Refinement
    The purpose of the overall simulation is to learn to create a good Product Backlog in preparation for a Scrum team’s first Sprint. Review the agenda with participants.
  • Discussion: Choosing a Product for the Simulation
    Give participants four product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons”, “POS for food trucks with social features”, or come up with your own app idea).  A table group must agree to one of the options.  They will stick with this product for the remainder of the simulation.  5 minutes to decide (usually takes much less).
  • Part 1: Product Vision
    • Lecture: Innovation Games – Product Box
      Talk about the need for a compelling vision as a pre-requisite for high-performance teams, and a way to decide what is in vs. out of a Product Backlog.  Introduce “Product Box” as a way to do market research in an Agile compatible way (collaborative, light documentation, quick).  Talk about the pattern of a product box: front to attract, back to showcase, sides to deal with objections.  Use of online resources / web research is allowed but should not dominate the exercise.
    • Exercise: Building Your Product
      30 minutes, with warnings at 15 minutes and 5 minutes remaining.  Ensure that by 10 minutes in, the group has actually started using the craft supplies and isn’t just talking.
    • Exercise: Presenting Your Product
      5 minutes – give additional time to allow groups to prepare for a trade show (in their market) presentation where other groups (or yourself) will role-play sceptical trade show participants.
    • Discussion: Debrief
  • Part 2: Product Users
    • Lecture: User Categories
      Describe “end users”, “customers” and “admin users” as the three major categories.  Users can be in hierarchies where a general user type may have two or more specific sub-types.
    • Exercise: Identifying Users
      10 minutes.  One user of each main type (end, admin and cust), at least 5 users in total.  More is okay.
    • Lecture: Personas, Usability and Empathy
      Introduce Persona concept (great reference: “The Inmates are Running the Asylum” by Alan Cooper).  Usability as part of Agile, not separate (i.e. “working software”).  Identifying personas as a way to build empathy from the development team to the end users/customers.
  • Part 3: User Stories
    • Handout: User Stories and Splitting
    • Lecture: Writing Effective User Stories
      Use the example “As a Job Seeker, I can upload my resume, so that I get a job.”  Explain the user story template based on the handout.  Emphasize the idea of end user functionality.  Explain user stories as an important tool, but optional part of Scrum.
    • Exercise: Create User Stories
      Goal: 20 user stories for each group’s product, at least two user stories for each type of user, all done in 20 minutes.  User Stories must be written on 3×5 note cards with a 2cm blank area on right side of each card.
    • Discussion: Review User Stories
      Workshop examples from each group.  Ensure that the “benefit” section of each story does not contain a feature.
    • Lecture: Splitting User Stories
      Go through each of the “top” six splitting methods.  Provide simple examples where the group needs help.  E.g. error conditions as an example of splitting by business logic.
    • Exercise: Split Some
      Goal: result in at least 30 user stories, use each of the top six splitting methods at least once, give 15 minutes.
    • Discussion: Review Splitting
  • Part 4: Estimation and Financial Modelling
    • Lecture: Effort, Value and ROI
      Customers and business stakeholders estimate value, Scrum team members estimate effort, and ROI is the calculation of the ration of value over effort.  Discuss examples of ordering based on these ratios, e.g. 8/2 vs. 8/4 and 200/20 vs. 20/2.
    • Handout: The Bucket System
    • Lecture: The Bucket System
      Review process based on handout.
    • Exercise: Estimating Business Value
      10 minutes.  Goal: all user stories get a business value estimate written in the top right-hand corner of the user story card.
    • Discussion: Debrief the Bucket System
    • Handout: The Planning Game
    • Lecture: The Planning Game
    • Exercise: Estimating Effort
      20 minutes. Goal: estimate 3 user stories using the Planning Game.  Use the Bucket System to estimate the remainder with the ones already estimated as the reference points.
    • Discussion: Debrief the Planning Game
    • Handout: Methods of Ordering the Product Backlog
    • Lecture: Ordering a Product Backlog
      Review ROI as a method to order the PBIs.  Reminder that the Product Owner has final authority and can ignore the estimates in deciding on the order.
    • Exercise: Calculating ROI and Ordering
      5 minutes.  Just simple divide-and-conquer calculations of business value divided by effort for all the user stories.
    • Lecture: Simulation Wrap-Up – Where Does This Fit?
      Reminder of the idea of creating an initial Product Backlog that is “good enough” to start the first Sprint.

NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!

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

Agile & UX: What’s wrong with working one sprint ahead?

Growing Agile - Tue, 08/05/2014 - 14:14

Let me start this post by saying I am not a UX expert in anyway, however we have been chatting to Flow Interactive recently about how agile and UX fit together. There seems to be a common pattern that UX runs one sprint ahead. Flow have had great success doing this, but when we heard about the idea it sounded a little mini-waterfallish to us. This blog post is an attempt to explain that gut feeling, and to mention some ideas of how this might work different, all shameless stolen from a nice chat with Adrian Howard  Whats wrong with working one sprint ahead?

Working one sprint ahead or behind sounds familiar. Testing used to work one sprint behind, until they found ways to automate testing, test earlier and test smaller chunks. Business Analysts used to (and maybe some still do) work one sprint ahead writing specs and designing solutions. I’d like to think most now see this isn’t optimal and can in fact be done in the same sprint if you learn how to slice work smaller. So hearing about UX working one sprint ahead, just sounds like a discipline still finding a way to work in smaller pieces.

 Whats wrong with working one sprint ahead?

What’s wrong with working one sprint ahead?

The main issue with this is one of focus. If the UX designers work one sprint ahead of the rest of the team, then the UX designers and the team actually never work on the same stuff at the same time. This means they are never focused on the same thing. When this is true a couple of things can happen:

  1. It doesn’t make sense to have the same standup meeting because you aren’t working on the same stuff.
  2. It’s harder to help each other out because you are focused on finishing different stuff
  3. The people working ahead consider their deliverable some interim artefact, not working software, so there is a handover of both knowledge and responsibility.
  4. People don’t see themselves as part of the same team, so you end up having a UX team and a dev team. This inhibits collaboration and communication.
  5. The people working behind aren’t involved in the decision making that happened without them and as a result they don’t understand the reasons for certain design choices, this often leads to assumptions, and rework.
  6. Okay, but we can’t start coding before we know what go build?

I’m not advocating writing code before an UX work has taken place. I’m saying the whole team should be involved in that work. Obviously the UX designer(s) take the lead here, but everyone on the team needs to see users use their product and understand the user journey map. If the rest of the team is busy with other deliverables this can’t happen.

So how can we do this?

I remember when business analysts ran one sprint ahead getting the requirements and specs ready for the sprint. I’ve solved this by having more backlog grooming or refinement sessions with the whole team, and yes that does happen a sprint ahead. i.e. in sprint 1 we refine stories for sprint 2. However we do it but allowing a percentage of time in the current sprint to be spent preparing for future sprints. This means everyone can get involved. The analyst might take point and run the session, but the whole team understands the requirements and decisions made before the sprint starts.

I think UX can be tackled in the same way. In each sprint the whole team should set aside time to look at UX designs for the next sprint, as well as usability testing whatever has been completed. Adrian mentioned that a great way to do this is to have users available every week for a few hours. The team can decide how best to make use of the users the day before, either run a usability test, or interview them about a new idea, or show them paper prototypes. This can significantly reduce the time delays in recruiting users when you need them.

Why is this better?

Like with agile testing, if testers are involved right from the beginning they can ask “how can we test that” early and often prevent bugs. Similarly having developers involved with UX design they might advise when something is difficult to build. They will also understand which parts of the design are crucial because of user feedback, and are then much more likely to implement a solution that adheres to these designs. I believe this will result in less rework, and better designed products, as well as more collaborative teams.

Categories: Companies

Insights at Agile 2014, Part III: Lean-Agile Development, 3rd Generation Agile

NetObjectives - Tue, 08/05/2014 - 07:57
The thinking that got us here won’t get us where we need to be. - Einstein This Blog Post in a Nutshell This blog is a culmination of some ideas that started at Agile 2013 and was presented in an open jam session in Agile 2014. Product developers should adopt a Lean mindset.They can then look at their situation, ask a few questions, and decide on the particulars of the development process...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Egal, was es ist: Ich war’s nicht!

Scrum 4 You - Tue, 08/05/2014 - 07:31

Scrum ist großartig. Entscheidungen werden dort getroffen, wo die größte Kompetenz liegt. Nur was, wenn mein Team das gar nicht so großartig findet? Wenn die Teammitglieder lieber tun, was man ihnen sagt? Dann sind sie hinterher, falls etwas schief geht, wenigstens nicht schuld. Schuldkultur führt zu Pflichterfüllung statt Verantwortungsübernahme. Wenn ich das als ScrumMaster erkannt habe, wie kann ich dann damit umgehen? Wie schaffe ich es, meinem Team Mut zu machen, selbst Entscheidungen zu treffen?

1. Rahmen schaffen Sicherheit

Je größer das Sicherheitsbedürfnis, desto enger sollte der Rahmen sein, um kleine Entscheidungen mit geringfügigen Konsequenzen treffen zu können. Mit der Erfahrung kommt das Vertrauen. Das Vertrauen liegt übrigens auf beiden Seiten: Bei demjenigen, der Verantwortung übernimmt ebenso wie bei dem, der Kontrolle abgibt.

Jeder ScrumMaster kennt die Situation am Anfang einer Scrum-Einführung: Im Daily stehen alle Teammitglieder in einem großen Sicherheitsabstand zum Board, niemand will etwas sagen müssen.
Durch die 4 Fragen

  • Was hast Du gestern erledigt?
  • Was wirst Du heute tun?
  • Gibt es etwas, das Dich behindert? und
  • Brauchst Du Unterstützung oder kannst Du jemanden unterstützen?

geben wir dem Daily einen engen Rahmen. Die Teammitglieder haben nicht viel eigenen Gestaltungsspielraum. Es entsteht umso mehr Vertrauen, je häufiger Dailies gemacht werden. Der ScrumMaster macht die Erfahrung, dass das Team die 15 Minuten nutzt, um sich auszutauschen. Beim Team entsteht das Vertrauen, dass der Termin nicht dazu gedacht ist, sie zu kontrollieren. Ebenso wie im Beispiel ‘Daily’ funktioniert das mit dem Scrum-Framework als Ganzes. Der feste Rahmen gibt den benötigten Freiraum.

2. Schulddiskussionen rigoros unterbinden

Es ist wichtig herauszustellen, dass die Frage, wer schuld ist, gänzlich uninteressant ist. Jedwede Diskussion der Schuldfrage muss vom ScrumMaster sofort unterbrochen werden. Für eine konstruktive Analyse der Ursachen bieten sich die 5-Warums und die Fischgräten-Analyse an. Die Erfahrung, nicht vorgeführt zu werden, wenn etwas nicht wie erwartet funktioniert hat, schafft Vertrauen.

Mein persönlicher Erfolg war, als eines Tages ein Kollege sagte: „Da standen drei Leute aus drei verschiedenen Abteilungen vor dem Gerät zusammen, und statt wie früher drei Tage lang darum zu streiten, wer schuld ist, haben wir innerhalb von ein paar Stunden eine Lösung erarbeitet.”
Lächeln auf den Gesichtern. Stille Freude und Stolz, dass sie es geschafft haben, die lästige Schuldfrage hinter sich zu lassen.

Related posts:

  1. Scrum Rollen: ScrumMaster | Robin Hood
  2. Was macht Scrum Teams eigentlich hyperproduktiv?
  3. Die Skills eines guten ScrumMasters

Categories: Blogs

Project Management with Kanban (Part 2) - Sequencing Policies

In this second in my series of posts exploring project management with Kanban, I'd like to look at how we build a project schedule.

We prefer not to use the term "prioritization" with Kanban because prioritization isn't something done once or periodically leading to a prioritized list, instead prioritization is done dynamically each time an item is pulled through our kanban system. Prioritization isn't an activity in Kanban, it is a consequence of decisions made dynamically based on the risk profile of available work when a pull signal is generated in the kanban system.

read more

Categories: Companies

The Agile Reader – Weekend Edition: 08/04/2014 - Kane Mar - Mon, 08/04/2014 - 08:53
Categories: Blogs

Agile 2014 – Stuck in Shu – Time to Change How to Teach Scrum

NetObjectives - Mon, 08/04/2014 - 07:55
It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. - Mark Twain  The problem ain't what people know. It's what people know that ain't so that's the problem. – Will Rogers  A man who carries a cat by the tail learns something he can learn in no other way. Mark Twain There are three kinds of men. The ones that learn by readin’. The few who learn...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Die vier Spielfelder der Teamkommunikation

Scrum 4 You - Mon, 08/04/2014 - 07:51

Agile Teams organisieren ihre Prozesse, Strukturen und ihre Performance über ein hohes Maß an Kommunikation. Kurz gesagt, Selbstorganisation ist gleich Kommunikation. Für die Führung agiler Teams, ob disziplinarisch oder lateral, gehört das Initiieren und Gestalten von funktionalem, aber auch sozialem Austausch zu den zentralen Aufgaben. Die verschiedenen “Spielfelder”, die für die interne Teamkommunikation relevant sind, müssen im Auge behalten und bei Bedarf aktiv entwickelt und gesteuert werden.

Teamkommunikation findet grundsätzlich auf zwei Ebenen statt. Zum einen auf der sachlich-fachlichen und zum anderen auf der emotional-sozialen Ebene. Beide können natürlich nicht wirklich unabhängig voneinander betrachtet werden, sie wirken in der Praxis permanent aufeinander ein. Es zeigt sich jedoch in den Teamprozessen, dass im Alltag situativ unterschiedliche Schwerpunkte zu erkennen sind und die vier Spielfelder durchaus unterschiedlich gut funktionieren können. Folgendes Modell kann für Teamentwickler und Führung eine Folie zur Analyse und Intervention bezogen auf die komplexe Teamkommunikation sein.

Im Mittelpunkt von selbstorganisierter Teamarbeit steht naturgemäß das Feld Fachinformation und Austausch - im Sinne von fachlichen und organisatorischen Absprachen, gegenseitigem Lernen. Kommunikation in diesem Feld entscheidet wesentlich über die Performance des Teams. Probleme können dann entstehen, wenn es im Team Wissensmonopole gibt, wenn nicht genügend Zeit für den Austausch zur Verfügung steht oder sich genommen wird, unklare Botschaften gesendet werden, z.B. zu viel E-Mail statt direkter Austausch, etc.

Entwicklungsfragen zu diesem Feld sind u.a.:

  • Wie wird mit Bring- und Holschuld von wichtigen Infos umgegangen?
  • Wie sind die fachlichen Informationen im Team verteilt?
  • Ist der Informationsfluss geregelt und gut strukturiert (z.B. Daily Scrum)?
  • Wie sind die Zugänge zu sachlichen Informationen für jeden?
  • Wie funktioniert fachliche Kommunikation horizontal und vertikal?
  • Wird genügend kommuniziert damit alle voneinander lernen können?

Das Feld Auseinandersetzung ist gekennzeichnet von hoher, z.T. unkontrollierter,
Emotionalität. Es steht in der Regel für ungelöste, eskalierende Konflikte und deren
Dominanz über die sachliche Kommunikation. Die eigentliche Arbeit wird partiell aus den
Augen verloren, es droht Schwächung der Leistung. Es kommt zu Koalitionen, die intensiv
miteinander kommunizieren und sozialem und kommunikativem Ausschluss von
einzelnen oder Teilgruppen usw. Es kann aber auch sein, dass Auseinandersetzungen
zu stark vermieden werden, Harmonie über alles gestellt wird. Das bedeutet oft
Stagnation und Mittelmaß, bzw. die Gefahr unvermittelter Eskalationen.

Entwicklungsfragen zu diesem Feld sind u.a.:

  • Wie aggressiv, wie eskaliert ist die emotionale Kommunikation untereinander?
  • Wer kommuniziert wie, mit wem und worüber ?
  • Wie stark ist die Leistung des Teams betroffen, eingeschränkt?
  • Welche Interessen stehen gegeneinander?
  • Wie hoch ist die Gesprächsbereitschaft untereinander noch?
  • Welchen Anteil an der Kommunikationen haben die persönlichen Befindlichkeiten?
  • Wird nur angegriffen oder werden auch gemeinsame Lösungen gesucht?
  • Braucht das Team evtl. Unterstützung zur Konfliktklärung?
  • Hat das Team zu wenig Mut, bzw. Kompetenzen zu Konfliktbewältigung?
  • Müssen Auseinandersetzungen auch mal bewusst provoziert werden?

Das Feld Small Talk definiert die entspannte, beziehungsorientierte Kommunikation im Team. Hier wird über Privates und Alltägliches gesprochen und soziales Miteinander gepflegt. Small Talk ist wichtig für den Abbau von Stress und das persönliche Kennenlernen auf einer nicht leistungsbezogenen Ebene. Und ein oft unterschätztes Element von Teamgeist und Wir- Gefühl. Probleme können hier eigentlich kaum auftreten, höchstens wenn zu viel oder zu wenig Small Talk läuft.

Entwicklungsfragen zu diesem Feld sind u.a.:

  • Ist genügend Zeit für diese Art der Kommunikation?
  • Wird in den Pausen nur über die Arbeit gesprochen?
  • Fördere oder behindere ich als Führung Small Talk?
  • Gibt unsere Unternehmenskultur dafür Räume, dürfen wir das?
  • Sind möglichst alle eingebunden, wenn nein, wer nicht und warum?
  • Gibt es auch außerhalb des Unternehmens Räume für das Zwischenmenschliche?
  • Feiern wir uns und unsere Erfolge angemessen?

Spannend ist das Feld des Dialogs. Hier kommuniziert das Team im kooperativen Dialog und bearbeitet gemeinsam vor allem komplexe fachliche Probleme und innovative Themen. Dieses Spielfeld heißt, in unterschiedlichen Meeting- und Workshop-Formaten zu kommunizieren und sich mit positiver Emotionalität, Engagement für das Ganze und hoher Fachkompetenz einzubringen. Dialog heißt Austausch auf höchstem Niveau und immer mit dem Fokus auf der Sache. Probleme können hier mangelnde Dialogbereitschaft, “Kopfmonopole”, schlampige Meetings, fehlende Methoden, zu wenig Beteiligung u.a. sein.

Entwicklungsfragen zu diesem Feld sind u.a.:

  • Sind alle im Team dialogfähig und -willig?
  • Wie leben wir tatsächlich unsere Meetingkultur?
  • Sind Meetingregeln und Strukturen vorhanden und effektiv umgesetzt?
  • Haben wir wirkungsvolle Methoden und Techniken?
  • Sind alle oder zumindest die meisten mit Engagement und Herzblut dabei?
  • Haben wir Spaß und Freude an gemeinsamer, kreativer Problemlösung?
  • Wie treffen wir im Team Entscheidungen? Sind wir darin effektiv?
  • Werden Ergebnisse und Maßnahmen committet und nachhaltig umgesetzt?
  • Kümmern wie uns um angemessene Kontrolle?

Diese vier Felder kennzeichnen die komplexe und anspruchsvolle Vielfalt der Kommunikationsprozesse in selbstorganisierten Teams. Weit mehr als in konventioneller Teamarbeit sind alle im Team aufgefordert, diese vier Felder optimal mitzugestalten und zu entwickeln. Führung als funktionales Mitglied des Teams sollte sich hier schwerpunktmäßig als Moderator, Impulsgeber und konstruktiv-kritischer Beobachter verstehen und sich entsprechend einbringen. Das heißt, Feedback geben, ggf. Trainer sein, Rahmenbedingungen schaffen, Impediments aus dem Weg räumen.
Wie im Fußballspiel: Auf dem Platz spielt dasTeam, in der Kabine agiert der Coach.

Wie geht das – die Kommunikation im Team fördern und gestalten? Antworten darauf gibt es im Training “Team Booster” mit Dieter Rösner – alle Infos hier

Related posts:

  1. Scrum mit verteilten Teams | Jeff Sutherlands Paper and Talk
  2. 5 min on Scrum | Small Project(s) (-teams)
  3. Die wertvolle Meetingzeit sinnvoll nutzen, effektiv kommunizieren (Teil 1)

Categories: Blogs

Why Many of Us Blindly Follow a Community After Initial Success

NetObjectives - Mon, 08/04/2014 - 07:29
I had forgotten the second half of this amazing quote from R. Buckminster Fuller. Operating Manual for Spaceship Earth "I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Knowledge Sharing

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