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…