Par Wiger

Tonight it’s time for another evening with Dave Thomas. This time he will talk about NoSQL (which really should be called something else, emphasizing its non-relationness) and I’m really looking forward to it. He’s a really entertaining guy and usually provides quite refreshing sessions. He certainly has strong opinions on our beloved business and with his experience and track record you’d do well to listen to them.

But, as I said; that’s tonight. Now I thought I’d give you a quick recap on last YOW! Night here in lovely Sydney:

Two weeks ago, on May 19th, I went to the Wesley Conference Centre to see Mr Thomas talk about “Improving the Quality and Productivity of Backlogs Through Envisioning: Collaborative Agile Product Analysis, Architecture and Design” (phew…)

Before I go on, I’d like to quickly comment on that title: Three words: No no no. Yes, he did talk about envisioning and backlogs, but the rest? Too fluffy and frankly a bit boring. Just compare that to tomorrow’s title: “Why Real Developers Embrace Functional Programming and NoSQL Data: Confessions of an Object’holic’ and Statefull Sinner“. Still long, but that one carries some punch! But then again, to quote Shakespeare:

What’s in a name? That which we call a rose
By any other name would smell as sweet.

And Dave Thomas is indeed a rose! If you ever get the chance to go and see him; just go, whatever topic and title. And relax; you will be in for an interesting event and you will learn. Lots.

So, let’s talk rosy smells; what did we learn?

First of all: Use common sense! There are a lot of hypes surrounding Agile and where there is hype, there are priests! Beware of them. Each customer and case is different anyway, so being a slave to a bible will do more harm than good. Rather be great, know your stuff, and adapt to your circumstances and build on them.

The emphasis on Envisioning means: Think, model, scribble, brainstorm, mock, prototype… Do whatever it takes to really understand the requirements, to understand what you’re really going to build. Your backlog – that’s your bible btw – should be clean and safe to use so don’t let any contaminants in there.

I’d like to mention some of the points Dave made about improving understanding:

First: Developers can build anything, they just have to understand it first.

Sprint 0 is the Envisioning sprint. I repeat: Do a proper job here and it will pay off. Sometimes this one can take months. So be it!

If you later do get stuck on something along the way, don’t just let it go on. Stop and push it back. You will only run into trouble later for ignoring it now. Be honest!

Build prototypes. Find a really great UI guy (at least) who can create mockups quickly. Done right this can really pay off; the customer will love it and it will deepen the understanding through out the team. By visualising your system early things will fall into place much quicker.

The problem with the prototyping as well as with a lengthy Sprint 0 though, is that it relies heavily on your faith in its long term effects. You will most often need to really work hard to sell these precious babies to the stakeholders. Do that. It’s worth it.

Use Personas; a great way of creating a common understanding of your users, across the whole team. Another great idea is to use same set of personas across projects so that everyone quickly get who/what we’re talking about. Don’t use too many though. Dave says max. 6-7 which feels right to me, even though I often see higher numbers elsewhere. One important clue to reach the best possible common understanding is to simplify. Within a team you should be able to quickly refer to a common set of rules and definitions with as little ambiguity as possible and without having to look them up. Personas will help you achieve that.

The team

I really liked what he said about colocation of teams: It’s overrated! Oooh, did he just swear in church?! No no …well, yes he did, but wait, here’s the good part: He would much rather have a teammate on the other side of the earth, sharing the same mental space, than share an office with one in another. I find it hard to disagree with that, even though I know a lot of people don’t. You could, of course, argue that the same mental and physical space is a winner. Yes, but that’s not always possible. And if it’s not: Don’t colocate developers just because some priest says it’s in the bible. -But what if you constantly end up in projects with people not sharing your mental space? Sorry mate, but then you really should find another job, pronto! My words, not Dave’s. Not on this particular night anyway. I’m quite sure he agrees though.

Other important take away tips: Create an architecture map and stick it to the wall, use those nice little cards with acceptance criteria on one side and the story on the other and take a look at decision tables (I will, looks great!)

And remember: Done = Acceptance tested! Unit tests are fine, but they have little business value.

To round up this Envisioning/backlog bit I want to use pretty much the exact words from Dave:

All code has bugs. The important question is: Does it matter? The whole point of Lean is triage: In ER, treat the dying patients.

That one sat well with me. Being a trained military medic (in the Swedish army – that’s a little like the Israeli army, only tougher) I’d even like to expand some upon it, making this analogy even more fitting: In the event of war the medical prioritisations change; some of the most critical peacetime wounds are now given only palliative care, i.e. the patient gets a shot of morphine so he can die peacefully…

—

On a final note I just have to make a little digression and pass on Dave’s sincere apology for OO. He said it made sense with Smalltalk, but now… I must say he looked very sincere, and given his prediction about the future legacy problems we’ll face it’s understandable. In his opinion, Java, and especially J2EE etc, will make the COBOL legacy look like a drop in the bucket. I suspect we will hear more about it tonight…

