Skip to content

Feed aggregator

Conceptual Model vs Graph Model

Mark Needham - Mon, 10/06/2014 - 09:11

We’ve started running some sessions on graph modelling in London and during the first session it was pointed out that the process I’d described was very similar to that when modelling for a relational database.

I thought I better do some reading on the way relational models are derived and I came across an excellent video by Joe Maguire titled ‘Data Modelers Still Have Jobs: Adjusting For the NoSQL Environment

Joe starts off by showing the following ‘big picture framework’ which describes the steps involved in coming up with a relational model:

2014 10 05 19 04 46

A couple of slides later he points out that we often blur the lines between the different stages and end up designing a model which contains a lot of implementation details:

2014 10 06 23 25 22

If, on the other hand, we compare a conceptual model with a graph model this is less of an issue as the two models map quite closely:

  • Entities -> Nodes / Labels
  • Attributes -> Properties
  • Relationships -> Relationships
  • Identifiers -> Unique Constraints

Unique Constraints don’t quite capture everything that Identifiers do since it’s possible to create a node of a specific label without specifying the property which is uniquely constrained. Other than that though each concept matches one for one.

We often say that graphs are white board friendly by which we mean that that the model you sketch on a white board is the same as that stored in the database.

For example, consider the following sketch of people and their interactions with various books:

IMG 2342

If we were to translate that into a write query using Neo4j’s cypher query language it would look like this:

CREATE (ian:Person {name: "Ian"})
CREATE (alan:Person {name: "Alan"})
CREATE (gg:Person:Author {name: "Graham Greene"})
CREATE (jlc:Person:Author {name: "John Le Carre"})
CREATE (omih:Book {name: "Our Man in Havana"})
CREATE (ttsp:Book {name: "Tinker Tailor, Soldier, Spy"})
CREATE (gg)-[:WROTE]->(omih)
CREATE (jlc)-[:WROTE]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "05-02-2011"}]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "08-09-2011"}]->(omih)
CREATE (alan)-[:PURCHASED {date: "05-07-2014"}]->(ttsp)

There are a few extra brackets and the ‘CREATE’ key word but we haven’t lost any of the fidelity of the domain and in my experience a non technical / commercial person would be able to understand the query.

By contrast this article shows the steps we might take from a conceptual model describing employees, departments and unions to the eventual relational model.

If you don’t have the time to read through that, we start with this initial model…

2014 10 07 00 13 51

…and by the time we’ve got to a model that can be stored in our relational database:

2014 10 07 00 14 32

You’ll notice we’ve lost the relationship types and they’ve been replaced by 4 foreign keys that allow us to join the different tables/sets together.

In a graph model we’d have been able to stay much closer to the conceptual model and therefore closer to the language of the business.

I’m still exploring the world of data modelling and next up for me is to read Joe’s ‘Mastering Data Modeling‘ book. I’m also curious how normal forms and data redundancy apply to graphs so I’ll be looking into that as well.

Thoughts welcome, as usual!

Categories: Blogs

How to create a Value Stream Map

Xebia Blog - Mon, 10/06/2014 - 09:05

Value Stream Mapping (VSM) is a -very- useful tool to gain insight in the workflow of a process and can be used to identify both Value Adding Activities and Non Value Adding Activities in a process stream while providing handles for optimizing the process chain. The results of a VSM can be used for many occasions: from writing out a business case, to defining a prioritized list to optimize processes within your organization, to pinpointing bottlenecks in your existing processes and gain a common understanding of process related issues.

When creating a VSM of your current software delivery process you quite possibly will be amazed by the amount of waste and therefor the room for improvement you might find. I challenge you to try this out within your own organization. It will leave you with a very powerful tool to explain to your management the steps that need to change, as it will leave you with facts.

To quickly get you started, I wrote out some handles on how to write out a proper Value Stream Map.

In many organizations there is the tendency to ‘solely’ perform local optimizations to steps in the process (i.e. per Business Unit), while in reality the largest process optimizations can be gained by optimizing the area’s which are in between the process steps and do not add any value to the customer at all; the Non Value Adding activities. Value Stream Mapping is a great tool for optimizing the complete process chain, not just the local steps.


The Example - Mapping a Software Delivery Process
Many example value streams found on the internet focus on selling a mortgage, packaging objects in a factory or some logistic process. The example I will be using focuses on a typical Software Delivery Processes as we still see them today: the 'traditional' Software Delivery Process containing many manual steps.

You first need to map the 'as-is' process as you need this to form the baseline. This baseline provides you the required insight to remove steps from the process that do not add any value to your customer and therefor can be seen as pure waste to your organization.

It is important to write out the Value Stream as a group process (a workshop), where group-members represent people that are part of the value chain as it is today*. This is the only way to spot (hidden) activities and will provide a common understanding of the situation today. Apart from that, failure to execute the Value Stream Mapping activity as a group process will very likely reduce the acceptance rate at the end of the day. Never write out a VSM in isolation.

Value Stream mapping is 'a paper and pencil tool’ where you should ask participants to write out the stickies and help you form the map. You yourself will not write on stickies (okay, okay, maybe sometimes … but be careful not to do the work for the group). Writing out a process should take you about 4 to 6 hours, including discussions and the coffee breaks of course. So, now for the steps!

* Note that the example value stream is a simplified and fictional process based on the experience at several customers.

Step 0 Prepare
Make sure you have all materials available.

Here is a list:
- two 4 meter strokes of brown paper.
- Plastic tape to attach paper to the wall
- stickies square multiple colors
- stickies rectangle multiple colors
- small stickies one or two colors
- lot’s of sharpies (people need to be able to pick up the pens)
- colored ‘dot' stickies.

What do you need? (the helpful colleague not depicted)

What do you need? (the helpful colleague not depicted)

Step 1 & 2 define objectives and process steps
Make sure to work one process at a time and start off with defining customer objectives (the Voice Of Customer). A common understanding of the VoC is important because in later stage you will determine with the team which activities are really adding to this VoC and which steps are not. Quite often these objectives are defined in Time, Cost and Quality. For our example, let’s say the customer would like to be able to deliver a new feature every hour, with a max cost of $1000 a feature and with zero defects.

First, write down the Voice of the Customer in the top right corner. Now, together with the group, determine all the actors (organizations / persons / teams) that are part of the current process and glue these actors as orange stickies to the brown paper.

Defining Voice of Customer and Process Steps

Defining Voice of Customer and Process Steps

Step 3 Define activities performed within each process step
With the group, per determine the activities that take place. Underneath the orange stickies, add green stickies that describe the activities that take place in a given step.

Defining activities performed in each step

Defining activities performed in each step

Step 4 Define Work in Progress (WiP)
Now, add pink stickies in between the steps, describing the number of features / requirements / objects / activities that is currently in process in between actors. This is referred to as WiP - Work in Progress. Whenever there is a high WiP limit in between steps, you have identified a bottleneck causing the process 'flow' to stop.

On top of the pink WiP stickies containing particular high WiP levels, add a small sticky indicating what the group thinks is causing the high WiP. For instance, a document has to be distributed via internal mail, or a wait is introduced for a bi-weekly meeting or travel to another location is required. This information can later be used to optimize the process.

Note that in the workshop you should also take some time to finding WiP within the activities itself (this is not depicted in this example). Spend time on finding information for causes of high WiP and add this as stickies to each activity.

Define work in process

Define work in process

Step 5 Identify rework
Rework is waste. Still, many times you'll see that a deliverable is to be returned to a previous step for reprocessing. Together with the group, determine where this happens and what is the cause of this rework. A nice additional is to also write out first-time-right levels.

Identify rework

Identify rework

