Skip to content

Feed aggregator

R: non-numeric argument to binary operator

Mark Needham - Mon, 04/20/2015 - 01:08

When debugging R code, given my Java background, I often find myself trying to print out the state of variables along with an appropriate piece of text like this:

names = c(1,2,3,4,5,6)
> print("names: " + names)
Error in "names: " + names : non-numeric argument to binary operator

We might try this next:

> print("names: ", names)
[1] "names: "

which doesn’t actually print the names variable – only the first argument to the print function is printed.

We’ll find more success with the paste function:

> print(paste("names: ", names))
[1] "names:  1" "names:  2" "names:  3" "names:  4" "names:  5" "names:  6"

This is an improvement but it repeats the ‘names:’ prefix multiple times which isn’t what we want. Introducing the toString function gets us over the line:

> print(paste("names: ", toString(names)))
[1] "names:  1, 2, 3, 4, 5, 6"
Categories: Blogs

Faster Word Puzzles with Neo4J

Mistaeks I Hav Made - Nat Pryce - Sun, 04/19/2015 - 22:08
When I used Neo4J to create and solve Word Morph puzzles, I brute-forced the algorithm to find and link words that differ by one letter. I was lucky – my dataset only contained four-letter words and so was small enough for my O(n2) algorithm to run in a reasonable amount of time. But what happens when I expand my dataset to include words of 4, 5 and 6 letters? Obviously, I have to change my Cypher to only relate words that are the same length: match (w1), (w2) where w2.word > w1.word and length(w1.word) = length(w2.word) with w1, w2, length([i in range(0,length(w1.word)) where substring(w1.word,i,1) <> substring(w2.word,i,1)]) as diffCount where diffCount = 1 create (w1)-[:STEP]->(w2) create (w2)-[:STEP]->(w1) But with the larger dataset, this query takes a very long time to run. I don’t know how long – I’ve never been patient enough to wait for the query to complete. I need a better algorithm. Nikhil Kuriakose has also written about solving these puzzles with Neo4J. He used a more sophisticated algorithm to create the graph. He first grouped words into equivalence classes, each of which contains words that are the same except at one letter position. So, for instance, the class P_PE would contain PIPE, POPE, etc., the class PIP_ would contain PIPE, PIPS, etc., and so on. He then created relationships between all the words in each equivalence class. This also has a straightforward representation as a property graph. An Equivalence class can be represented by an Equivalence node with a pattern property, and a word’s membership of an equivalence class can be represented by a relationship from the Word node to the Equivalence node. Words related via equivalence classes Nikhil implemented the algorithm in Java, grouping words with a HashMap and ArrayLists before loading them into Neo4J. But by modelling equivalence classes in the graph, I can implement the algorithm in Cypher – no Java required. For each Word in the database, my Cypher query calculates the patterns of the equivalence classes that the word belongs to, creates Equivalence nodes if for the patterns, and creates an :EQUIV relationship from the Word node to each Equivalence node. The trick is to only create Equivalence nodes for a pattern once, when one doesn’t yet exist, and subsequently use the same Equivalence node for the same pattern. This is achieved by creating Equivalence nodes with Cypher’s MERGE clause. MERGE either matches existing nodes and binds them, or it creates new data and binds that. It’s like a combination of MATCH and CREATE that additionally allows you to specify what happens if the data was matched or created. Before using MERGE, I must define a uniqueness constraint on the pattern property of the Equivalence nodes that will be used to identify nodes in the MERGE command. This makes Neo4J create an index for the property and ensures that the merge has reasonable performance. create constraint on (e:Equivalence) assert e.pattern is unique Then I relate all the Word nodes in my database to Equivalence nodes: match(w:Word) unwind [i in range(0,length(w.word)-1) | substring(w.word,0,i)+"_"+substring(w.word,i+1)] as pattern merge (e:Equivalence {pattern:pattern}) create (w)-[:EQUIV]->(e) This takes about 15 seconds to run. Much less time for my large dataset than my first, brute-force approach took for the small dataset of only four-letter words. Now that the words are related to their equivalence classes, there is no need to create relationships between the words directly. I can query via the Equivalence nodes: match (start {word:'halt'}), (end {word:'silo'}), p = shortestPath((start)-[*]-(end)) unwind [n in nodes(p)|n.word] as step with step where step is not null return step Giving: step ---- halt hilt silt silo Returned 4 rows in 897 ms. And it now works for longer words: step ---- candy bandy bands bends beads bears hears heart Returned 8 rows in 567 ms. Organising the Data During Import The Cypher above organised Word nodes that I had already loaded into my database. But if starting from scratch, I can organise the data while it is being imported, by using MERGE and CREATE clauses in the LOAD CSV command. load csv from "file:////puzzle-words.csv" as l create (w:Word{word:l[0]}) with w unwind [i in range(0,length(w.word)-1) | substring(w.word,0,i)+"_"+substring(w.word,i+1)] as pattern merge (e:Equivalence {pattern:pattern}) create (w)-[:EQUIV]->(e)
Categories: Blogs

R: Removing for loops

Mark Needham - Sun, 04/19/2015 - 01:53

In my last blog post I showed the translation of a likelihood function from Think Bayes into R and in my first attempt at this function I used a couple of nested for loops.

