f3yourmind

I suspect that many people did not understand what I meant about forces at play and that patterns describe a solution to bring some harmony among the forces in the problem in a particular context.  For the example of the airplane and wanting to serve the right meal to the right person, the challenge is to serve the meal without knowing about the seating arrangement on the plane, and still sequentially access each seat.  Let’s look at how to get rid of the need to know the seating arrangement.

We start with the solution where we need to know the arrangement of seating and number of seats too.  BTW, it’s ruby code.

for row in (0..29) do # 30 rows
    for pos in (0..5) do # seat A-F
       passenger = airplane.seats[row][pos]
       next if passenger.nil?
       passenger.serve_meal("nut free") if passenger.meal() == "nut free"
    end
end

Of course, if we know the seat number, for example, 15C, then we can do this.  But that does not help at all.

airplane.seats[14][2].serve_meal("nut free") if airplane.seats[14][2].meal() == "nut free"

But, we still expose the data structure of the seats.  So, let’s make it a little better by using the iterator pattern on the data structure for the seats.

airplane.seats.each do |row|
  row.each do | passenger |
    next if passenger.nil?
    passenger.serve_meal("nut free") if passenger.meal() == "nut free"
  end
end

We could be cuter and do something like this and hide the seats array, but we still expose the numbering scheme of the seating.

airplane.serve_meal("15C", "nut free")

So, we can have the iterator on the seats data structure, which helps a bit.  But we can make it a lot better if we put an iterator on the airplane itself. Now, we just care about occupied seats.

airplane.each_occupied_seat do |passenger|
  passenger.serve_meal("nut free") if passenger.meal()
 == "nut free"
end

In the airplane class, we have the following.

class airplane
  ...
  def each_occupied_seat &block
    @seats.each {|row| row.each { |pos| yield pos if not pos.nil?} }
  end
end

We are using iterators on the encapsulated seats structure and exposing a new iterator for the airplane. Also, we are only work with seat that has a passenger

So, we started out with a deep need to know the structure, layout and limits of the seating in the airplane. Then we started hiding the data structure for the seats, put iterators on this seats data structure which helped a bit.  But the real breakthrough happened when we started asking the airplane to just give us a way of sequentially accessing each seat that had a passenger.  No more conflicting forces, just a simple harmonious way to access each occupied seat on the plane.  And when the plane seating changes, we don’t care.

Sourced from http://www.sahistory.org.za

At the Scrum gathering I had a tiny little conversation with Lorraine Steyn of Khanyisa Real Systems and Henrik Kniberg of Crisp about some of the values in our organisations.  At the top of Henrik’s value list was Freedom.  It seemed straight forward enough, until I started thinking about what freedom means to me.

My early perspective and experience on (the lack of) freedom is based purely on oppression of apartheid.  Ok, that’s over, so I am now free. Right?

Then John Lennon’s Imagine lyrics sang through my head.  If we’ve nothing to kill or die for, will we have universal freedom?

Hold on, what about when Janis Joplin sang Me and Bobby McGee – “Freedom’s just another word for nothing left to lose”?  That sounds too dreary for a concept that should make me happy.

Tonight I saw a quote by Maria Montessori on the wall next to my wife’s desk at home.  It’s been there forever and it says:

“The  essence of independence  is to be  able to do something for one’s self.”

I like this the most.  Be able to something for yourself and you will gain independence which sets you free.  It also reminds me of the self-organising mantra in Scrum-land.  Self organising implies that the team wants to be able to manage themselves so that they achieve independence (freedom).  But, there is a little spark of conflict in here.  As individuals we also have priorities and values, which is not necessarily aligned with that of the team.  Is it acceptable to compromise just to subscribe to the homogeneity of the team?

I think it’s a long walk to freedom.

For those of you that attended the Modeling out Loud deep dive at the S.Africa Scrum Gathering today, here are some things that I discussed.  It’s in no particular order, and it only makes sense if you attended the session.

• BDD Stories that are authored outside the team contributes to a hand-off which influences design decisions.
• Because we understand something does not mean that we know how to design it.
• Be aware of when you are analysing and when you are designing.
• Be concrete and abstract late.
• Use the scenarios to close the loop with product owners, stake holders, etc.
• Developers should write BDD stories and scenarios.
• We are less ignorant at the end of the sprint than at the beginning.
• Use code to close the feedback loop for your story.
• A story and it’s scenarios can be a representation of your model, just like a picture, UML, test code, production code.
• Seek out the behavior and express intentions.
• Use the value statement to explore alternative needs.
• Product owners should not write BDD stories
• Recycle stories if there are scenarios that you cannot commit to.
• Keep out the technical jargon.  The moment you get technical, then the story shifts to an implementation.
• Evolve and accept that it is ok to change … your story, your scenario, code, anything.
• Login is not a story

There was a lot more which we all discussed, so feel free to add what you got out of it as a comment for others to grab.

The slide deck which contained the code example is available at http://bit.ly/bhNkvQ.

And lastly, thanks for joining in.  I sincerely appreciate you making the time.

Remember that writing stories is a really difficult thing to learn, because is design is hard.  Persevere.