Step 6 Add additional information
Spend some time in adding additional comments for activities on the green stickies. Some activities might for instance not be optimized, are not easy to handle or from a group perspective considered obsolete. Mark these comments with blue stickies next to the activity at hand.

Add additional information

Add additional information

Step 7 Add Process time, Wait time and Lead time and determining Process Cycle Efficiency

Now, as we have the process more or less complete, we can start adding information related to timing. In this step you would like to determine the following information:

  • process time: the real amount of time that is required to perform a task without interruptions
  • lead time: the actual time that it takes for the activity to be completed (also known as elapse time)
  • wait time: time when no processing is done at all, for example when for waiting on a 'event' like a bi-weekly meeting.

(Not in picture): for every activity on the green sticky, write down a small sticky with two numbers vertically aligned. The top-number reflects the process-time, (i.e. 40 hours). The bottom-number reflects the lead time (i.e. 120 hours).

(In picture): add a block diagram underneath the process, where timing information in the upper section represents total processing time for all activities and timing information the lower section represents total lead time for all activities. (just add up the timing information for the individual activities I described in previous paragraph). Also add noticeable wait time in-between process steps. As a final step, to the right of this block diagram, add the totals.

Now that you have all information on the paper, the following  can be calculated:

  • Total Process Time - The total time required to actually work on activities if one could focus on the activity at hand.
  • Total Lead Time - The total time this process actually needs.
  • Project Cycle Efficiency (PCE): -> Total Process Time / Total Lead Time *100%.

Add this information to the lower right corner of your brown paper. The numbers for this example are:

Total Process Time: add all numbers in top section of stickies: 424 hours
Process Lead Time (PLT): add all numbers in lower section of stickies + wait time in between steps: 1740 hours
Project Cycle Efficiency (PCE) now is: -> Total Process  Time / Total Process Lead Time: 24%.
Note that 24% is -very- high which is caused by using an example. Usually you’ll see a PCE at about 4 - 8% for a traditional process.

Add process, wait and lead times

Add process, wait and lead times

Step 8 Identify Customer Value Add and Non Value Add activities
Now, categorize tasks into 2 types: tasks that add value to the customer (Customer Value Add, CVA) and tasks that do not add value to the customer (Non Value Add, NVA). The NVA you can again split into two categories: tasks that add Business Value (Business Value Add, BVA) and ‘Waste’. When optimizing a process, waste is to be eliminated completely as it does not add value to the customer nor the business as a whole. But also for the activities categorized as 'BVA', you have to ask yourself whether these activities add to the chain.

Mark CVA tasks with a green dot, BVA tasks with a blue dot and Waste with a red dot. Put the legend on the map for later reference.

When identifying CVA, NVA and BVA … force yourself to refer back to the Voice of Customer you jotted down in step 1 and think about who is your customer here. In this example, the customer is not the end user using the system, but the business. And it was the business that wanted Faster, Cheaper & Better. Now when you start to tag each individual task, give yourself some time in figuring out which tasks actually add to these goals.

Determine Customer Value Add & Non Value Add

Determine Customer Value Add & Non Value Add

To give you some guidance on how you can approach tagging each task, I’ll elaborate a bit on how I tagged the activities. Note again, this is just an example, within the workshop your team might tag differently.

Items I tagged as CVA: coding, testing (unit, static, acceptance), execution of tests and configuration of monitoring are adding value to the customer (business). Why? Because all these items relate to a faster, better (high quality through test + monitoring) and cheaper (less errors through higher quality of code) delivery of code.

Items I tagged as BVA: documentation, configuration of environments, deployments of VMs, installation of MW are required to be able to deliver to the customer when using this (typical waterfall) Software Delivery Processes. (Note: I do not necessarily concur with this process.) :)

Items I tagged as pure Waste, not adding any value to the customer: items like getting approval, the process to get funding (although probably required), discussing details and documenting results for later reference or waiting for the Quarterly release cycle. Non of these items are required to either deliver faster, cheaper or better so in that respect these items can be considered waste.

That's it (and step 9) - you've mapped your current process
So, that’s about it! The Value Stream Map is now more or less complete an contains all relevant information required to optimize the process in a next step. Step 9 here would be: Take some time to write out items/bottlenecks that are most important or easy to address and discuss internally with your team about a solution. Focus on items that you either tagged as BVA or pure waste and think of alternatives to eliminate these steps. Put your customer central, not your process! Just dropping an activity as a whole seems somewhat radical, but sometimes good ideas just are! Note by the way that when addressing a bottleneck, another bottleneck will pop up. There always will be a bottleneck somewhere in the process and therefor process optimization must be seen as a continuous process.

A final tip: to be able to perform a Value Stream Mapping workshop at the customer, it might be a good idea to join a more experienced colleague first, just to get a grasp of what the dynamics in such a workshop are like. The fact that all participants are at the same table, outlining the delivery process together and talk about it, will allow you to come up with an optimized process on which each person will buy in. But still, it takes some effort to get the workshop going. Take your time, do not rush it.

For now, I hope you can use the steps above the identify the current largest bottlenecks within your own organization and get going. In a next blog, if there is sufficient interest, I will write about what would be possible solutions in solving the bottlenecks in my example. If you have any ideas, just drop a line below so we can discuss! The aim for me would be to work towards a solution that caters for Continuous Delivery of Software.

Michiel Sens.

Categories: Companies

Environments for Swarming

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


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

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

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

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


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

Adaptive Licensing – Zulassung medizintechnischer Produkte als Lernprozess

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

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

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

Zulassung als lernendes System

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

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

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

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

Related posts:

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

Categories: Blogs

If you don't care to know about the details of IT, I'm going to bet that your IT is not going to work reliably

In the last while, I've encountered a few large enterprises that had chosen to outsource pretty much all their IT capability.  That is, for the most part, all the actual activity related to IT delivery and IT support are done by third-party vendors.  Full-time staff, for the most part, only manage vendor activities but don't do any of the activities themselves.
From what I can gather, the nominal rationale for the outsourcing is primarily about two things:
  1. Reducing cost: The third party vendor costs less than in-house staff
  2. Delegating risk: The risk moves to the third party vendors
What I suspect is the actual rationale is something along the lines of... 
"We have not been good at IT, we don't know how to fix it BUT if we outsource it, we don't have to think about it."The problem is the subsequent phenomenon that inevitably occurs.  Because, the full-time staff are only managing and not doing, they eventually (and by "eventually", I mean "very quickly") lose the ability to understand what is going on.  Once they lose the ability to understand what's going on, they lose the ability to effectively manage.
Is IT being delivered and supported efficiently?  Can't tell.Is our IT risk being managed effectively? Can't tell.
No reduced (overall) cost.  No shared risk.  No ability to tell this has happened.Martin alludes to this lesson in Utility vs Strategic Dichotomy.
If you don't care to know about the details of IT, I'm going to bet that your IT is not going to work reliably.
Categories: Blogs

Swarming Resources

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


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


The Wisdom of Crowds – James Suroweicki

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

Bioteams – Ken Thompson

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

Emergence – Steven Johnson

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

Micromotives and Macro Behavior – Thomas Schelling

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

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

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

Swarm Creativity – Peter Gloor

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

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

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

Web sites

BioTeams – Companion to the book

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

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

Swarm Theory –  a great Nat Geo article about swarming

Wikipedia article on swarms

Rules for Flocking Behavior

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

The Science of Biological Swarms

Swarm Creativity – companion site to Peter Gloor’s book

Research Project from the MIT Center for Collective Intelligence

Links on Complexity, Self-Organization and Artificial Life

Swarm Intelligence – more links

NY Times article on swarming

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

Project Anarchy

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


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

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

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

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

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

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

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

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

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

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


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