Isn’t it great when you stumble upon something, whatever, that makes you think, really think?! And then sometimes, that wonderful stumble triggers you to rethink things you thought you already knew, things you took for granted. Ah, that’s indeed a wonderful process.

It just happened to me. This time it was two very interesting articles that got me thinking about the Agile idea of iterative delivery.

Photo Credit: extranoise

Delivery

The way of delivering anything these days is arguably to do it in steps, adjusting as you go, depending on the feedback and the changing requirements. Yes, yes, yes, I know; far from everyone agrees with that statement. Hence “arguably”. (I’m not going further this time. Go google – or bing if you will – delivery waterfall agile if you want to dig deeper into that subject. And bring a sturdy spade.)

Having lived with a term like “iterative delivery” for about a decade now, believing to have a rather firm grip around its meaning, I find it interesting – and refreshing – to find it challenged twice in a couple of days, after reading two excellent articles sort of on the subject.

Iterative delivery

A common way of looking at iterative/evolutionary product delivery is: Release and fail fast, acknowledge missing features, embrace change and continuously add and improve all the way to the “final” (great) product.

Banana skins

My two challenges, or pitfalls, for today concerns:

• The acknowledgement of missing features
• The failing fast

The acknowledgement of missing features

There is a very interesting article by John Gruber, about “how Apple rolls“, showing how Apple consistently release their products small, and then improving on them, slowly, bit by bit. Of course that’s what they’re doing. I just haven’t seen it like that before. Apple is doing iterative delivery. They just don’t advertise it as they go. They never focus on the missing parts. Every product is a flagship that will, and most often does, revolutionize the industry.

Before I go on and you accuse me of comparing Apple and orange: When we talk about Agile software development principles, the acknowledgement of missing features is commonly communicated within the team, including stakeholders/customers. What Apple is doing is marketing externally to the end users of the product. That’s a different ball game, but nevertheless I think there’s an important lesson to be learned here:

One of the great benefits of the Agile way of thinking is that it fosters a humility towards failure and change. However, too much of a good thing may do you harm. When you insist on putting up a sign on the front page telling the users this is not a complete product, when you refuse to remove that Beta tag, you start making excuses, effectively demoting your product. You don’t have to speak Apple, but be careful. Don’t be too humble.

Fail fast

The same goes for the mantra “fail fast”. It’s a great guiding principle, but be careful communicating it to people without the same level of understanding and knowledge about Agile and XP. They might just perceive it as a careless approach to their product, their time and money.

–But pretty please with sugar on top; it’s such a catchy phrase, with its short allegorical allure! Yes, but it does front a dangerous word when it comes to the customer’s children: Fail!

It’s not just linguistics though. Fail fast is a concept that demands and deserves proper presentation. It lives dangerously close to the world of lazy or lacking preparations. (Which, by the way, is not a good starting point if you have any ambitions.)

There have been times that I’ve felt this need for careful wording trying to convert waterfalling customers, but after reading this rather energetic confrontation with the mantra from a VC’s standpoint, it really made its way to the frontal lobes. Again, all I’m saying is: Be careful.

Do your homework

Be careful you say? How? The way to avoid these pitfalls is – in my humble opinion – to be sure to communicate, to eat, live and breathe responsibility and thorough groundwork. From there you can go pretty much wherever you like…

About a month ago (wow – time flies when you’re having fun) we had the great honor of having Linda Rising guest starring at our, and I’m quoting myself, biannual “internal technical workshop weekend”. (Hey, that weekend has actually gotten a name since my last post, thanks to Geir Wavik: Miles Camp!)

And in the mean time…

…and while I’ve been at it, writing this blog post, averaging about one word a day, we’ve also finished a Miles Session – another one of Miles’ professional development initiatives. This month’s special guests here in Bergen were none less than Mary & Tom Poppendieck! Phew, busy days among the A-players… I’ll get back on my personal impressions from that one later. But now, back to this post’s leading star:

Linda who?

I didn’t know who Linda Rising was before I attended JAOO in Ã…rhus last year. Now I know! …now I know she’s an amazing lady who somehow manages to inspire the [beep] out of room full of people with her fascinatingly intuitive findings on the inner workings of our brains, delivered through her great storytelling.

Linda how?

Here’s the amazing part (besides her actually being a remarkable person. In person.) :

It’s not just that she inspires us, her audience, with her great storytelling techniques letting shine through both her passion for what she does as well as her openness and willingness to share. She actually manages to convince a bunch of engineers that the quality of an idea does almost nothing to help influence others. She tells us that the rational argument – our only source of light in life – is void of significance.

I mean, that’s like telling that saber-toothed squirrel in Ice Age to forget that acorn!

(Actually it’s not. That acorn is more equivalent to one rational argument that we should let go of. That’s probably why Martin Fowler says he doesn’t like analogies.)

