f3yourmind

Over the next few months or so, I will be quite active in the conference space.  Here’s what’s coming up soon …

• 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 came across this tweet by Karen Greeves.

Scrum Master fail… Improvement action: Bigger stories where only few members can participate should be scheduled to run over 2 sprints.

After a quick twitter conversation, Karen explained.

It removes the ability to measure progress via working software at the end of the sprint

My response was

Working software is not the only way to measure progress in a sprint. And what if it works? I think it can.

It may well not be the ScrumMaster that failed when it was decided to have a bulkier story span two sprints.  I appreciate that it is a whole lot better when a story is in one sprint, and that should be our default objective.  However, it’s often not so trivial.  Given that I don’t have a lot of context, I will be assuming a lot.

In this case, it is more likely a failure of the team that they (a) accept a story to develop over 2 sprints, or (b) was unable to do enough analysis to consider what can be done in one sprint.  It can also be a failure on the product owner for not entering into a meaningful conversation on the details of the story, and then, again, a team failure on not engaging the PO significantly to take the problem forward.

If I encounter a story that spans two sprints, and that is more often than you think (often discovered mid-sprint), then I’m not interested in working software but seek clarity of understanding in that sprint.  The outcome at the end of the immediate sprint is an unambiguous story (or maybe several stories) which is a statement of the problem domain, or even better, the solution domain.  That is what I mean by working software is not the only measure of progress in a story.  It is more important to “measure” increased understanding in each sprint, and good statements in the solution domain is at the heart of knowledge crunching.

The most neglected aspect of working software is a measure of understanding of the solution domain.  In my experience, many teams are great at expressing the problem domain in software and their code reflects the analysis of the problem.  Consequently, the code does not reflect the understanding of the solution.  The end result is a weak design.  Over many sprints that require work in the vicinity of the weak design, there will be a degradation in velocity because the code is just baking in the problem statement, and not a well crafted solution to the problem.

Next, let me deal with the case of just a few team members participate and not the entire team.  I think that is completely feasible approach.  I’ve done it many times to great effect and with great efficiency because the conversation is a lot more direct and contained.  It is later that the distilled knowledge is shared with the team.  This is largely crunching in the problem domain with some rough models in the solution domain.  When I’ve included the entire team in the analysis, then the effect is one of dilution and inefficiency – too many people over a longer period.

Lastly, I asked “What if it works?”.  While this may seem to be brash or provocative  question, it is meant literally.  What if it really does work? Hey, then what we’ve achieved as an odd case of delivery over two sprints instead of one.  If it happens often enough, then we need to adapt accordingly: increase sprint duration, have people dedicated to analysis (oops, bite me ‘cos I’m creating a silo) and maybe more if we just think a bit about it.

So, in my opinion, it is absolutely OK to attempt the proposed solution because it is an admittance of ignorance, but if the team does not understand the actual situation they’re in, then it is the failure of the team not the ScrumMaster.  I also think that we should understand the rules of the game a lot more deeply.  Like I’ve said in the past:

It’s not the rules that matter, it’s what we do with the rules that counts.

To each their own, and life goes on.

I will be hosting a 3 hour session at the South African Scrum Gathering titled “Live your principles or stay in bed”.  You can read the abstract here.  In my opinion, there is far too little focus on software development itself in Scrum.  So, this is unashamedly a developer session.  I will be present various snippets of code, and we will “live our principles” to transform the code into something that is less messy.

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.

I’ve got a busy few weeks of preparation to get through for a few talks that I will be giving.  In September I will be speaking at the South African Scrum Gathering.  The one talk for Johannesburg is on product ownership and it is a combination of the content that I presented earlier for the SD Times webinars.  The other I hope to keep quite code centric and is aimed squarely at developers and architects.

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.

I will be joining Kent Beck and Henrik Kniberg on July 20, 2011 for an SD Times webinar on Lean Software Development.  As usual, Kent has put up a great abstract for the event.  I’m absolutely certain that Kent will set the scene with his usual deep insights, and Henrik  has some amazing “from the trenches” experiential material to share.  Overall, we will explore this concept of waste vs value and how lean influences application development.

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.