delar0cha: adsdata: 2014 Ads+Data design offsite. The talent...

Business Craftsmanship - Tobias Mayer - Fri, 10/03/2014 - 19:39



2014 Ads+Data design offsite. The talent at this table is immeasurable.

A colleague and collaborateur is moving on to new pastures. Farewell, Leonardo. I shall miss you, and our inspiring idea-building conversations.

Categories: Blogs

Integrating Geb with FitNesse using the Groovy ConfigSlurper

Xebia Blog - Fri, 10/03/2014 - 19:01

We've been playing around with Geb for a while now and writing tests using WebDriver and Groovy has been a delight! Geb integrates well with JUnit, TestNG, Spock, and Cucumber. All there is left to do is integrating it with FitNesse ... or not :-).

Setup Gradle and Dependencies

First we start with grabbing the gradle fitnesse classpath builder from Arjan Molenaar.
Add the following dependencies to the gradle build file:

compile 'org.codehaus.groovy:groovy-all:2.3.7'
compile 'org.gebish:geb-core:0.9.3'
compile 'org.seleniumhq.selenium:selenium-java:2.43.1
Configure different drivers with the ConfigSlurper

Geb provides a configuration mechanism using the Groovy ConfigSlurper. It's perfect for environment sensitive configuration. Geb uses the geb.env system property to determine the environment to use. So we use the ConfigSlurper to configure different drivers.

import org.openqa.selenium.firefox.FirefoxDriver

driver = { new FirefoxDriver() }

