• SD Times’ Leaders of Agile Webinar: This is the fourth or fifth in this series hosted by Kent Beck.  It’s always very engaging for me, and Kent normally asks far too many difficult questions without warning me in advance.  It’s also the third time that I will be working with Henrik Kniberg.  This time we will be talking about Kanban, and should be another really fun 3 hours.  What I enjoy the most is the balance between practical experience, challenging the norm, and always the realisation that I know far too little.  It’s free and you can register at SD Times.
• Oredev 2011:  I’ve been invited back to Oredev in Malmo, Sweden.  This is always a fun conference and I get some face time with my factor10 colleagues in Sweden again.  On this occassion, I will be giving two talks.  In the first I will explore the messes we make over and over again, yet we are missing some old teachings and learnings consistently.  The second is on the Java track and I will share my experiences on experimenting with Scala and Clojure, more from design and mental mindshifts, instead of the usual language and syntax changes.  Check it out at Oredev 2011.
• rubyfuza 2012: This is the second edition of the only South African Ruby conference that I know of.  The 2011 edition was well put together with great local and overseas speakers.  Although the program is not finalised, I will be talking about using JavaScript and CoffeeScript to build parsers and grammars.  This is something that I’ve spent a lot of time on recently and it’s changed a lot of my thinking on domain driven design implementation options.  Check out the details at rubyfuza.
• AgileIndia2012:  This is my first trip to India, and one that I am absolutely excited about.  I will be running two sessions.  One on product ownership which is a slight improvement on the sessions held for SD Times and the S.African Scrum Safari.  The other is a culmination of years of introspection on cultural differences that I face.  I explored this quite emotionally at Oredev last year and will run a more in-depth session for AgileIndia.  Check out the abstracts for my sessions Practical Product Ownership: balancing strategy and development and Collaboration lessons from the Rainbow Nation the early bird program.

I often hear developers, and managers too, saying “It’s so much easier without, so why bother?”.  Well, design is hard.  Applying principles for life is harder.  But if you are professional developer and have a conscience about your design, your code, and your product then “an easy life without principles” is not an option.

If you are planning to come along, bring your laptop with your development environment.  I will likely have code samples in Java, C#, Ruby, Javascript, and even, yup, Basic (well, maybe).  All the samples should be very readable and you could easily translate them to something equivalent in your language pretty easily.  Better still, bring some of your own code along, that you want to share.

In reality, this is stuff that Scrum does not teach you, but need to know to avoid Scrum burnout.  Looking back, I should have done something like this sooner.

Then in November, I’ve been kindly invited to speak at Oredev in Malmo, Sweden.  I will be talking on the Java track and Architecture track.  Being in Sweden, I get a chance to get some face time with my Scandinavian colleagues, and lots of offshore geek friends.  If you are a South African looking for a decent developer conference, then consider Oredev.  It has a good vibe and some very good content, and is generally good value for money.

Personally, I want to cover what flow and waste mean to me, and examples of the huge piles of waste that I ended up manufacturing or walking into blindly and then struggling to dig myself out at great expense.  If the time allows, I want to weave in some models of flow that work for me and those that contributed to waste.  All of this fits into my rather weak thoughts on designing feedback loops.

For a long time I have been wary of the way product ownership is “taught” in CSPO courses, and the way it is implemented in Scrum teams. I think the fundamental tension of product ownership is not being addressed.  So, at the heart of my talk, I want to explore the tension that a product owner needs to resolve and, maybe, some ways of resolving that tension.

Regardless of whether we offer workable solutions, I think the webinar will raise questions that are well worth discussing in larger groups.

Sign up, it’s free.

You can check out the full program details here, but here is a personal perspective on the talks.

Architecture in an Agile World: On the agility track, this talk will have a distinctly technical flavor.  At the JCSE in July I gave a similar talk, but this will be more technical than that, I think.  There are many things that I observe in teams, but one screams at me most often.  Some  process/methodology is hauled in, some discipline is put in place.  People are set free, slavery is abolished.  Everyone is agile.  But the code is still imprisoned.  Then, you flatline and then you start the decline.  Agility is a lot about design too, and how you constantly need to find ways to move from ignorance to knowledge, and again, and again, and again, …

Truth and Reconciliation: Agile Lessons from the Rainbow Nation: In the S.African community I talk almost exclusively about agility at the code face, but there is another side with which I assist teams without casting labels – that is dealing with the social aspects of software development.  This talk is very personal, semi-biographical maybe, but something that I don’t see teams in S.Africa recognising, yet it is part of our history.  Ooops, that’s presuming a lot — it’s part of MY history, not yours.  This talk is on the collaboration track, largely about trust, but there are one or two twists and turns too.

And it’s time that Øredev heard some vuvuzela music!

• 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.

BTW, digging around on material diversity in agile teams I came across this video.  I didn’t know it existed at all.  Suddenly, the references to the FIFA 2010 World Cup seem sooooo dated.