f3yourmind

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.

I will be running a 6 hour long session at the Scrum Gathering in Cape Town in September titled Modeling Out Loud.  I’m now convinced that the Scrum tribe are weird.  They call these sessions Deep Dives.  Presumably, you need to carry enough oxygen to survive the session.

I think I’m going out on limb here because I will be challenging the value of Product Owners writing stories.  I’m also suggesting that when Product Owners write stories riddled with behavior then developers are disconnected from domain experts and you regress into a waterfall mode of execution fronted by a Scrum Board.  So be prepared to experiment with me and turn up your self-reflection to maximum level because we will challenge many assumptions.

I just had a quick Google Wave experience with Willem Odendaal and the experience of seeing the other person type was a bit weird for both of us.

Lesson to both of us: Think before you wave!

Also, I have to remind myself to not think about waves as email, or tweets or instant messages. It’s just something else! And it has a different spin on the time dimension of communication.

I suspect that Google Wave will force us to be better at the way we communicate, how we express ourselves and the relevance of the content to the conversation.  I can imagine a wave growing over time that describes a story started by a domain expert with feedback from a developer and a nice cadence emerging between them.  It all is in one nice wave, with playback that tells you how you got there in the first place.  I wonder if this will have an influence on effectiveness of remote pairing?

I also have a feeling that if you’re a waterfall type of person, then waves will not have an impact on you.  It’s all about feedback and dealing with the changes, which is at the heart of agility.

Now I just need someone to wave with to try out a slightly modified development flow.

I finally got out of neutral and pulled together the first public offering our Domain Driven Design courses in Cape Town, South Africa.  Normally we give these courses on-site with people on the same development team but I thought it may be fun and inspiring to open it up to everyone for a change.  Now I’m all excited again and really looking forward to a diverse mixture of people. Hopefully, I will see some old faces and lots of new people.

The one thing I can tell you is that the course is a very immersive experience.  I really hate lecturing but I enjoy probing conversations and that’s how I give the course. I don’t have answers to the practical work and concerns are addressed as we go along.  As a result, the day takes unexpected turns and routes.  But in the end I get you to the right destination.  Come along; you will leave exhausted, but inspired!

Take the Fast Track to Domain Driven Design

about the course /  course contents / should you attend? / register for the course

factor10 has expanded its services in South Africa to include our advanced and
expert level courses aimed for the software professional.  On September 8-9, 2009,
we will be offering a fast track to DDD for Architects at the BMW Pavilion in
Cape Town.

Who should attend?

This course is for software professionals that want to take the right steps towards
advanced and expert levels in their careers.  Register for this course if you want to …

• learn more than just another syntax and set of tools
• write software for large, long living systems
• increase the quality and maintainability of your design
• design high quality models and use code to represent those models effectively
• develop applications with a good APIs
• add a design edge to your skill set

Why should you learn DDD?

More and more developers and architects realise that learning every detail of a new
API just isn’t the way to deliver the best business value. It’s such a tough balancing
act; focus on the solving the business problem and focus on building working software
with your frameworks.

One way of taking a big leap in the right direction is to learn and apply domain driven
design. It is definitely not abstract and fluffy; it deals a lot with the code also. DDD
leads us to focus on understanding and to communicate that understanding very well;
in language, in design and in code. You will shift your focus away from designing for a
technology, and you will learn to design for the business domain; to the core of the
problems and solutions. Those are the most interesting parts and what your users
and customers really care about.

about the course /  course contents / should you attend? / register for the course

I am revisiting the material for the factor10 Domain Driven Design course as part of a “freshen up” for the when I give it to a development team on July 1, 2009.  So I started hunting for some quotes to liven it up a bit.

Here are some choice bites for ubiquitous language.

“They have been at a great feast of languages and stolen the scraps” – William Shakespear

and

“Thought is the blossom; language the bud; action the fruit behind it” — Ralph Waldo Emerson

And on the need for simplicity, I really liked this one.

“There is never any justification for things being complex when they could be simple” – Edward de Bono

Robert Bravery commented on an old blog post of mine and I re-discovered this one

“Don’t indulge in any unnecessary, sophisticated moves.  You’ll get clobbered if you do” – Bruce Lee

Lastly, and the one I’m definitely going to use to stress the importance of working directly with the domain expert.

“Never hold discussions with the monkey when the organ grinder is in the room” – Winston Churchill

What a diverse group of people but such collective value.  Do you have any classic quotes?  Obscure quotes?