environments {
  chrome {
    driver = { new ChromeDriver() }
FitNesse using the ConfigSlurper

We need to tweak the gradle build script to let FitNesse play nice with the ConfigSlurper. So we pass the geb.env system property as a JVM argument. Look for the gradle task "wiki" in the gradle build script and add the following lines.

def gebEnv = (System.getProperty("geb.env")) ? (System.getProperty("geb.env")) : "firefox"
jvmArgs "-Dgeb.env=${gebEnv}"

Since FitNesse spins up a separate 'service' process when you execute a test, we need to pass the geb.env system property into the COMMAND_PATTERN of FitNesse. That service needs the geb.env system property to let Geb know which environment to use. Put the following lines in the FitNesse page.

!define COMMAND_PATTERN {java -Dgeb.env=${geb.env} -cp %p %m}

Now you can control the Geb environment by specifying it on the following command line.

gradle wiki -Dgeb.env=chrome

The gradle build script will pass the geb.env system property as JVM argument when FitNesse starts up. And the COMMAND_PATTERN will pass it to the test runner service.

Want to see it in action? Sources can be found here.

Categories: Companies

Partnership & Possibilities – Episode 1, Season 6

Partnership & Possibilities - Diana Larsen - Fri, 10/03/2014 - 17:30

Partnership & Possibilities: A Podcast on Leadership in Organizations

What are you seeing in your organization relating to women’s experience in the workplace? How are you involved in the growing conversation?

Leave a comment on this blog or email us at


[Intro] Subject of “Women in Agile” still a hot topic at Agile 2014 Conference in Orlando.

[03:20] “…this is the first year that the Agile Alliance has been very overt about their anti-harassment policy…”

[04:35] Agile conferences have a much higher proportion of women attending than any other kind of technical conference.

[07:03] It’s time to bring back conversations about “Gender Intelligence” and the often differing working styles between men and women.

[9:50] Attendees are more open and feel safer about having these kinds of conversations at Agile conferences.

[12:50] It is a courageous thing for a young woman to decide to stand out in the technical world due to very real danger of death threats, rape threats, and so on.
[17:20] The sense of male entitlement, and the belief that “I got to where I am because I’m so smart.”


[Agile 2014 Orlando Session] Women in Agile: Creating Teams That Embrace Diversity (Diane Zajac-Woodie, Doc Norton)

Categories: Blogs

The Agile Reader – Weekend Edition: 10/03/2014 - Kane Mar - Fri, 10/03/2014 - 12:51

You can get the Weekend Edition delivered directly to you via email by signing up

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture in #Kolkata
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Mumbai) #job
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture (#Hyderabad)
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Bangalore, apply now! #job
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Gurgaon, apply now at #Accenture! #job
  • What does the Scrum Master actually do in agile projects? –
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Mumbai. #Accenture
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai, apply now! #job
  • #JOB: Wir suchen motivierte und engagierte Coaches (m/w) für #agile Projekte #Scrum #Kanban
  • #JOB: Wir suchen motivierte und engagierte Coaches (m/w) für #agile Projekte #Scrum #Kanban
  • #JOB: Wir suchen motivierte und engagierte Coaches (m/w) für #agile Projekte #Scrum #Kanban
  • Business Analyst – Ecommerce / Agile / Scrum / Web Applications – Searchability – Chester Job Chester
  • Agile Tools – Tom Perry: Disappearing Radiators #agile #scrum
  • New #job opening at #Accenture in #Mumbai! Agile Methods (Scrum/FDD/XP/Crystal/DSDM)
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Mumbai) #job
  • RT @yochum: Agile Tools – Tom Perry: Disappearing Radiators #agile #scrum
  • Certified #Scrum Master weekend course in London – 1-2 Nov – £895 price expires at midnight – #agile
  • What Characteristics Make Good Agile Acceptance Criteria? –
  • Don’t Underestimate Discipline: The Real Key to Agile Development #nearshore #agile #scrum #software #development
  • New #job opening at #Accenture in #Mumbai! Agile Methods (Scrum/FDD/XP/Crystal/DSDM)
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai! #job
  • New #job: Senior Project Manager (Agile/Scrum) Location: London Salary: GBP55kpa – GBP65kpa .. #ITjobs
  • RT @technofeliz: Scrum et Agilité is out! Stories via @TheAgileNetwork @ShirlyRonenRL @lyssaadkins
  • RT @technofeliz: Scrum et Agilité is out! Stories via @TheAgileNetwork @ShirlyRonenRL @lyssaadkins
  • #Agile – How does Planning Poker work in Agile? –
  • Computer People: Senior Project Manager (Agile/Scrum) #ITjobs #technologyjobs #jobs
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Kolkata, apply now! #job
  • How I Helped Start the Agile/Scrum Movement 20 Years Ago via @wordpressdotcom #Agile #Scrum
  • RT @mikewcohn: Don’t equate story points to hours: #agile #Scrum
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Kolkata) #job
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai! #job
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Bangalore. #Accenture
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Gurgaon. #Accenture
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #NewDelhi, apply now at #Accenture! #job
  • RT @AgileSparrow: Our program is featured on @Hurriyet, and here is the link: #agile #scrum
  • How to Plan an Agile Sprint Meeting? –
  • RT @mikewcohn: Don’t equate story points to hours: #agile #Scrum
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture in #Chennai
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai! #job
  • How Avanade develops #agile coaches to be change agents to drive #awareness & #adoption #scrum
  • RT @AgileSparrow: Our program is featured on @Hurriyet, and here is the link: #agile #scrum
  • Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum.Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum: Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum: Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum: Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Pune, apply now! #job
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Chennai, apply now! #job
  • Scrum Framework Explained: #scrum #agile
  • Categories: Blogs

    UXSouthAfrica – UX and Agile

    Growing Agile - Fri, 10/03/2014 - 10:00

    Today we are doing a talk at UXSouthAfrica on UX and Agile. This topic has been a favourite of ours for a while. We believe strongly that agile and UX can work together very well. Unfortunately what we see most often is a sprint of UX running ahead of a sprint of dev. This is NOT what we mean by agile UX.

    Our talk explains the differences between Traditional UX, Agile UX and Lean UX. We also provide some tips for UX people wanting to try this out. You can get the slides on slideshare.

    Here are some links to interesting blog posts on the topic:

    This is a great newsletter on the topic of UX: The Agile & Lean UX News – be sure to subscribe!

    Categories: Companies

    Making System Interventions with Kanban Thinking

    AvailAgility - Karl Scotland - Fri, 10/03/2014 - 10:00

    This post pulls together a number of ideas on interventions into a single place, and will become the content for a page on Interventions on the Kanban Thinking site.

    What is an intervention?

    An intervention is an act of becoming involved in something in order to have an influence on what happens. It is an active and participatory action, as opposed to a passive and observational instruction. Thus in Kanban Thinking, interventions are ways of interacting with a kanban system with the intent of improving it and having a positive impact.

    There are 5 types of Kanban Thinking intervention, which can be considered as heuristics to help the discovery of appropriate practices and techniques for a system’s context. These heuristics may point to the purpose behind known and proven practices, or they may lead to the identification of new and alternative practices. They are:

    • Study the Context
    • Share the Understanding
    • Stabilise the System
    • Sense the Capability
    • Search the Landscape
    Study the Context

    What could be done to learn more about customer and stakeholder needs, the resultant demand and how that demand is processed?

    Kanban Thinking is based on a philosophy of “start where you are now” and the foundation for this evolutionary approach is Studying the Context. In his book “The New Economics”, W. Edwards Deming famously said, “there is no substitute for knowledge”, and it is the acquisition of this knowledge about the current situation that leads to an appreciation of how to improve it.

    Various practices are widely used to study different aspects of the system. Empathy Mapping is one way of learning more about customer and stakeholder needs. The work that they request as a result of those needs can be studied with demand analysis and profiling to determine classes of service and response. The way that work is then progressed, from concept to consumption, can be examined using forms of value stream mapping.

    Share the Understanding

    What information is important to share, and how can tokens, the inscriptions on them, and their placements, provide a single visual model?

    Sharing the Understanding of the current situation, typically in the form of a kanban board, creates an environment where people are more intrinsically motivated. The ability to see what needs work provides autonomy, the ability to see where improvements can be made provides mastery, and the ability to see where to focus provides purpose.

    Potentially, lots will have been learned from studying the context, so it is important to decide what is the most relevant information to share to avoid being overloaded with too much noise. That information can then be visualised using various patterns based on the acronym TIP; Token, Inscription, Placement. Tokens are the cards, stickies or other tangible representations of the work, where aspects such as shape, size, colour or material can represent different information. Inscriptions are items of information added onto the tokens, where words, dates, pictures or symbols can all be used with suitable formatting. Placements are the Tokens are placed on the board to convey information, where horizontal, vertical and relative positioning can all be meaningful.

    Stabilise the Work

    What policies could help limit work in process, and remove unnecessary or unexpected delays or rework?

    A kanban system which is stable is more likely to be able to evolve and have resilience in the face of change. Systems can be considered to have boundaries or constraints, and those with too loose constraints will devolve into chaos, whereas those with too tight constraints will become brittle with bureaucracy. Stabilising the Work is achieved with enabling constraints, open enough to avoid restriction and prescription, yet limiting enough to stimulate expansion and new possibilities.

    Defining work in process limits is a primary means of stabilising the work. One approach is to start with the current work in process (WIP), and look to gradually reduce it. Alternatively, the WIP could be drastically reduced to stabilise quickly, and then gradually increased to a more optimal level. A middle ground could be to base an initial WIP in the size of the team, such as one work item per person. How WIP is spread across the system is also a factor, from a single limit covering everything (CONWIP) to a different limit per stage or column.

    WIP is a form of explicit policy, and other common forms are Definitions of Ready and Done and similar, simple quality criteria. Additionally, Test Driven Development can be considered an explicit policy on how software is written to create a stable code-base.

    Sense the Capability

    What measures and meetings might create insights and guide decisions on potential interventions?

    As well as acquiring knowledge on what the work is, and how it gets done, it is also important to know how well it gets done. Sensing the Capability of a kanban system involves getting a feel for its performance by both measuring and interacting with it. Metrics provide an objective, quantative sense of capability. Meetings, and other feedback cadences, provide a subjective and qualitative sense of capability.

    Measures should be derived from the desired impact, and the outcomes which would make the impact. If Flow is the desired impact, being more responsive might be a good outcome, and thus Lead Time might be a good measure. Additionally, the subsequent behaviours, both good and bad, which a measure might drive should be considered, and trade-offs can be made by having a set of balancing metrics. A focus on Lead Time might result in a reduction in Quality by cutting corners, so measuring Released Defects could help balance that trade-off.

    Meetings provide a cadence with regular interactions can generate feedback. A simple metronomic cadence can tie various events such as planning, reviewing and retrospection to a single rhythm, or a polyrhythmic cadence can decouple these events into multiple rhythms. Another option is for some events to be asynchronous and triggered by the work rather than time-driven.

    Search the Landscape

    What small experiments could be run to safely learn the impact of different interventions?

    Searching the Landscape of a kanban system involves looking at a range of possible interventions and experimenting to discover what impact they have. Those that have a positive impact should be pursued and amplified. Those that turn out to have a negative impact should be reversed and dampened. This searching can be thought of as exploring the evolutionary potential of the present state, as opposed to defining a future state and trying to move towards it.

    Defining an experiment involves proposing a hypothesis that has a rationale behind it, can be measured in order to validate or falsify it, and can be easily recovered from in case of unanticipated results. The intentional act of documenting the experiment, using formats such as A3s, encourages disciplined thinking and avoids falling into the trap of retrospective coherence to explain results.

    Searching the Landscape is an exercise in continual curiosity about how to evolve and improve the kanban system, increasing impact through further insights, interactions and interventions.

    Categories: Blogs

    Selbstorganisation braucht Führung: Sich selbst und andere begeistern

    Scrum 4 You - Fri, 10/03/2014 - 07:33

    Mittlerweile schreibe ich meine Beiträge für den Blog mit echter Begeisterung. Und ich stelle fest: Dieser Zustand wirkt sich sehr positiv auf die Ergebnisse und den Schreibprozess aus. Mehr Spaß und Engagement beim Verfassen und schnellere und meiner subjektiven Einschätzung nach auch immer bessere Ergebnisse. Erfolgreiche Arbeit und Begeisterung scheinen in einem unmittelbaren Zusammenhang zustehen.

    In meinen ScrumSupplement Trainings fragen mich Teilnehmer immer wieder, wie sie die Motivation ihrer Teams oder einzelner Mitarbeiter wirkungsvoll verbessern können. Frage ich genauer nach, scheinen mir die Teams eigentlich durchaus motiviert. Sie machen ihren fachlichen Job, praktizieren mehr oder weniger brav Scrum. Was den Führungskräften bei ihren Teams und Mitarbeitern fehlt, ist in der Regel eindeutig (mehr) Begeisterung für die “gute Sache”. Auf weiteres Nachfragen verbinden meine Teilnehmer mit dem Phänomen Begeisterung hohes Engagement, Herzblut, positive Stimmung, Teamgeist, Spaß, weniger Widerstände und natürlich in erster Linie eine optimale Performance. Es geht ihnen also darum, grundsätzlich motivierte Menschen im Arbeitsprozess in einen Zustand der Begeisterung zu bringen. Ein durchaus verständliches und legitimes, aber auch anspruchsvolles Anliegen von Führung.

    Doping für Geist und Gehirn

    Der Duden definiert Begeisterung als “Zustand freudiger Erregung, leidenschaftlichen Eifers und hohen Engagements”. Klingt natürlich gut und erklärt, warum der Zustand der Begeisterung in verschiedensten Zusammenhängen so attraktiv erscheint. Der berühmte Hirnforscher Gerald Hüther meint dazu: “Das ist der Grund, warum wir bei all dem, was wir mit Begeisterung machen, auch so schnell immer besser werden. Jeder kleine Sturm der Begeisterung führt gewissermaßen dazu, dass im Hirn ein selbsterzeugtes Doping abläuft. So werden all jene Stoffe produziert, die für alle Wachstums- und Umbauprozesse von neuronalen Netzwerken gebraucht werden. So einfach ist das: Das Gehirn entwickelt sich so, wie und wofür es mit Begeisterung benutzt wird.” (Gerald Hüther, “Begeisterung ist Doping für Geist und Hirn” offizielle Webseite) Kleine Kinder sind 20-50 Mal pro Tag in einem Zustand großer Begeisterung und lernen dabei meist rasend schnell. Als frisch gebackener Großvater einer Enkelin kann ich das nur bestätigen. Wir Erwachsenen haben diese natürliche Begeisterungsfähigkeit im Laufe unserer Biografie (individuell allerdings sehr unterschiedlich) leider stark abgebaut, aber nicht grundsätzlich verlernt, wie jeder bei sich selbst immer wieder erleben kann. Es besteht also Hoffnung.

    Um andere Menschen mit Begeisterungshormonen zu “dopen” muss man:

    1. Selbst begeistert sein, sich selbst begeistern können. Nur wer selbst begeistert ist, kann andere wirklich begeistern, oder um mit Augustinus Aurelius (354-430, römisch-karthagischer Philosoph, Rhetoriker und Theologe) zu sprechen: “Nur wer selbst brennt, kann Feuer in anderen entfachen.” Will ich andere begeistern, muss ich mir also die Frage stellen, ob ich von (m)einer Sache wirklich selbst begeistert bin. Das Entscheidendste für die eigene Begeisterung ist es, dass das, worum es geht, von großer Bedeutung, von hoher Wichtigkeit für mich ist und dass ich es selbst und aus eigener Motivation gewählt habe. Dass es meine Wahl und ureigene Entscheidung war und etwas bei mir auslöst, das da heißt, ich will das unbedingt tun/haben (nicht “ich muss”). Sich selbst für etwas begeistern heißt, die Möglichkeit darin zu sehen, sich selbst verwirklichen und seine Fähigkeiten und Stärken optimal einsetzen zu können. Dies bedeutet ein attraktives Spielfeld für sich zu generieren, um erfolgreich sein zu können und die Aussicht auf Freude am Tun und im Idealfall Erfolg zu haben. Begeisterung heißt auch, sich von anderen unabhängig zu machen. Darum gilt es im “Ernstfall”, das eigene Begeisterungslevel zu prüfen und sich zu fragen, ob es ausreicht, um andere mitzunehmen und anzustecken. Und wenn nicht: Was hindert mich und was brauche ich als Führungskraft noch?
    2. Dialoge inszenieren. Begeisterung bei anderen entsteht in erster Linie nicht durch einseitige Monologe, sondern durch Austausch im Dialog. Das bedeutet, sich nicht nur für mich und meine eigene aktuelle Begeisterung, sondern sich auch für den anderen zu interessieren, adäquat auf ihn zu reagieren und ihm zuzuhören. Empathie und Einfühlungsvermögen sind hier die Stichworte um a) das Gegenüber einschätzen zu können, und es b) nicht zu überfordern, ihm nichts mit aller Macht überzustülpen. Begeistern kann man den, der bereit ist (bewusst/unbewusst), sich begeistern zu lassen. D.h. manchmal brauchet es erst Zeit zur Vorbereitung. Nur so wird er meine Sache mit der Zeit zu seiner machen. Denn nur wenn er meine zu seiner Sache macht, entsteht seine Begeisterung (siehe oben).
    3. Gezielt Emotionalität antriggern, eine “emotionale Epidemie” auslösen. Begeisterung ist in einem hohen Maße ein positiv-emotionales Phänomen. Um die emotionale Ebene bei anderen anzusprechen, empfiehlt sich eine lebendige Sprache mit Metaphern und Sprachbildern. Auch der intensive Einsatz von Visualisierung weckt Emotionalität – aber nicht unbedingt Power Point, sondern selbst gemalte Flipcharts, Fotos und Bilder mit hoher Aussagekraft usw. Es empfiehlt sich, die eigene Gefühlslage offenzulegen und seine positiven, animierenden Emotionen, wie Freude, Lust, Neugier, Stolz etc., anzusprechen. Und natürlich kann die gesamte Palette wirkungsvoller Rhetorik gezielt eingesetzt werden. Dazu findet man jede Menge schlauer Ratgeber in Form von Büchern oder im Netz. Emotionen haben wissenschaftlich nachweisbar den Charakter von Viren, d.h. sie sind sozial äußerst ansteckend. Es empfiehlt sich also, in Situationen die man emotional aufladen will, zuerst bei besonders empfänglichen Personen anzufangen und auf den Ansteckungseffekt zu setzen. Werden diese zu begeisterten “Missionaren”, können sie eine gewünschte “Epidemie der Begeisterung” unterstützen. In Berichten über besonders erfolgreiche Führungskräfte, ob in Sport oder Wirtschaft, kann man dieses Phänomen immer wieder nachlesen. Sie können in besonderem Maße andere mit ihrer Begeisterung infizieren.
    4. Die Individualität meiner Gegenüber gezielt berücksichtigen und nutzen. Erwachsene Menschen haben biographisch sehr unterschiedliche Begeisterungsmuster. Ich zum Beispiel bin ein sehr begeisterungsfähiger Mensch und daher schnell und ausdauernd von allem Möglichem begeistert und zu begeistern. Meiner lieben Frau gehe ich damit immer wieder mal auch gehörig auf die Nerven, denn sie braucht deutlich länger, um sich für etwas zu begeistern und hat auch ein anderes Intensitätsniveau. Es gilt also im Dialog herauszufinden, wo beim anderen die Ansatzpunkte Sinne von Begeisterung liegen, an denen er erreichbar und ansprechbar ist. Braucht er Visionen, ein klares Ziel, Herausforderung, Sicherheit, Erfolg, Struktur, Freiräume? Ist es eher Emotionalität oder Rationalität, will er spielerisch handeln können, ernsthafte Aufgaben übernehmen, braucht er Erfolgsorientierung, Prozessorientierung, Bedenkzeit, Ehrgeiz, usw.? Und, manchmal hilft alles nichts, es entwickelt sich kein Begeisterungspotential. Vielleicht genügt dann auch die “gewöhnliche Standardmotivation”.

    Fazit: Selbstorganisation braucht Führung. Führung in der Selbstorganisation braucht Begeisterung. Für Management und Führung ist es eine zentrale Aufgabe, Anstöße zu geben, Bewegung zu erzeugen, die zu eigendynamischen Prozessen von Selbstorganisation führen. Hohe Motivation, im Idealfall echte Begeisterung, gewährleistet optimal, dass erwünschte Ziele und Ergebnisse auch erreicht werden können. Kein Team wird Weltmeister, wenn es sich nicht an seinen Aufgaben berauscht, in einen Flow kommt und begeistert alle seine Ressourcen nutzt und einsetzt.

    Literaturtipp: Boris Gloger; Dieter Rösner: Selbstorganisation braucht Führung. Die einfachen Geheimnisse agilen Managements. Hanser 2014.

    Related posts:

    1. Über das Schreiben | Leidenschaft
    2. Neues Buch: Selbstorganisation braucht Führung
    3. Führung ja, nein, jein?

    Categories: Blogs

    Disappearing Radiators

    Agile Tools - Fri, 10/03/2014 - 07:24


    A little while ago I wrote an article sharing all the amazing information radiators that you can find in a 1st grade classroom. It’s been a while since that eye opening experience and I found myself at “curriculum night” at her middle school. As I wandered from class to class, listening to teachers drone on about their teaching philosophy, I found myself once again staring at the walls, and yet again they seemed to be telling me a story.

    In my first article I was astonished by the richness and variety of information radiators that you find in the typical elementary school classroom. Nary a square inch of wall space is wasted. Middle school, as it turns out, is somewhat different. In middle school there was still information on the walls, but it was more subdued and there was less of it. You can actually find bare stretches of wall space. Not many, but definitely more than what you see in elementary school.

    As I sat there in those dreadful little plastic chairs, I wondered, “Do we put less information up on the walls as we get older?” What will I find in the classrooms when my daughter is in high school? In college? I remember the classrooms in my college well, and there were often entire rooms with nothing at all on the walls. Why is that?

    So here I am today, living like a nomad in that information radiator desert we call a corporation. Simply asking people to put a task board up on the wall is a revolutionary idea. What happened to us? Do we stop learning? Do we not require as much information?

    I don’t think so. Working in technology, all we do is learning: about our customers, about technology, about the business domain. If anything, we are required to learn at what feels like an ever faster rate with each passing year. For instance, I know C/C++, which qualifies me as a Jurassic techno-dinosaur. I know Java too, which probably brings me up to the Cretaceous period (Woolly Mammoth?). These days there are functional languages that just completely leave me in the dust. The lizard brain just can’t keep up. We live in a world now where our ability to learn is being constantly tested. With each new silicon valley startup, the pressure increases.

    So, why on earth do we leave all those wonderful, rich, learning environments behind? Do our inner worlds become so abundant and complex that we no longer benefit from the additional input from the external world? I doubt it. I feel like I need to start a campaign to bring back the information radiator. Agile task boards are a good start, but there is so much more we could be doing.


    Filed under: Agile Tagged: class, classroom, data, information, information radiators, Learning, school
    Categories: Blogs

    Corporate Values: Really Valuable, or Really Just a Poster?

    Agile Management Blog - VersionOne - Thu, 10/02/2014 - 17:06

    You hear about the agile values and they seem to make sense, but what the heck is a value system? And how do you use value systems in your daily work? Do your values really help you do your job better, or are they really just a poster in your office kitchen?

    When I say values, I’m talking about beliefs that guide behavior – as opposed to the term value meaning ‘the benefit of what is being produced.’ In software we use both “agile values” and “business value,” but they represent different things.

    Corporate values have peppered company literature for ages.  These value statements are important expressions of the community and culture within a company.  In larger organizations, however, those values are often so abstract that it’s tough to impact a team’s work.

    The notion of a value system to guide agile software development emerged in Kent Beck’s inclusion of values with the introduction of Extreme Programming (XP) in the late ‘90s.   A similar set of values was added to Scrum soon afterward. And soon after that, the Agile Manifesto was born. It brought software teams a straightforward value statement that today remains a powerful influence on the behavior and success of agile software development teams all over the world.

    The concept of a human value system has been reasonably well studied in psychology since the ‘50s, but before 1999 (when Kent posed the question, “What is it that we value?”), developers simply didn’t talk about values – only the work at hand. People brought abstract, personal values in to work with them, which may have influenced behavior lightly.  This introduction of a value system was one of the most innovative parts of XP.  The XP values are Communication, Simplicity, Feedback, Courage and Respect. With the Agile Manifesto, that contribution expanded to the broader software industry and beyond, opening a new focus on behavior and improving the way we do things.

    Let’s back up and define the agile values…

    Watch this video: “The Agile Manifesto – 4 Agile Values Explained”

    Sound familiar?

    You’ve probably seen these agile values introduced in agile training, and they are easy to learn. They also read well on posters. But how do they affect you every day, every sprint, every release?

    The utility of the value system is often lost to the intense focus on the agile frameworks and practices. Back when XP was still the most common agile approach, I gave a popular talk that included asking the audience, “What is XP?”  Invariably, it would take many minutes and an awkward silence after all of the practices were exhausted for someone to timidly mention the values.  Most certified Scrum people are not be able to articulate the Scrum values.  Of the roughly 150 words squeezed into the official Scaled Agile Framework® diagram, only one of values, Code Quality, made the cut (alignment, transparency, and program execution are the omitted three).  We have a long way to go to appreciate the important role that values play in enabling teams to be empowered to adapt their practices and maximize their delivery.

    So, why are these values so important?  Aren’t we doing OK with the values being the footnote they are?

    To see the answer, one needs to look no further than the frustration expressed around the dogma of agile.  A common complaint of Scrum team members is an almost irrational commitment to follow the rules of Scrum blindly.  Ironically, one reaction of the Scrum community to SAFe™ is that it is overly prescriptive in how organizations should scale Scrum.  In both cases, an increased focus and incorporation of the values leads teams to a better place.

    In the absence of shared values to guide the adaptation of our practices, teams are left to resort to static rules to guide their behaviors.  We see silly arguments like “Should the Product Owner participate in the Daily Scrum?”  In the context of the Scrum values (Focus, Courage, Openness, Commitment and Respect), a team can answer that question easily and optimally by themselves.  We don’t need to enforce consistent practices, as long as teams apply the values to their situation.

    Let’s explore some specifics 

    The agile values system can guide daily decisions about working through problems with teams and individuals in a way that corporate values may not be able to.  Any problem we are trying to solve can be addressed with more rules and process, more contracts, more documents, more upfront planning.  Those are our traditional, comfort-zone, status quo solutions.  I can almost guarantee that in an early sprint retrospective with a new agile team, some of the feedback will be, “Had we spent more time documenting up front, we would not have had this problem.”

    There will be times where those items “on the right” in the Manifesto will be part of the solution to our challenges.  But a commitment to our values will drive innovative solutions that better support our use of agile.  Examples include the increased use of tele-presence technology with distributed teams — reconstructing our workspaces, reconfiguring teams, and even relocating people — and collaborating with people we didn’t even realize were involved in, or affected by, our work.  The values will guide us to solutions that enhance agile, rather than contradict it.

    One of my favorite examples where the values guided the solution to a problem was an SDLC compliance change at a very large financial services company.  Existing SDLC practices required numerous artifacts to be delivered within each phase of a project.  Requirements documents had to be signed off during the requirements phase, prior to design, etc.  The agile advocates needed this process requirement changed to empower agile teams to deliver shippable increments in each sprint.  But this needed to be done in a way that was still compatible with the majority of project teams who were still following the phased approach.

    So, rather than create a big conflict, demanding that the whole process be changed, a simple change was made.  Audit artifacts are still required for the business, but teams have discretion as to WHEN artifacts get produced.  All of the artifacts are required when they close projects, but the team decides when it is optimal to do it. They don’t have to sign off on a Requirements document in the beginning of a long plan. Requirements can be modified over time, and they can furnish a signed-off Requirements document at the end. This moved the organization closer to the Individuals and Interactions value, while respecting the importance of Process and Tools in the broader organization.  A dogmatic stance on Scrum practices would not have been so open to that solution.  Later, further updates gave teams more discretion of WHICH artifacts were valuable enough to produce, further empowering the teams for continuous improvement.

    So, the next time you’re in your Daily Scrum or Retrospective – or even just solving a problem – reflect on what is being talked about. How are teams and individuals working together to identify solutions? As you move across release and process design (teams and programs), pull out the agile values and assess whether your decisions and those of your teams reinforce the agile values or diminish them. Are they helping the organization make decisions that drive working software?  Use the values to guide your solutions and improvements.  If values aren’t helping people do their jobs better, why bother? At that point, they are just poster fodder!

    Categories: Companies

    Management Feedback: Are You Abrasive or Assertive?

    Johanna Rothman - Thu, 10/02/2014 - 15:37

    Let me guess. If you are a successful woman, in the past, you’ve been told you’re too abrasive, too direct, maybe even too assertive. Too much. See The One Word Men Never See In Their Performance Reviews.

    Here’s the problem. You might be.

    I was.

    But never in the “examples” my bosses provided. The “examples” they provided were the ones when I advocated for my staff. The ones where I made my managers uncomfortable. The examples, where, if I had different anatomy, they would have relaxed afterwards, and we’d gone out for a beer.

    But we didn’t.

    Because my bosses could never get over the fact that I was a woman, and “women didn’t act this way.” Now, this was more than 20 years ago. (I’ve been a consultant for 20 years.) But, based on the Fast Company article, it doesn’t seem like enough culture has changed.

    Middle and senior managers, here’s the deal: At work, you want your managers to advocate for their people. You want this. This is a form of problem-solving. Your first-line and middle managers see a problem. If they don’t have the entire context, explain the context to them. Now, does that change anything?

    If it does, you, senior or middle manager, have been derelict in your management responsibility. Your first-line manager might have been able to solve the problem with his/her staff without being abrasive if you had explained the context earlier. Maybe you need to have more one-on-ones. Maybe all your first-line managers could have solved this problem in your staff meeting, as a cross-functional team. Are you canceling one-on-ones or canceling problem-solving meetings? Don’t do that.

    Do you have a first-line manager who doesn’t want to be a manager? Maybe you fell prey to the myth of promoting the best technical person into a management position. You are not alone. Find someone who wants to work with people, and ask that person to try  management.

    We all need feedback. Managers need feedback, too. Because managers leverage the work of others, they need feedback even more than technical people.

    If you think a manager on your management team is “too” abrasive or assertive,” ask yourself, is this person female? Then ask yourself, “Would I say the same thing if this person looked as if she could be a large sports figure, male attributes and all?”

    You see, the fact that I have the physical attributes of a short, kind-of cute woman has not bothered me one bit. I feel seven feet tall. I often act like it. I am not afraid to take chances or calculated risks. I am not afraid to talk to anyone in the organization about anything. How else would I accomplish the work that needs to be done? (You may have noticed that I write tall, too.)

    Abrasive and assertive are code words for fearless problem solvers. Don’t penalize the women—or the men—in your organization who are fearless problem solvers.

    Categories: Blogs

    NServiceBus 5.0 behaviors in action: routing slips

    Jimmy Bogard - Thu, 10/02/2014 - 14:57

    I’ve wrote in the past how routing slips can provide a nice alternative to NServiceBus sagas, using a stateless, upfront approach. In NServiceBus 4.x, it was quite clunky to actually implement them. I had to plug in to two interfaces that didn’t really apply to routing slips, only because those were the important points in the pipeline to get the correct behavior.

    In NServiceBus 5, these behaviors are much easier to build, because of the new behavior pipeline features. Behaviors in NServiceBus are similar to HttpHandlers, or koa.js callbacks, in which form a series of nested wrappers around inner behaviors in a sort of Russian doll model. It’s an extremely popular model, and most modern web frameworks include some form of it (Web API filters, node, Fubu MVC behaviors, etc.)

    Behaviors in NServiceBus are applied to two distinct contexts: incoming messages and outgoing messages. Contexts are represented by context objects, allowing you to get access to information about the current context instead of doing things like dependency injection to do so.

    In converting the route supervisor in my routing slips implementation, I greatly simplified the whole thing, and got rid of quite a bit of cruft.

    Creating the behavior

    To first create my behavior, I need to create an implementation of an IBehavior interface with the context I’m interested in:

    public class RouteSupervisor
        : IBehavior<IncomingContext> {
        public void Invoke(IncomingContext context, Action next) {

    Next, I need to fill in the behavior of my invocation. I need to detect if the current request has a routing slip, and if so, perform the operation of routing to the next step. I’ve already built a component to manage this logic, so I just need to add it as a dependency:

    private readonly IRouter _router;
    public RouteSupervisor(IRouter router)
        _router = router;

    Then in my Invoke call:

    public void Invoke(IncomingContext context, Action next)
        string routingSlipJson;
        if (context.IncomingLogicalMessage.Headers.TryGetValue(Router.RoutingSlipHeaderKey, out routingSlipJson))
            var routingSlip = JsonConvert.DeserializeObject<RoutingSlip>(routingSlipJson);

    I first pull out the routing slip from the headers. But this time, I can just use the context to do so, NServiceBus manages everything related to the context of handling a message in that object.

    If I don’t find the header for the routing slip, I can just call the next behavior. Otherwise, I deserialize the routing slip from JSON, and set this value in the context. I do this so that a handler can access the routing slip and attach additional contextual values.

    Next, I call the next action (next()), and finally, I send the current message to the next step.

    With my behavior created, I now need to register my step.

    Registering the new behavior

    Since I have now a pipeline of behavior, I need to tell NServiceBus when to invoke my behavior. I do so by first creating a class that represents the information on how to register this step:

    public class Registration : RegisterStep
        public Registration()
            : base(
                "RoutingSlipBehavior", typeof (RouteSupervisor),
                "Unpacks routing slip and forwards message to next destination")

    I tell NServiceBus to insert this step before a well-known step, of loading handlers. I (actually Andreas) picked this point in the pipeline because in doing so, I can modify the services injected into my step. This last piece is configuring and turning on my behavior:

    public static BusConfiguration RoutingSlips(this BusConfiguration configure)
        configure.RegisterComponents(cfg =>
            cfg.ConfigureComponent(b => 
        return configure;

    I register the Router component, and next the current routing slip. The routing slip instance is pulled from the current context’s routing slip – what I inserted into the context in the previous step.

    Finally, I register the route supervisor into the pipeline. With the current routing slip registered as a component, I can allow handlers to access the routing slip and add attachment for subsequent steps:

    public RoutingSlip RoutingSlip { get; set; }
    public void Handle(SequentialProcess message)
        // Do other work
        RoutingSlip.Attachments["Foo"] = "Bar";

    With the new pipeline behaviors in place, I was able to remove quite a few hacks to get routing slips to work. Building and registering this new behavior was simple and straightforward, a testament to the design benefits of a behavior pipeline.

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    Categories: Blogs

    Teams 102

    Leading Agile - Mike Cottmeyer - Thu, 10/02/2014 - 13:00

    Much of my personal journey over the past 8 years has involved unpacking some of the more dense concepts we tend to take for granted when we talk about agile. For me, it’s all about understanding the primitives of these approaches and trying to figure out how to apply them in unique ways. I’m deeply interested in not only how this stuff works, but why it works… and more importantly, why it fails when it fails. 

    The time I spent with VersionOne was very formative for me. My gig with V1 was a blend of training, coaching, and helping our customers understand and implement the product. When you are trying to implement software designed to support a very specific process, and the company adopting the process isn’t really built to accommodate it, things can get goofy really fast. For any of you guys that have configured V1, Rally, Jira, TFS, or AgileCraft… you know what I mean. 

    I didn’t have this language back when I was with V1, but over the last few years I’ve come to believe that most organizations struggle to adopt agile because agile is incongruent with how they’ve built their companies and what their companies value. It usually centers around how they have chosen to form teams, how they govern their work, and how they measure the performance of their organization. To me… and now to LeadingAgile… those are the things that we need to fix first. Solving this is why I left V1 and started my own company. 

    A Brief Perspective on the History of Agile

    I’ll admit I’m no historian of agile, and while I’ve gotten to know a few of the original manifesto signers, much of what I’m getting ready to say here are just my impressions based on the things I’ve read and heard over the past few years as a student of this approach. 

    I think that many folks new to agile think of agile as a thing… they might even equate agile with Scrum and might not even know there are other approaches out there in practice that are considered agile. I like to talk about agile as a family of approaches that have their roots in the earliest days of software engineering back in the 60’s and 70’s and some of the lean stuff in the 80’s. 

    When the Manifesto signatories got together in 2001, they weren’t inventing agile. They were already doing agile, they were just doing agile in many different ways. The Snowbird event wasn’t about invention, it was about discovery. It was about exploring what the various approaches had in common. I think it also might of had something to do with drinking and snow skiing, but I digress. 

    The result was in effect a position statement of sorts… The Agile Manifesto. If you’re on this blog, I imagine you’ve been exposed to that document, and I’ll save you the agony of going over it in any detail here. What’s important to this conversation though, is that the Manifesto isn’t a process, it’s a set of values and principles. It guides us on how to think and behave, but doesn’t really tell us what to go do. 

    The Manifesto and Teams

    The Manifesto says a little about teams. What it does say specifically is that we should support them and trust them and allow them to self-organize. It doesn’t say much about who should be on a team, or how to form a team, or what to do when forming teams is hard. I think the Manifesto assumes teams of a specific sort. When we look the other principles and see that we are supposed to deliver often, get feedback, etc. we start to gather some clues about what it would take to form a team capable of providing that kind of value. 

    I don’t think that anyone would disagree that when the Manifesto was written, folks weren’t really trying to apply these principles at scale. They weren’t trying to apply these concepts in the large, super complicated companies that are trying to apply agile today. They were dealing with groups of 5-10 developers, all working in the same office, all with access to decision makers. They were dealing with simpler technology stacks that they fully controlled. When the Manifesto was written, this was they environment they assumed to be in place. 

    Culture, Practices, and Teams

    This discussion of the Manifesto is important to me because it has clearly shaped much of the conversation around how to adopt agile, and 13 years later, how we should best adopt agile at scale in large enterprises.

    Because the Manifesto is a set of values and principles… and doesn’t give much guidance around how to form teams or any guidance around specific practices… agile transformation is quite often approached as a culture change. The idea being that we have to get people to change how they think and how they behave in order to do agile. 

    Likewise, because the values and principles outlined in the Manifesto were derived from methodology and practice, many transformations focus on changing the stuff that people do. Be it technical practices or management practices… we recognize that people need to learn new tools and techniques that are necessary to operate in this new way. 

    While I believe culture shift in many organizations is a necessary precondition to making change stick, and I think it’s fairly inarguable that solid blocking and tackling around the core agile practices is essential to be a high performing agile team… I’ve come to believe that individually, and even together, culture change and practices are not enough to have an effective agile ecosystem. 

    I think it’s what’s implicit in the Manifesto that is actually most important. I think it’s the ability to have complete cross-functional teams that gives us the foundation for a healthy, adaptive, trust-based culture to emerge and for agile practices to become contextually relevant. Cultural messaging and practices outside of a complete cross-functional team just doesn’t make any sense to me. 

    Regardless if it makes sense, I don’t fundamentally see this approach work in practice. While culture and practices are essential, they are not sufficient to effect sustainable, large scale transformation in most organizations. We need to have a pattern for forming teams across the organization, guidance for how to intake and coordinate work across teams, and ways to track delivery and communicate progress. Structure, governance, and metrics.

    My General Bent

    My general bent is that the best way to effect sustainable change, and establish  lasting agile transformations, is to first form teams. After the teams have been formed, you get them executing with precision by teaching the practices that make agile teams really work. Why teams and practices first? Well, by forming teams and teaching practices first, you create safety for the people to change what they believe. 

    My take is that it’s hard to get people to change what they think, feel, and believe… especially if they are invested personally in the old way of working. It’s extra hard if people have been punished for coloring outside the lines. If a company wants to go agile, is willing to form teams, create the environment where the practices can generate great results… I believe you will create an ecosystem where a healthy culture can emerge.

    Results build trust with the organization and provide safety for the managers which in turn creates safety for the teams. Safety is what allows culture shift to happen. While culture shift is wildly important, it’s not the place you want to start in your agile transformation. 


    In this post, I wanted to go just a little deeper on the notion of teams and challenge some of the common thinking around agile and agile transformation.

    Don’t get me wrong… there is hard work ahead of us. We haven’t addressed ANY of the barriers yet that make forming teams difficult or what you’d even form a team around if we had permission to go do it.

    LeadingAgile starting to discover some really effective patterns, thinking tools, and specific methods for giving guidance on forming teams in large, complex organizations. Furthermore, we are seeing these patterns drive significant gains within the organizations we’re working with. That’s pretty exciting. 

    That said, if I don’t get you convinced the forming teams is first problem to solve, maybe even the most important problem to solve, the rest won’t really matter much ;-)

    Until next time. 

    The post Teams 102 appeared first on LeadingAgile.

    Categories: Blogs

    Starting Swarming

    Agile Tools - Thu, 10/02/2014 - 07:47


    “prattle without practice”
    ― William Shakespeare, Othello

    Enough prattle! All this theory is great, but how do we actually set the conditions for swarming to occur? How can we make it work?

    Initiating the Swarm

    The problem with a good swarming team is that you can’t control team membership. Swarming requires a dynamic and egalitarian approach where everyone can decide what they want to do with whomever they please. Management has no role in this at all (other than perhaps creating the space). I suppose you could try and provide a few seed ideas to attract people, but you go into it with no assurance that those ideas will be what the groups coalesce around.

    There should be some orientation to the values and principles to start with. We need to find a group that is interested in using the process and understands from the start that there are no explicitly defined leaders or followers. Anyone can come up with an idea, and if the idea is a good one, perhaps others will join you.

    So the key ingredients to start swarming:

    • People who have been introduced to and understand the swarming values and principles
    • Some ideas
    • A place for the swarming to take place – preferably a place dedicated to swarming
    • Passion

    One more note on the people: radical diversity is required. It’s not sufficient to just toss a bunch of developers and QA into a room and tell them to swarm. It must be open to everyone. ABSOLUTELY everyone. That’s right, toss that cute receptionist from the front desk in there too. Customer Service, the guy from the help desk, and the janitor. Throw them all in. And a customer or two – don’t forget them. Oh, and for God’s sake, whatever you do, don’t toss an agile coach in there, they’ll tell everyone how to do it and just screw everything up.

    That should get them started. It could be structured like the marketplace in open space. Everyone with an idea goes to the center of the room and writes their idea on a sheet of paper. They stand up and announce the idea, then go to some agreed upon area and wait to see who shows up. Simple. Then let people go wherever their interest takes them. They can be butterflies, bumble bees, whatever makes them happy. If you come up with a new idea (and hopefully people will) then you just write it down and announce it to the group. If there are no takers, no problem: you can decide to continue on your own and develop the idea to the point where it attracts more interest or you can dump it and look at someone else’s idea.

    That’s really all there is to it. From here on out you just stand back and let it go. The teams that form will decide how to work together. If someone doesn’t like it, they can move on, make their own team or join another one. No managers. No scrum masters. Just:

    Water frequently…

    Place in direct sunlight…

    And let it grow…

    Filed under: Agile, Coaching, Swarming, Teams Tagged: initiation, self-organization, starting, Swarming, team building, team creation
    Categories: Blogs

    Knowledge Sharing

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