Envisioning envisioning
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…