Martin Fowler is a caveman

Forget Mr. Fowler – let’s stick to that analogy for a while. Chronologically it has put us in the right setting. We’re all in the cave you know! We act and react based on what has kept us alive through evolution. There are things here that we simply cannot escape – they are hardwired into our brains. That’s just how we humans work. That can of course make one feel almost powerless, but once you start to understand these simple but oh so powerful triggers that rule our behaviour and interpretations things really start to lighten up and make sense.

a == b. Ergo, you have to do it my way

As I said (that she said), we salute logic arguments in our business. We core dump the results of our inner brainstorm and leave the room disappointed that the clueless washouts don’t get it right away, not understanding we have actually triggered their instincts of self-preservation. Evolutionary speaking, that reaction is a sound one: If Garog comes knocking on your cave one day eagerly explaining in his most persuasive manner his newfound idea of defending against angry mammoths by tickling them to death that self-preservation instinct can prove quite useful.

-No Powerpoint? What then?!

First we smile overbaringly. We know she’s wrong. You can’t argue with logic. The best idea always wi… oh, shoot. Strike one.

But still, how does she manage to convince us through theories of cognitive psychology? After all, that river between our camps is a pretty wide one to cross.

Well, not necessarily, not if you’re Linda Rising. By expressing and explaining our behaviour, our actions and reactions, as Patterns – a “style” that is both familiar and authoritative in our simple engineering world of mathematical reasons – she wins us over.

– Really, you can apply patterns to this psychological mumbo jumbo? And she gets to present at QCon and OOPSLA?! Hmm, ok – maybe she has a point here…

And once she starts telling (and sometimes acting) her stories with her calm and reassuring voice you’re lost.

Show me the patterns!

So, how does these patterns look then? Well, some of them are roles, like the Evangelist – the person (you!) introducing his/her passionate idea into an organization, but most of them are advice, or the “rules” if you wish, to play by in order to get your idea through all the way to the Late Majority.

Here are a few samples:

First, my favourite: Do food: Food makes people lower their shoulders and relax. It was an unwritten law among the vikings not to attack anyone during meals. It was considered cowardly to fight someone with their defences down. Not only the vikings I’m sure; food has always been considered a friendly gesture in all cultures.

Bringing food to a meeting changes the nature of the event.

Ask for help: This can be a tough one for some, but those people (/you?) will be surprised how open and helpful people can be in a change friendly organization. That last part is important. (If you’re in an organization not open to change, good luck.).

Just Say Thanks: The follow-up on the previous one. This one is so powerful, although so seemingly easy to implement. Anyone can do it. It’s just one word, and a nice one too. Sometimes that’s not enough though. As with most things in life, even the simple ones, mastering it is an artform. Just saying thanks folks to a group of individuals may disserve the intended purpose. But don’t let that stop you. Just go ahead and start thanking people – it’s a reward in itself just saying it. You feel good about yourself. Oh, wait. May I change my mind please? I think this one is my favourite pattern.

External Validation: As Linda said, most people may have had experience of a spouse not listening to advice or ideas only to find out he/she gets all enthusiastic reading it in the paper the following morning. We tend to be more attentive to outsiders, especially outsiders also being (looked upon as) authorities. That’s good news for us consultants. Instead of complaining – as we often do – on our powerlessness, being outside the organization, we should focus on our excellent position for providing external validation. After all, we where hired as experts in whatever area(s), brought in to help the customer solve problems.

And so on. There are about 40 more of these little babies in her book…

Interesting theories, but couldn’t we just read the book?

Since these are are cognitive, behavioural patterns that exist within each and all of us – couldn’t just anyone get up there and convince just any paleolithic squirrel? Did we really have to fly in a woman all the way from Arizona? The answers are No, definitely not! and Yes we did. The real killer here is Linda’s background and experience combined with her speaking skills and smart brains. That makes her very credible, both technically, organizationally and psychologically. (Should you ever be looking at bringing in someone from the outside to explain such patterns as External Validation, she is the one!). Without that credibility we would run back to our Powerpoints before you could say “halv sju”.

And what about me? Why do I write such a loong post about this?

Both at JAOO and Miles Camp I could feel my inner strings resonating. This is really something that hit a note with me. On both occasions I thought maybe it was just me, but I can see, not only on Linda’s crazy conference schedule, but also on the reactions from my colleagues and my tutorial friends at JAOO. This is really interesting and highly relevant material.

I will return to some of these patterns here later. I just have to start trying them out first; both on “my” organizations and on myself. Yes, that’s right – some of these patterns work well applied to influencing yourself too, introducing new ideas into your own life. Well, doesn’t  that sound nice?!…

On a final note: I urge you to to read her book and – even more urgently – to attend one of her tutorials and/or sessions if you get the chance. You too will be inspired…