likelihoods = function(names, mixes, observations) {
  scores = rep(1, length(names))
  names(scores) = names
  for(name in names) {
      for(observation in observations) {
        scores[name] = scores[name] *  mixes[[name]][observation]      
Names = c("Bowl 1", "Bowl 2")
bowl1Mix = c(0.75, 0.25)
names(bowl1Mix) = c("vanilla", "chocolate")
bowl2Mix = c(0.5, 0.5)
names(bowl2Mix) = c("vanilla", "chocolate")
Mixes = list("Bowl 1" = bowl1Mix, "Bowl 2" = bowl2Mix)
Observations = c("vanilla", "vanilla", "vanilla", "chocolate")
l = likelihoods(Names, Mixes, Observations)
> l / sum(l)
  Bowl 1   Bowl 2 
0.627907 0.372093

We pass in a vector of bowls, a nested dictionary describing the mixes of cookies in each bowl and the observations that we’ve made. The function tells us that there’s an almost 2/3 probability of the cookies coming from Bowl 1 and just over 1/3 of being Bowl 2.

In this case there probably won’t be much of a performance improvement by getting rid of the loops but we should be able to write something that’s more concise and hopefully idiomatic.

Let’s start by getting rid of the inner for loop. That can be replace by a call to the Reduce function like so:

likelihoods2 = function(names, mixes, observations) {
  scores = rep(0, length(names))
  names(scores) = names
  for(name in names) {
    scores[name] = Reduce(function(acc, observation) acc *  mixes[[name]][observation], Observations, 1)
l2 = likelihoods2(Names, Mixes, Observations)
> l2 / sum(l2)
  Bowl 1   Bowl 2 
0.627907 0.372093

So that’s good, we’ve still got the same probabilities as before. Now to get rid of the outer for loop. The Map function helps us out here:

likelihoods3 = function(names, mixes, observations) {
  scores = rep(0, length(names))
  names(scores) = names
  scores = Map(function(name) 
    Reduce(function(acc, observation) acc *  mixes[[name]][observation], Observations, 1), 
l3 = likelihoods3(Names, Mixes, Observations)
> l3
$`Bowl 1`
$`Bowl 2`

We end up with a list instead of a vector which we need to fix by using the unlist function:

likelihoods3 = function(names, mixes, observations) {
  scores = rep(0, length(names))
  names(scores) = names
  scores = Map(function(name) 
    Reduce(function(acc, observation) acc *  mixes[[name]][observation], Observations, 1), 
l3 = likelihoods3(Names, Mixes, Observations)
> l3 / sum(l3)
Bowl 1.vanilla Bowl 2.vanilla 
      0.627907       0.372093

Now we just have this annoying ‘vanilla’ in the name. That’s fixed easily enough:

likelihoods3 = function(names, mixes, observations) {
  scores = rep(0, length(names))
  names(scores) = names
  scores = Map(function(name) 
    Reduce(function(acc, observation) acc *  mixes[[name]][observation], Observations, 1), 
  result = unlist(scores)
  names(result) = names
l3 = likelihoods3(Names, Mixes, Observations)
> l3 / sum(l3)
  Bowl 1   Bowl 2 
0.627907 0.372093

A slightly cleaner alternative makes use of the sapply function:

likelihoods3 = function(names, mixes, observations) {
  scores = rep(0, length(names))
  names(scores) = names
  scores = sapply(names, function(name) 
    Reduce(function(acc, observation) acc *  mixes[[name]][observation], Observations, 1))
  names(scores) = names
l3 = likelihoods3(Names, Mixes, Observations)
> l3 / sum(l3)
  Bowl 1   Bowl 2 
0.627907 0.372093

That’s the best I’ve got for now but I wonder if we could write a version of this using matrix operations some how – but that’s for next time!

Categories: Blogs

What if we fail?

Ben Linders - Sat, 04/18/2015 - 10:46
People are often afraid to make mistakes. They do things to prevent that something might go wrong and avoid doing things that might fail. And if it does go wrong then they don't talk about it. Is it really bad if once in a while something goes wrong? If something can go wrong, let arrange for it to happen as soon as possible, because then you can quickly learn from it. Create a culture where failure is allowed so that we can all learn from it and find ways to make fewer mistakes! Continue reading →
Categories: Blogs

Life Quotes That Will Change Your Life

J.D. Meier's Blog - Sat, 04/18/2015 - 08:41

Life’s better with the right words.

And life quotes can help us live better.

Life quotes are a simple way to share some of the deepest insights on the art of living, and how to live well.

While some people might look for wisdom in a bottle, or in a book, or in a guru at the top of a mountain, surprisingly, a lot of the best wisdom still exists as quotes.

The problem is they are splattered all over the Web.

The Ultimate Life Quotes Collection

My ultimate Life Quotes collection is an attempt to put the best quotes right at your fingertips.

I wanted this life quotes collection to answer everything from “What is the meaning of life?” to “How do you live the good life?” 

I also wanted this life quotes collection to dive deep into all angles of life including dealing with challenges, living with regrets, how to find your purpose, how to live with more joy, and ultimately, how to live a little better each day.

The World’s Greatest Philosophers at Your Fingertips

Did I accomplish all that?

I’m not sure.  But I gave it the old college try.

I curated quotes on life from an amazing set of people including Dr. Seuss, Tony Robbins, Gandhi, Ralph Waldo Emerson, James Dean, George Bernard Shaw, Virginia Woolf, Buddha, Lao Tzu, Lewis Carroll, Mark Twain, Confucius, Jonathan Swift, Henry David Thoreau, and more.

Yeah, it’s a pretty serious collection of life quotes.

Don’t Die with Your Music Still In You

There are many messages and big ideas among the collection of life quotes.  But perhaps one of the most important messages is from the late, great Henry David Thoreau:

“Most men lead lives of quiet desperation and go to the grave with the song still in them.” 

And, I don’t think he meant play more Guitar Hero.

If you’re waiting for your chance to rise and shine, chances come to those who take them.

Not Being Dead is Not the Same as Being Alive

E.E. Cummings reminds us that there is more to living than simply existing:

“Unbeing dead isn’t being alive.” 

And the trick is to add more life to your years, rather than just add more years to your life.

Define Yourself

Life quotes teach us that living live on your terms starts by defining yourself.  Here are big, bold words from Harvey Fierstein that remind us of just that:

“Never be bullied into silence. Never allow yourself to be made a victim. Accept no one’s definition of your life; define yourself.”

Now is a great time to re-imagine all that you’re capable of.

We Regret the Things We Didn’t Do

It’s not usually the things that we do that we regret.  It’s the things we didn’t do:

“Of all sad words of tongue or pen, the saddest are these, ‘It might have been.”  – John Greenleaf Whittier

Have you answered to your calling?

Leave the World a Better Place

One sure-fire way that many people find their path is they aim to leave the world at least a little better than they found it.

“To laugh often and much; to win the respect of intelligent people and the affection of children…to leave the world a better place…to know even one life has breathed easier because you have lived. This is to have succeeded.” -- Ralph Waldo Emerson

It’s a reminder that we can measure our life by the lives of the people we touch.

You Might Also Like

7 Habits of Highly Motivated People

10 Leadership Ideas to Improve Your Influence and Impact

Boost Your Confidence with the Right Words

The Great Inspirational Quotes Revamped

The Great Leadership Quotes Collection Revamped

Categories: Blogs

What good listeners do

Via First Among Equals, from The Trusted Advisor, what good listeners do:
  1. Probe for clarification
  2. Listen for unvoiced emotions
  3. Listen for the story
  4. Summarize well
  5. Empathize
  6. Listen for what's different, not for what's familiar
  7. Take it all seriously (don't say, "you shouldn't worry about that")
  8. Spot hidden assumptions
  9. Let the other person "get it out of his or her system"
  10. Ask, "How do you feel about that?"
  11. Keep the other person talking ("What else have you considered?")
  12. Keep asking for more detail that helps to understand
  13. Get rid of distractions while listening
  14. Focus on hearing their version first
  15. Let them tell their story their way
  16. Stand in their shoes, at least while listening
  17. Ask them how they think you might be of help
  18. Ask what they've thought of before telling them what you've thought of
  19. Look at (not stare at) the person as s/he speaks
  20. Look for "congruency" (or incongruity) between what the person says and how s/he gestures and postures
  21. Make it seem as if the other person is the only thing that matters and that they have all the time in the world
  22. Encourage by nodding head or giving a slight smile
  23. Show awareness and control of body movement (no moving around, shaking legs, fiddling with a paper clip)
Categories: Blogs

Common traits of trusted advisors

Via First Among Equals, from The Trusted Advisor, common traits of trusted advisors:
  1. Seem to understand us, effortlessly, and like us
  2. Are consistent: we can depend on them
  3. Always help us see things from fresh perspectives
  4. Don't try to force things on us
  5. Help us think things through (it's our decision)
  6. Don't substitute their judgment for ours
  7. Don't panic or get overemotional: they stay calm
  8. Help us think and separate our logic from our emotion
  9. Criticize and correct us gently, lovingly
  10. Don't pull their punches: we can rely on them to tell us the truth
  11. Are in it for the long haul: the relationship is more important than the current issue
  12. Give us reasoning (to help us think), not just their conclusions
  13. Give us options, increase our understanding of those options, give us their recommendation, and let us choose
  14. Challenge our assumptions: help us uncover the false assumptions we've been working under
  15. Make us feel comfortable and casual personally, but they take the issues seriously
  16. Act like a person, not someone in a role
  17. Are reliably on our side, and always seem to have our interests at heart
  18. Remember everything we ever said (without notes)
  19. Are always honorable: they don't gossip about others (we trust their values)
  20. Help us put our issues in context, often through the use of metaphors, stories, and anecdotes (few problems are completely unique)
  21. Have a sense of humour to diffuse our tension in tough situations
  22. Are smart sometimes in ways we're not
As someone who advises others, how well does this describe me?
Categories: Blogs

Making Sure They Do It the “Right Way”

Leading Agile - Mike Cottmeyer - Fri, 04/17/2015 - 23:21

In a Certified Scrum Product Owner class I was teaching recently we got to the part about how it was up to the teams to figure out the best way to solve the business problems presented in the User Stories. We discussed the logic behind this and everyone seemed to be in agreement that it made sense that the people who do the design/coding/testing on a daily basis were the ones most familiar with the technology, the environment and the context of the needs of the end user and that it made sense for them to find the best way to meet the needs of the end user.

It was all going just fine until one of the participants in the class asked a very simple question…

“How do I know they are going to do it the right way?”

The question came from someone who was moving out of the role of lead developer into a Product Owner role.

The short answer, “You don’t. You have to trust them.”

He winced. And this is where things got twitchy. The person asking the question understood that he was supposed to trust. The problem was that understanding this intellectually, and actually doing it were two completely different things.

“Yeah, I know… but really… how do I know they’ll do it the right way?”

We talked about shaping the scope with the Acceptance Criteria, and talking with the team about any known challenges they were going to face, but that at the end of the day, it was the people doing the work that were going to have to be given the freedom to find the best way to solve the challenge placed before them. The “… but really…” question was raised a few more times and it seemed like there was a fading, desperate hope that there was going to be some secret magic answer or trick that would resolve the fear that “they” might make a mistake. Unfortunately, there is no magic answer to this. The simple fact is, “they” might solve the problem in a way that met all the needs of the User Story and it’s Acceptance Criteria but it might not be in line with how the PO would have solved the problem on his own. There is the chance that the solution the PO had in mind might have been a better way, but there is also a possibility that a team of talented, skilled individuals, working together might come up with a solution that was as good, or possibly better, than what the PO was envisioning.

If the Team delivered a solution that met the needs of the story but was somehow still not what was needed, this would become apparent during the Sprint Review meeting when the work was shown to the Stakeholders. One of the benefits of working in short iterations is that we can find problems and learn from them quickly, getting better every step of the way – both in delivering value and in working together. The longer the PO and the Team worked together, the better they get at defining and working on the User Stories.

For this particular PO, and for many people who are moving towards Agile, being open to the possibility that others may have solutions which are as good as, or better than we have isn’t an easy pill to swallow. One of the dysfunctions inherent in a traditional approach is that a command and control way of working was put in place because of the the assumption that if we don’t tell people how to do something, they’ll do it wrong.

But what if they won’t? What if they’re as smart, or smarter than us? Are we willing to let go and accept the risk of trusting again? It’s easy to say yes, but actually doing it – that is much harder. It is also one of the most challenging parts of making the switch to Agile.

Regardless of whether you are a member of the Team doing the work, someone playing the role of Product Owner or ScrumMaster, recognizing the places where the fear of trusting creeps in, observing your reaction and finding a way to take the chance of trusting people again is always hard. And it isn’t just about trusting others. We also have to learn to trust ourselves to make good choices and allow for the possibility of making mistakes and learning from them. How else are we going to get better?

Regarding the light bulb, Thomas Edison is often quoted as having said:

“I have not failed. I just found 10,000 ways that won’t work.”

If Edison had not been given the chance to find the best way to create his version of the light bulb our world would be very different than it is today.

The Scrum Guide says “Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” This may well be true, but for Agile to sink in and really take root, those three pillars have to stand on a solid foundation of trust. What we trust in is not that people will always be “right”, but that we will run these experiments and learn every step of the way.

And who knows, there is always the chance that the Team may surprise you by coming up with a solution that is even better than the one you had in mind.

The post Making Sure They Do It the “Right Way” appeared first on LeadingAgile.

Categories: Blogs

Testomato monitors your website and alerts you if anything important breaks - Fri, 04/17/2015 - 23:00
Monitor both your staging and production environments to catch problems immediately. Instead of worrying, know when something is broken so you can fix it fast.
Categories: Communities

Topics for Lunch-N-Learn

Agile Complexification Inverter - Fri, 04/17/2015 - 19:57

Brainstorming a list of topics for a Scrum/Agile lunch-N-learn session.

Slicing Stories – resources to slice vertical stories of valueStory Writing techniques:  w/ Q&A based upon participants real storiesEstimation techniques:  Affinity Estimation; T-shirt sizing -> converting to numbers; Planning Poker (the rule book)Team building tools:  Infinite Loops; Helium Stick; Warp Speed;  Pair Drawing, etc.Definition of Done/Ready exerciseRelease Planning   How to derive duration with a complicated backlogAgile Library Initiation  Bring books, make the rules, get funding, 1,2,3, GO!Management 3.0 Book Club - join a group reading the best Agile book written.Making Visual Information Radiators - define Radiator/Cooler;  elements of a Scrum boardAspects of an effective Product BacklogAgile Portfolio Planning - tools and techniques; estimation, cost of delay, prioritization, deciding what NOT to doThe principle of TDD via LEGO building;  anyone can learn the power of test first developmentDoes you development rest on a SOLID foundation - an overview of the SOLID principlesCollaboration Games to understand the customer;   12 Innovation Games;  Other resourcesUser Story Maps technique to achieve higher level understanding of the backlogLaunching a Team;  what’s required, best practices, examples and techniquesTeam Practices:  a collection of quick tools to increase team work and collaborationLearn Backlog Prioritization techniques:  Cost of Delay,  Perceived ROI,  Delivery Order, Gut Feeling, Loudest Yeller

see also:
Categories: Blogs

Saga Implementation Patterns: Singleton

Jimmy Bogard - Fri, 04/17/2015 - 17:38

NServiceBus sagas are great tools for managing asynchronous business processes. We use them all the time for dealing with long-running transactions, integration, and even places we just want to have a little more control over a process.

Occasionally we have a process where we really only need one instance of that process running at a time. In our case, it was a process to manage periodic updates from an external system. In the past, I’ve used Quartz with NServiceBus to perform job scheduling, but for processes where I want to include a little more information about what’s been processed, I can’t extend the Quartz jobs as easily as NServiceBus saga data. NServiceBus also provides a scheduler for simple jobs but they don’t have persistent data, which for a periodic process you might want to keep.

Regardless of why you’d want only one saga entity around, with a singleton saga you run into the issue of a Start message arriving more than once. You have two options here:

  1. Create a correlation ID that is well known
  2. Force a creation of only one saga at a time

I didn’t really like the first option, since it requires whomever starts to the saga to provide some bogus correlation ID, and never ever change that ID. I don’t like things that I could potentially screw up, so I prefer the second option. First, we create our saga and saga entity:

public class SingletonSaga : Saga<SingletonData>,
    protected override void ConfigureHowToFindSaga(
    	SagaPropertyMapper<SingletonData> mapper)
    	// no-op

    public void Handle(StartSingletonSaga message)
        if (Data.HasStarted)

        Data.HasStarted = true;
        // Do work like request a timeout
        RequestTimeout(TimeSpan.FromSeconds(30), new SagaTimeout());
    public void Timeout(SagaTimeout state)
    	// Send message or whatever work

Our saga entity has a property “HasStarted” that’s just used to track that we’ve already started. Our process in this case is a periodic timeout and we don’t want two sets of timeouts going. We leave the message/saga correlation piece empty, as we’re going to force NServiceBus to only ever create one saga:

public class SingletonSagaFinder
    : IFindSagas<SingletonSagaData>.Using<StartSingletonSaga>
    public NHibernateStorageContext StorageContext { get; set; }

    public SingletonSagaData FindBy(StartSingletonSaga message)
        return StorageContext.Session

With our custom saga finder we only ever return the one saga entity from persistent storage, or nothing. This combined with our logic for not kicking off any first-time logic in our StartSingletonSaga handler ensures we only ever do the first-time logic once.

That’s it! NServiceBus sagas are handy because of their simplicity and flexibility, and implementing something a singleton saga is just about as simple as it gets.

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

Categories: Blogs

Is LeSS meer dan SAFe?

Xebia Blog - Fri, 04/17/2015 - 15:48

(Grote) Nederlandse bedrijven die op zoek zijn naar een oplossing om de voordelen die hun Agile teams brengen op te schalen, gebruiken vooral het Scaled Agile Framework (SAFe) als referentiemodel. Dit model is -ook voor managers- zeer toegankelijke opgezet en trainingen en gecertificeerde consultants zijn beschikbaar. Al in 2009 beschreven Craig Larman en Bas Vodde hun ervaringen met de toepassing van Scrum in grote organisaties (onder andere Nokia) in hun boeken 'Scaling Lean & Agile Development' en 'Practices for Scaling Lean & Agile Development'. De methode noemden ze Large Scale Scrum, afgekort LeSS.
LeSS heeft de afgelopen jaren een onopvallend bestaan geleid. Onlangs is besloten dit waardevolle gedachtengoed meer in de spotlights te zetten. Er komt in de zomer een derde boek, de site is gelanceerd, er is een trainingen tournee gestart en Craig en Bas geven acte de presence op de toonaangevende conferenties. Zo zal Bas 4 juni als keynote optreden tijdens Xebicon 2015, in Amsterdam. Is LeSS meer of minder dan SAFe? Of min of meer SAFe?

Wat is LeSS?
Less is dus een methode om een grote(re) organisatie met Agile teams als basis in te richten. Zoals de naam verraadt, Scrum is daarbij het uitgangspunt. Er zijn 2 smaken: ‘gewoon’ LeSS, tot 8 teams en Less Huge, vanaf 8 teams. LeSS bouwt op verplichte regels (rules), bijvoorbeeld "An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, ScrumMasters, Team Representatives, and managers (if there are any).” Daarnaast kent LeSS principles (ontwerp criteria). De principes vormen het referentie raamwerk op basis waarvan je de juiste ontwerp besluiten neemt. Tenslotte zijn er de Guidelines en Experiments, de dingen die in de praktijk bij organisaties succesvol of juist niet zijn gebleken. LeSS gaat naast het basis framework verder dieper in op:

  • Structure (de organisatie structuur)
  • Management (de -veranderende- rol van management)
  • Technical Excellence (sterk gebaseerd op XP en Continuous Delivery)
  • Adoption (de transformatie naar de LeSS organisatie).

LeSS in een notendop
De basis van LeSS is dat Large Scale Scrum = Scrum! Net als SAFe wordt in LeSS gezocht naar hoe Scrum toegepast kan worden op een groep van zeg 100 man. LeSS blijft het dichtst bij Scrum: er is 1 sprint, met 1 Product Owner, 1 product backlog, 1 planning en 1 sprint review, waarin 1 product wordt gerealiseerd. Dit is dus anders dan in SAFe, waarin een opgeblazen sprint is gedefinieerd (de Product Increment). Om deze 1 sprint implementatie te kunnen waarmaken is naast een hele sterke whole product focus, bijvoorbeeld ook een technisch platform nodig, dat dit ondersteunt. Waar SAFe pragmatisch een geleidelijke invoering van Agile at Scale toestaat, is LeSS strenger in de klaar-voor-de-start eisen. Er moet een structuur worden neergezet die de cultuur van de 'contract game’ doorbreekt. De cultuur van overvragen, druk, onduidelijkheid, verrassingen, en afrekenende verantwoordelijkheid.

LeSS is meer en minder SAFe
De recente inspanning om LeSS toegankelijk te maken gaan ongetwijfeld leiden tot een sterk toenemende aandacht voor deze aansprekende benadering voor de inrichting van Agile at Scale. LeSS is anders dan SAFe, al hebben beide modellen vooral in hun inspiratiebronnen ook veel gemeen.
Beide modellen kiezen een andere insteek, bijvoorbeeld mbt:

  • hoe Scrum toe te passen op een cluster van teams
  • de benadering van de transformatie naar Agile at Scale
  • hoe oplossingen worden gebracht: SAFe geeft de oplossing, LeSS de voors en tegens van keuzes

Opvallend is verder dat SAFe (met het portfolioniveau) uitlegt hoe de verbinding tussen strategie en backlogs gelegd moet worden. LeSS besteedt daarentegen meer aandacht aan de transformatie (Adoption) en Agile op hele grote schaal (LeSS Huge).

Of een organisatie kiest voor LeSS of SAFe, zal afhangen wat het best past bij de organisatie. Past bij de veranderambitie en bij de ‘agility’ op moment van starten. Sterk ‘blauwe’ organisaties zullen kiezen voor SAFe, organisaties die een overtuigende stap richting een Agile organisatie durven te zetten, zullen eerder kiezen voor LeSS. In beide gevallen loont het om kennis te nemen van de oplossingen die de andere methode biedt.

Categories: Companies

Clickbait is evil!

Scrum Breakfast - Fri, 04/17/2015 - 09:47
Anyone who has taken one of my Scrum classes knows that I believe that multitasking is evil! I have come to realize that clickbait is evil too.

Why? For the same reason. Clickbait, like multitasking, destroys productivity.  At least for my own purposes, I have decided do something about it, and I am wondering if other people feel the same way.

What is clickbait? Let's say you an article open a reputable site, like See all those links on the right side, like Opinion, More Top Stories, Promoted Stories, More from CNN? That's click bait. My guess is 1/3rd of any given web pages consists of catchy headlines whose sole purpose is to get you to spend more time on their site (or maybe, to cash in on Cost-per-Click syndication schemes, to get you go to some other site). By the time you get 2/3rd down the page, 100% of the content is usually clickbait.
What is evil?What do I mean by evil? Evil things are bad for you. Like weeds in the garden or corrupt politicians, you'll never get rid of evil entirely, but if you don't keep the weeds under control, you won't have a garden any more. So we need to keep evil things in check, lest you suffer the consequences. In this case the consequences is massive amounts of wasted time (at least for me it is)!
Why is Multitasking Evil?I have long known that if you have two goals, working them in parallel slows you down. If goal A takes a month, and goal B takes a month, then if you work on A and B in parallel, it will take you at least 2 months before either goal is finished and probably longer. So focusing on one thing at a time usually gives you better results. This is why focus is a core value of Scrum. 
It turns out the situation with multitasking is much worse than I thought.
I recently attended a talk by Prof Lutz Jäncke, the neuropsychologist at the ETH, on why teenagers are the way the are. (The short answer: they are not evil, they are drawn that way. They will be people again when their brains have finished developing -- sometime around 20 years old. But I digress.)
Listening to a neuropsychologist for an hour was very challenging! My brain was very tired after his talk, but one point really stuck out:Multitasking makes you worse at multitasking!To process information effectively, we need to filter irrelevant information. By responding to every stimulus that comes in, we lose the ability to filter junk.
He also asked, have you ever gone to do something on the Internet, lost track of what you are doing and then wasted a tremendous amount of time? You bet! Every day! Why is that? Clickbait. Catchy headlines and dramatic pictures pique my curiosity to send me to the next page.
I realized this was true, and I am now trying to turn down the interruptions on my computer and other devices.Using Adblock Plus to fight clickbaitI have used ABP for a long time to block most ads. But the standard filters only target ads, not clickbait. I discovered you can not only block links, but you can block specific HTML elements. After a bit of experimenting with the block element feature, I was able to filter the clickbait sections of the news and entertainment sites I visit most. 
I was amazed at the difference in how much less clutter and fewer distractions I encountered!
Do you have this problem? Would you like to use my filter list? I don't know if it is worth packaging these filters for distribution. Or of there isn't a filter set somewhere that addresses this problem. So I have simply published this list and installation instructions on as a google doc: It's still pretty short, but if you send me additions, I will integrate them. 
Clickbait is evil. I believe reducing clickbait will be good for my performance, and it probably will be for yours as well. If you install it, please put out a tweet like this:
"Just installed @peterstev's clickbait filter! #clickbaitisevil!"

Categories: Blogs

R: Think Bayes – More posterior probability calculations

Mark Needham - Thu, 04/16/2015 - 22:57

As I mentioned in a post last week I’ve been reading through Think Bayes and translating some of the examples form Python to R.

After my first post Antonios suggested a more idiomatic way of writing the function in R so I thought I’d give it a try to calculate the probability that combinations of cookies had come from each bowl.

In the simplest case we have this function which takes in the names of the bowls and the likelihood scores:

f = function(names,likelihoods) {
  # Assume each option has an equal prior
  priors = rep(1, length(names)) / length(names)
  # create a data frame with all info you have
  dt = data.frame(names,priors,likelihoods)
  # calculate posterior probabilities
  dt$post = dt$priors*dt$likelihoods / sum(dt$priors*dt$likelihoods)
  # specify what you want the function to return
  list(names=dt$names, priors=dt$priors, likelihoods=dt$likelihoods, posteriors=dt$post)  

We assume a prior probability of 0.5 for each bowl.

Given the following probabilities of of different cookies being in each bowl…

mixes = {
  'Bowl 1':dict(vanilla=0.75, chocolate=0.25),
  'Bowl 2':dict(vanilla=0.5, chocolate=0.5),

…we can simulate taking one vanilla cookie with the following parameters:

Likelihoods = c(0.75,0.5)
Names = c("Bowl 1", "Bowl 2")
> res$posteriors[res$name == "Bowl 1"]
[1] 0.6
> res$posteriors[res$name == "Bowl 2"]
[1] 0.4

If we want to simulate taking 3 vanilla cookies and 1 chocolate one we’d have the following:

Likelihoods = c((0.75 ** 3) * (0.25 ** 1), (0.5 ** 3) * (0.5 ** 1))
Names = c("Bowl 1", "Bowl 2")
> res$posteriors[res$name == "Bowl 1"]
[1] 0.627907
> res$posteriors[res$name == "Bowl 2"]
[1] 0.372093

That’s a bit clunky and the intent of ‘3 vanilla cookies and 1 chocolate’ has been lost. I decided to refactor the code to take in a vector of cookies and calculate the likelihoods internally.

First we need to create a data structure to store the mixes of cookies in each bowl that we defined above. It turns out we can do this using a nested list:

bowl1Mix = c(0.75, 0.25)
names(bowl1Mix) = c("vanilla", "chocolate")
bowl2Mix = c(0.5, 0.5)
names(bowl2Mix) = c("vanilla", "chocolate")
Mixes = list("Bowl 1" = bowl1Mix, "Bowl 2" = bowl2Mix)
> Mixes
$`Bowl 1`
  vanilla chocolate 
     0.75      0.25 
$`Bowl 2`
  vanilla chocolate 
      0.5       0.5

Now let’s tweak our function to take in observations rather than likelihoods and then calculate those likelihoods internally:

likelihoods = function(names, observations) {
  scores = c(1,1)
  names(scores) = names
  for(name in names) {
      for(observation in observations) {
        scores[name] = scores[name] *  mixes[[name]][observation]      
f = function(names,mixes,observations) {
  # Assume each option has an equal prior
  priors = rep(1, length(names)) / length(names)
  # create a data frame with all info you have
  dt = data.frame(names,priors)
  dt$likelihoods = likelihoods(Names, Observations)
  # calculate posterior probabilities
  dt$post = dt$priors*dt$likelihoods / sum(dt$priors*dt$likelihoods)
  # specify what you want the function to return
  list(names=dt$names, priors=dt$priors, likelihoods=dt$likelihoods, posteriors=dt$post)  

And if we call that function:

Names = c("Bowl 1", "Bowl 2")
bowl1Mix = c(0.75, 0.25)
names(bowl1Mix) = c("vanilla", "chocolate")
bowl2Mix = c(0.5, 0.5)
names(bowl2Mix) = c("vanilla", "chocolate")
Mixes = list("Bowl 1" = bowl1Mix, "Bowl 2" = bowl2Mix)
Observations = c("vanilla", "vanilla", "vanilla", "chocolate")
> res$posteriors[res$names == "Bowl 1"]
[1] 0.627907
> res$posteriors[res$names == "Bowl 2"]
[1] 0.372093

Exactly the same result as before! #win

Categories: Blogs

Join Me in Australia in June!

Agile Product Owner - Thu, 04/16/2015 - 17:56


This June, I’ll be busy in Australia presenting a SAFe SPC certification class, and speaking at Agile Australia as an invited spearker where I’ll lead workshops, and present “Nine Immutable Principles of Lean-Agile Development.”

Agile Australia 2015

Invited Speaker Track: Nine Immutable Principles of Lean-Agile Development

Half-day Workshops: Foundations of the Scaled Agile Framework

Sydney 16 June (two workshops); Melbourne 19 June 2015 (AM only).

In this half-day workshop, you’ll learn the foundations of the Scaled Agile Framework (SAFe), its values and underlying principles of Agile, Lean and Product Development Flow. This course will enable you to leave with an understanding of how the principles and practices of SAFe support large scale Agile Software Programs,  Lean Systems Engineering and Agile Portfolio Management. You’ll also learn about effective strategies for implementing SAFe, including the critical role that Leadership plays. These rare half-day workshops provide a personal setting that helps assure effective knowledge exchange.

See detailed descriptions and register at Earlybird registration closes on Friday 24 April 2015, and you can get a further discount using this promo code, AA15-SFND

SAFe Program Consultant Certification June 22-25, 2015

Logo_ContextMatters_DirectoryThis is the official 4-day SAFe Certification Program which results in the SAFe Program Consultant (SPC) Certification. I don’t get a chance to deliver this workshop myself that often anymore, especially in Asia-Pacific, so I encourage you to attend this unique event. We’ll be working with our local Gold Partners Context Matters, and you can contact Mark or Em for more information. Early bird pricing is available until 22, May 2015.

I hope to see you in Australia!


Categories: Blogs

How We Can Inspire a Million Children to Become Engineers

Agile Management Blog - VersionOne - Thu, 04/16/2015 - 14:37


We can all agree that inspiring children to become engineers and scientists is of utter importance. However making a difference on a local level seems intimidating. But it doesn’t have to be so difficult.

Learn how you can help us inspire a million children to become engineers by providing just a few hours a month and a safe, collaborative meeting space.

The Challenge

A few years ago Robert Holler, the president and CEO of VersionOne, challenged VersionOne employees to come up with an idea that would help children in our local community learn about programming and technology. This seemed like an exciting, though daunting, community service project.

At VersionOne we feel it is an important responsibility to help the community. That doesn’t mean just the agile community, but also the local community. In fact, Gartner recently recognized our strong community presence in the Magic Quadrant for Application Development Lifecycle Management report.

Typically when we do local community projects they are hosted by charities that manage projects. This project, on the other hand, would be completely managed by VersionOne employees. At first, this seemed like it might take a lot more time and effort than any of us really had. Nonetheless, we were very excited to try to make it work.event_258537472

There were a lot of ideas that would need varying degrees of resources, but after a little research we discovered the global CoderDojo movement. It was a movement started in Ireland in 2011 by an eighteen-year-old student and a serial entrepreneur. They developed a vision for creating a safe and collaborative environment in which experienced adult mentors help students who want to learn about technology and programming. Their model was fairly lean, making it easy to launch. Parents bring their kids and their own laptops, so we just needed space and mentors to get started.

Since VersionOne is an agile lifecycle management company, we were attracted to the lean nature of this program. Soon after, CoderDojo Ponce Springs was born!

How It Works

The way it works is that parents bring their kids, ages 7 through 17, with laptops in hand to a meeting place. (In our case, we also have a limited number of laptops that have been donated by VersionOne for kids who don’t have a laptop). Volunteers help the students learn a programming language or other creative tools.


There are tons of great free resources like, Khan Academy, Codecademy,, Scratch, Blockly Games, and more. This makes it less burdensome for new volunteers to help because they don’t need to spend hours and hours creating their own resources.

However, a number of our volunteers have devoted additional time to creating step-by-step tutorials and interactive tools tailored to the needs of students who have been through the beginner materials online and want to more challenging things like building plugins for Minecraft or learning about building HTML5 JavaScript games.

Student-Driven Learning

We should stress, however, that the bulk of the work is on the students themselves! Mentors are there to assist and inspire, but not to provide long, drawn-out lectures. Students rapidly get hands on with the technologies and help each other learn. It’s a theme that’s woven throughout the CoderDojo movement. One of its own mentors is Sugata Mitra, who has conducted some amazing experiments in child-driven learning. Check out his TED talks to see what he discovered about the innate curiosity and capacity for learning and teaching that children possess.

Want to Start Your Own CoderDojo?

We share code and resources in GitHub in this open source and forkable CoderDojoPonceSprings repository. Feel free to create a copy of it and start one in your own community! Our Dojos take place in downtown Atlanta and in Alpharetta, Georgia, but one of our volunteers cloned our content and started a brand new CoderDojo in Henry County, about 30 minutes south of Atlanta.


It has been exciting to see the program still going strong for more than two years. The majority of the students are returning students, a good indication of the value they are getting from the program. In fact, many of the students have been participating for the entire program, and are becoming quite advanced. These are the students who have encouraging parents and peers outside of the Dojo as well, because it takes more just attending a Dojo to become really advanced.

What a CoderDojo is best at is providing the safe, collaborative environment for students who are ready and willing to learn to meet other enthusiastic peers with whom they can collaborate and increase their knowledge. Research has shown that when someone is learning something new, they often learn best from peers who are just slightly ahead. A CoderDojo also provides students who want to help others an opportunity to start giving back immediately. In one particular case, we had a student serve as a mentor to much younger students. He is thirteen and participated in a special event with students from an Atlanta elementary school.

A Million Children

Making a difference in the world can seem like a daunting feat, but the greatest lesson that I think has come out of our CoderDojo project is that by simply providing some space and time, we can inspire the next generation to get excited about programming and technology.

We probably have 300 different children come to our program each year. Over the next five years we hope to inspire 1,500 children in our program. If each of the three chapters that launched after ours has the same results, together we will inspire 4,500 children. And if 223 companies are willing to join us, we all can inspire 1,000,000 children over the next five years.

Volunteers in our Dojo are currently collaborating on tools and content to make starting a new CoderDojo even easier, if you’re interested to learn more or start your own CoderDojo, email us at

So what do you have to say, will you help us inspire the next generation of software programmers?

Categories: Companies

Experimenting with Swift and UIStoryboardSegues

Xebia Blog - Wed, 04/15/2015 - 22:58

Lately I've been experimenting a lot with doing things differently in Swift. I'm still trying to find best practices and discover completely new ways of doing things. One example of this is passing objects from one view controller to another through a segue in a single line of code, which I will cover in this post.

Imagine two view controllers, a BookViewController and an AuthorViewController. Both are in the same storyboard and the BookViewController has a button that pushes the AuthorViewController on the navigation controller through a segue. To know which author we need to show on the AuthorViewController we need to pass an author object from the BookViewController to the AuthorViewController. The traditional way of doing this is giving the segue an identifier and then setting the object:

class BookViewController: UIViewController {

    var book: Book!

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        if segue.identifier == "ShowAuthor" {
            let authorViewController = segue.destinationViewController as! AuthorViewController

class AuthorViewController: UIViewController {

    var author: Author!

And in case we would use a modal segue that shows a AuthorViewController embedded in a navigation controller, the code would be slightly more complex:

if segue.identifier == "ShowAuthor" {
  let authorViewController = (segue.destinationViewController as! UINavigationController).viewControllers[0] as! AuthorViewController =

Now let's see how we can add an extension to UIStoryboardSegue that makes this a bit easier and works the same for both scenarios. Instead of checking the segue identifier we will just check on the type of the destination view controller. We assume that based on the type the same object is passed on, even when there are multiple segues going to that type.

extension UIStoryboardSegue {

    func destinationViewControllerAs<T>(cl: T.Type) -> T? {
        return destinationViewController as? T ?? (destinationViewController as? UINavigationController)?.viewControllers[0] as? T

What we've done here is add the method destinationViewControllerAs to UIStoryboardSegue that checks if the destinationViewController is of the generic type T. If it's not, it will check if the destinationViewController is a navigation controller and if it's first view controller is of type T. If it finds either one, it will return that instance of T. Since it can also be nil, the return type is an optional T.

It's now incredibly simple to pass on our author object to the AuthorViewController:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
  segue.destinationViewControllerAs(AuthorViewController.self)?.author =

No need to check any identifiers anymore and less code. Now I'm not saying that this is the best way to do it or that it's even better than the traditional way of doing things. But it does show that Swift offers us new ways of doing things and it's worth to experiment to find best practices.

The source code of the samples and extension is available on

Categories: Companies

11 years at ThoughtWorks - Wed, 04/15/2015 - 22:45

I had planned to write a 10 years at ThoughtWorks post but was busy on a sabbatical learning a real language (German!) This year, I decided to get around to writing an anniversary post. One of the current impressive employee benefits for long-time employees is a 12-week paid break (it’s mandatory law in Australia but not true around the world).

When I think about my time here at ThoughtWorks, I can’t believe that I have been here so long. I still remember, after graduating from University, thinking how unlikely I would stay with a company for more than two years because I wanted to learn, change and grow. I thought that would be difficult in a permanent position in any other company. I wanted to stay in the zone but also find an opportunity to do interesting work. Consulting proved to be a good middle ground for what I was looking for.

What a ride it has been. Oh, and it’s still going, too :)


Like most companies, ThoughtWorks has changed and evolved over time.

  • When I started, we had (I’m guessing) about 10 offices in four countries. As of this post, we have 30 offices in 12 countries (Australia, Brazil, Canada, China, Ecuador, Germany, India, Singapore, South Africa, Uganda, the United Kingdom, and the United States) in some places I would never have guessed we would have had offices.
  • When I started, we had maybe 500 employees worldwide. We now have around between 2500-3000 people.
  • When I started, we were pretty much a consulting firm doing software development projects. Since then we now have a product division, a highly integrated UX capability, and are influencing companies at the CxO level which means a different type of consulting (whilst still keeping to our core offering of delivering effective software solutions).

We don’t always get things right, but I do see ThoughtWorks takes risks. In doing so, that means trying things and being prepared to fail or succeed. Although we have grown, I have found it interesting to see how our culture remains, in some ways very consistent, but adapts to the local market cultures and constraints of where we are operating. When I have visited our Brazilian offices, I felt like it was TW but with a Brazilian flavour, likewise when I visit our German offices.


I find it constantly interesting talking to alumni or people who have never worked for ThoughtWorks to see what their perceptions are. With some alumni, they have a very fixed perception of what the company is like (based on their time with the company) and it’s interesting to contrast that view with my own, given that the company constantly changes.

We are still (at least here in the UK) mostly a consulting firm, and so some of the normal challenges with running a consulting business still apply, both from an operational perspective, and being a consultant out on the field. Working on client site often means travel, and still affected by the ebbs and flows of customer demand around client budgeting cycles.

Based on my own personal observations (YMMV) we, as a company, have got a lot better about leadership development and support (although there is always opportunity to improve). I also find that we tend, on average, to get more aligned clients and have opportunities to have a greater impact. We have become better at expressing our values (The Three Pillars) and finding clients where we can help them and they are ready for that help.

It is always hard to see colleagues move on as it means building new relationships but that is always a reality in all firms, and occurs often even more so in consulting firms. After coming back from sabbatical I had to deal with quite a bit of change. Our office had moved, a significant part of our management team had changed, and of course there were lots of new colleagues who I hadn’t met. At the same time, I was surprised to see how many long-time employees (and not just operational people) were still around and it was very comforting to reconnect with them and renew those relationships.


I’ve been particularly proud of some of the impact and some of the opportunities I have had. Some of my personal highlights include:

  • Being the keynote speaker for the 2000-attendee Agile Brazil conference.
  • Publishing my first book, The Retrospective Handbook, a book that makes the agile retrospective practice even more effective.
  • Publishing my second book, Talking with Tech Leads, a book that collects the experiences of Tech Leads around the world aimed at helping new or existing Tech Leads improve their skills.
  • Developing a skills training course for Tech Leads that we run internally. It’s a unique experiential course aimed at raising awareness of and developing the skills developers need when they play the Architect or Tech Lead roles. I may even have an opportunity of running it externally this year.
  • Being considered a role model for how ThoughtWorks employees can have impact on both clients, the industry and within our own company.
Categories: Blogs

Laloux Cultural Model and Agile Adoption

Agile For All - Bob Hartman - Wed, 04/15/2015 - 19:10
Laloux and Agile Adoption My Story

I had invested years of my life in a ground up, large-scale agile adoption. The early years of the adoption seemed to go at breakneck speed. Teams were adopting scrum with great success. People were feeling more engaged, products were getting better, and the company was benefiting. And then it felt like we hit a wall. Despite what felt to me like a groundswell of support from teams, managers, and directors, we were struggling to make the leap to real organizational agility.

The Breakthrough

While reviewing a draft of a good friend’s upcoming book, a single reference leaped off the page:

“There is … evidence that the developmental stage of the CEO determines the success of large-scale transformation programs.” (Tolbert, cited by Laloux, 2014)

I immediately bought and read Frederic Laloux’s book Reinventing Organizations, which provides a comprehensive overview of how humans have organized in groups over the centuries. The prevailing perspective today (what Laloux labels “orange”) seemed to describe my organization in an almost clairvoyant way. It helped me make sense of what my organization valued the most, how I could continue to be effective in my role as agile transformation leader, and what was likely possible given our cultural values. Keep reading to learn more…

Laloux’s Culture Model

I created the following video overview of Laloux’s cultural model and how it applies to Agile adoption in various types of organizations. It’s kind of a whirlwind tour, but I wanted to cover the basics in as succinct a way as possible. Feel free to pause and ponder as you digest the information.



The Rest of the Story…

Did one of the descriptions/colors stick out to you as the prevailing perspective at your organization? How about for you personally? My story takes an interesting twist after reading Laloux’s book. The prevailing perspective at the executive level seemed firmly rooted in Orange. I felt like I was somewhere between green and teal, personally. The difference in what I valued the most, and what the organization valued most, helped me understand why I had been so frustrated with the wall it seemed we had reached at the organizational level.

For me, it seemed I had three options:

  1. Acknowledge the value in an Orange perspective (there is value in every perspective), and work hard to help my organization be a shining example of Orange at its most vibrant.
  2. Seek out leaders with a Green perspective and work with them to try to expand the influence of Green values in the organization.
  3. Leave the organization and seek out Green or Teal organizations where I could grow personally at a faster pace.

Option one had been my journey for the first several years of my work leading our agile transformation. Option two had been my approach for the previous 18 months, but seemed to stall out when we needed executive level support for the types of changes required for a vertical transformation from Orange to Green. For option two, it felt like a waiting game – I could work with Green leaders in the hopes that at some point, the current CEO would either evolve personally, or, as happens frequently in large organizations, a new CEO would eventually come along, and all of the Green level cultural work would be unlocked and begin to flourish. This felt like a crapshoot as to what perspective that new CEO might have, and how long it might be before such a change might occur.

This left me with Option three, and that’s the option I took. While I think I could have provided value helping the organization be the best version of Orange it could, for my own personal growth, I really wanted to advance what’s possible and see how I can add value in a Green or Teal organization. I joined Agile for All knowing that they had been doing some really cool work with organizations adopting a Green/Teal set of practices, and I’m excited to see where we can go with such an approach.

So Now What?

First of all, definitely check out Laloux’s book. He provides fantastic details of how Teal organizations do awesome things.

If you are in a predominantly Amber or Orange organization, we’ve been there! We’ve seen Agile help these organizations get better at what they care about most, be that stability and predictability (Amber), or innovation and competitive advantage (Orange). An Agile mindset and practices will help achieve awesome results, and in a way that is more engaging and fulfilling for the people doing the work.

If you are in a predominantly Green or even a Teal organization, or one interested in moving in that direction, please get in touch! We’d love to hear about how it’s working for you. Whether we can help you out or not, we want to learn more about and help connect organizations taking this approach.

No matter your organization’s primary perspective, if you are interested in learning more about deep, long-lasting organizational transformation then let’s talk! Email me at or just respond to this blog post.

If you think others would be interested in this topic, please share it using one or more of the buttons below.

The post Laloux Cultural Model and Agile Adoption appeared first on Agile For All.

Categories: Blogs

Summary of User Stories: The Three “C”s and INVEST

Learn more about our Scrum and Agile training sessions on WorldMindware.comUser Stories Learning Objectives

Becoming familiar with the “User Story” approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.

Consider the following

User stories trace their origins to eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as refactoring, test-driven development (TDD) and pair programming to name a few. In future modules of this program, you will have the opportunity to become familiar enough with some of these practices in order to understand their importance in delivering quality products and how you can encourage your team to develop them. For now, we will concentrate on the capability of writing good user stories.

The Three ‘C’si

A User Story has three primary components, each of which begin with the letter ‘C':


  • The Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don’t have to have all of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories.
  • The Card is usually follows the format similar to the one below

As a <user role> of the product,

I can <action>

So that <benefit>.

  • In other words, the written text of the story, the invitation to a conversation, must address the “who”, “what” and “why” of the story.
  • Note that there are two schools of thought on who the <benefit> should be for. Interactive design specialists (like Alan Cooper) tell us that everything needs to be geared towards not only the user but a user Persona with a name, photo, bio, etc. Other experts who are more focused on the testability of the business solution (like Gojko Adzic) say that the benefit should directly address an explicit business goal. Imagine if you could do both at once! You can, and this will be discussed further in more advanced modules.


  • The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.
  • As much as possible, this is an in-person conversation.
  • The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.
  • This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).


  • The Product Owner must confirm that the story is complete before it can be considered “done”
  • The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”
  • Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team.  All associated acceptance tests should be in a passing state.

The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:

I – Independent

  • The solution can be implemented by the team independently of other stories.  The team should be expected to break technical dependencies as often as possible – this may take some creative thinking and problem solving as well as the Agile technical practices such as refactoring.

N – Negotiable

  • The scope of work should have some flex and not be pinned down like a traditional requirements specification.  As well, the solution for the story is not prescribed by the story and is open to discussion and collaboration, with the final decision for technical implementation being reserved for the Development Team.

V – Valuable

  • The business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user. All stories should be connected to clear business goals.  This does not mean that a single user story needs to be a marketable feature on its own.

E – Estimable

  • The team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality.  This does not mean that the team needs to understand all the details of implementation in order to estimate the user story.

S – Small

  • The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog.  This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.

T – Testable

  • Everyone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.

Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories.

Splitting Stories:

Sometimes a user story is too big to fit into a Sprint. Some ways of splitting a story include:

  • Split by process step
  • Split by I/O channel
  • Split by user options
  • Split by role/persona
  • Split by data range

WARNING: Do not split stories by system, component, architectural layer or development process as this will conflict with the teams definition of “done” and undermine the ability of the team to deliver potentially shippable software every Sprint.


Like User Stories, Personas are a tool for interactive design. The purpose of personas is to develop a precise description of our user and so that we can develop stories that describe what he wishes to accomplish. In other words, a persona is a much more developed and specific “who” for our stories. The more specific we make our personas, the more effective they are as design tools.iii

Each of our fictional but specific users should have the following information:

  • Name
  • Occupation
  • Relationship to product
  • Interest & personality
  • Photo

Only one persona should be the primary persona and we should always build for the primary persona. User story cards using personas replace the user role with the persona:


can <action>

so that <benefit>.


i The Card, Conversation, Confirmation model was first proposed by Ron Jeffries in 2001.

ii INVEST in Good Stories, and SMART Tasks. Bill Wake.

iii The Inmates are Running the Asylum. Alan Cooper. Sams Publishing. 1999. pp. 123-128.

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

Knowledge Sharing

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