The final words about software estimation - Pecha Kucha talk

Here are the slides of my Pecha Kucha lightining talk I gave at #ALE14 in Krakow. Kind of a quick reminder (or kick in the butt, in case one forgot...).

The intrinsic non repeatability of the change agent

After 3 really intense days of ALE2014 in Krakow, this morning my brain was busy connecting the many sparse dots and the many insights popping out from talks, open sessions and private conversations, including late night ones.

There’s a fundamental clash between the way change agents and organisational consultants act and the way the market is looking for their services. Let me explain it.

What the market is looking for

When selecting/interviewing a change agent the buyer company, most of the time ends up falling into two fundamentally flawed questions:

• Which results can you guarantee?
• Have you done this before?

Let me explain why they’re both fundamentally flawed and why you should try to challenge them from the start. Beware, I said flawed, but I didn’t mean they’re not legitimate questions: the buyer/customer company might be new to change initiatives and looking for some certainty. Statistics shows that 70% of change initiatives fail, and that those numbers are substantially flat from the eighties (thanks to Steven Parry for showing this data). So risk is inevitably there. But the way to manage risk is probably to hire a good consultant, with previous experience on the matter, in order to mitigate that risk, or to implement some just in case ‘cover my ass’ strategy.

 

This leads to a couple of weird problems: success in previous initiatives is no guarantee of success in the new one. More than anywhere else, context is king. And context is mostly out of the change agent scope, at least in the early days. A common trait of experienced change agents is the ability to detect critical, non removable impediments quickly (in the initial interview or in the early assessment) so that they end up having a better record, by avoiding customers with low success probability. Which sounds a lot like the old Sun Tzu’s advice: “battles are won before they’re ever fought”.

 

A more legitimate meaning of the ‘Have you done this before?’ question is to check previous references. This is probably the best thing to do, especially if it involves talking with somebody to know something more about the person, the style and the possible surprises that may arise.

What happens in reality

But the other implicit issue is that this often hides the tendency of thinking in terms of the wrong complexity context.  Of course we don’t expect our customers to be familiar with the Cynefin Framework, but guarantee and repeatability are thinking tools for complicated systems. While in a complex system there is no guarantee that repeating an action will lead to the same result.

 

If you hire Mourinho as a football coach, you’re sure you’re going to pay a lot of money, but there is no guarantee that he will deliver the expected result. This is what makes soccer still interesting, by the way.

 

But one other aspect gets too easily forgotten. In a change management initiative, or more specifically in an agile transformation, the system is not the only thing that changes. The change agent, changes as well. It’s not only experience, it’s scars. It’s emotions, and last but not least it’s learning.

The agent changes too

One thing that the customers rarely understand is that sometimes we do something really special, something that we’ve never done before. And this turns out special just because we’re doing it for the first time. It’s something probably similar to improvising in a jazz way. In Jazz music, it takes a lot of mastery to be able to improvise, but that performance is intrinsically non repeatable. And trying to repeat it will probably make it worse. The second time a band tries to jam on a given tune, the magic won’t be there.

 

The other thing that we often forget to consider is the emotional overload of such things. After a success, or a failure, or simply when the time has come, would you just ‘be ready to start over?’ I suspect the plain answer can be “no". Just like some people need some thinking time between a love story and another one, ending an initiative and starting a new one with a new customer right away might be a really bad idea. Without the initial curiosity, and freshness the new mission will risk to be ‘just a new job’, without the magic.

 

 

 

 

 

 

 

EventStorming Recipes

Just uploaded the slides of my talk at DDDeXchange London. Thanks to everybody for the great conversations.

Event storming recipes from Alberto Brandolini

Not Dead Yet

Like it or not, David Heinemeier Hanson did it. By starting the debate around the “Is TDD Dead” topic, he forced the whole agile community to re-think about many issues that were taken for granted. You may like his opinion or not, you may prefer to choose his side or Kent Beck side, or the more radical one from Robert C. Martin. Or you may also appreciate the way Martin Fowler proposed to sort out the issue, in a way that is a great example of “this is how we discuss things in the agile community”.

I personally liked the fact that many collateral discussion spread out on the topic, the best ones I had with Francesco Fullone and Matteo Vaccari. Here are some of the thoughts they helped shaping.

Who’s paying for what

I remember the old argument that 90% time on code is spent on maintenance, so it does make a lot of sense to write software that’s easier to read an maintain. This is what I normally do, or, better, this is what I relentlessly keep trying to do.

But the more I look around the more I realise that this statement leads to a quite naive approach. This is not how most developers are working right now.

Let me explain that.

It’s not about the code

Given 90% of time spent on code is in fact maintenance, it makes a lot of sense to try to improve this 90% instead of the 10% spent writing new stuff. Unless…

…unless we stop focusing about code and start looking at human beings surrounding it. Some call them developers, but I am really more concerned about the human being, not the role.

Humans move, evolve, grow, move to another team and another company. Humans will be far away the moment evolution will be needed on a given piece of code. They won’t be there to take the praise for well-written maintainable code as well as they won’t be there for talking the blame for horrible legacy code.

Even worse: once they’ve left, they might be blamed also for supposedly well-written code, if the new developer who’s now taking care of their beloved source code has a different programming style. Or simply doesn’t like their indentation style, or what was intended to be good coding practice at the time the code was written.

If I don’t plan to stay around a piece of software for a long time, writing maintainable code is dangerously close to an exercise of style. Many practices are said to repay themselves in the long term but no one stays around long enough to catch the benefit

Being short-term sustainable

Yep. In the long term.

That’s the thing I really don’t like. It sounded like reasonable first time I heard it, but now it has the sinister sound of I have no evidence to support it, just faith.

And in a world where software development workforce is made not only by internal developers, but also consultants, freelancers, contractors, offshore developers and part-time hackers (just to name a few) the implicit assumption that

if you don’t code right, technical debt will bite your back 

is flawed.

Well, technical debt is a bad thing. It’s probably worse than we think. Companies deliver horrible services due to technical debt, they struggle, collapse and ultimately sink for technical debt.

But well… who cares! Big companies will survive anyway. For small companies… it’s just darwinian selection. As a developer I’ll move somewhere else soon (disclaimer: I have a bias for not hiring developers who previously worked in companies that sunk).

So, I guess the real story with technical debt should be rephrased like

if you don’t code right, technical debt will bite somebody’s back

meaning …Not necessarily yours. Call me cynical, but by the time your crappy code will unleash its sinister powers you’ll probably be in another company complaining about a different yet stinky legacy codebase. Time for a soundtrack: try this.

A little tragedy of the commons

If code stays around longer than the expected lifespan of developers there’s not much that we can do to prevent technical debt to flourish. It’s just another version of the well known tragedy of the commons, that economists know very well: people acting in their own interest will ultimately harm a greater good.

A system view

Thinking of a codebase as a part of a larger system, if independent agents aren’t there to stay, they won’t improve the system. I remember my days when I was a university student. I hated it. I probably hated every single exam. The way it was led, taught, and the way students were evaluated. But the thing I hated most was that the whole system was hopeless: nobody liked it, but nobody really put any effort in changing the system. Students were not there to stay, the winning strategy was to keep your mouth shut and pass the exam. It will be somebody else’s business, not ours.

Does it sound familiar?

If the time needed to be rewarded for an effort is longer than the expected time in the system, well …who cares?

Enter the Boy Scout Rule

Interestingly, Uncle Bob proposed a solution for that: the so-called Boy Scout Rule, which goes as follows:

always leave the campground cleaner than you’ve found it

I love it, for many reasons. It creates a sense of ethics and belonging. It provides a little quick reward: “I am doing something good here”. But the most interesting thing is that it turns a rational argument into an ethical and moral one. Boy Scouts do not rationally believe that every forest will be cleaned up if everybody starts behaving the way they do. But the feeling of doing something good and right, is a good one. And moral - together with the fear that Uncle Bob in person will one day see my code and throw me in the flames of hell as a consequence - will probably do a better job.

A higher duty

Who should care for the system? Who should ‘enforce’ (I hate this term) the boy scout rule? It’s pretty clear that this is the job of somebody who’s going to stay around for a longer time. Somebody that cares about the ecosystem, and sees the whole. Or at least tries to do that. Be it a CTO a Technical Lead or the CEO, depending on your company.

For example, working for a sustainable work environment with as little turnover as possible might be a really good strategy in the long term. If developers feel the workplace as their own workplace, continuos improvement policies might flourish and people might stay around long enough to see them working, creating a virtuous cycle.

No hope in the short term?

Here we are. Now you’re probably thinking that - since the battle for maintainable code is very hard to win I - am depressed enough to give up and let the barbarian hordes commit whatever they want.

Not yet, guys.

The thing is, good practices like TDD and continuous refactoring should repay themselves in the short term too. And they do, …if you know them well enough. Which means that you’re correctly accounting costs and benefits, including the cost of learning TDD and keeping it distinct from the cost of doing TDD.

Personally, I would be lost without TDD. But I am a different beast: despite all of my efforts, coding is not my primary activity: booking hotels and flights is. So TDD is a way to keep a codebase manageable even in scenarios with no continuous work on a project. I guess this goes for many open source projects too.

But the most interesting thing is that the best developers I know are all doing TDD. Not for religion, but because they get benefits in return. Not potential benefits, just-in-case style. Real benefits, in the short term.

Safety, confidence and speed.

Very good developers can also recognise different needs in different contexts. There may be cases when TDD is overkill or bringing little value: if all you need right now is showing a prototype, show a damn rails prototype right now! It’s no religion, it’s a continuous evaluation of return on investment and evaluating options. Which means that you can also be wrong: you may be too conservative and pay an insurance for a disaster that would not happen, or be taking some risks, just to end up smashing your face against a wall with your colleagues staring at you with a I-told-you-so look on their faces. That’s life, dude.

But in the land of continuous choices, being able to code only in one way, means being weak. The only safe spot, is being so good in TDD to know when not to use TDD. Aren’t you there yet? Good luck. There’s still people that go to a Japanese restaurant and ask for fork and spoon. But, you don’t want to be the one.

So please, stop raising arguments like “Yes, but if one day somebody wants to change the codebase”  because I won’t buy it. If you can’t provide short term benefits for TDD and refactoring, then you probably don’t know them well enough, yet. And at the same time I don’t want to be the one trading a sure expense, for a potential gain in the distant future.

Some updates about EventStorming

Hi everybody. After a long silence I finally found some time to start writing again some content for this blog. Well, many things happened in the meanwhile in the EventStorming space, and I finally managed to find some time and discipline to start sharing our findings more effectively.

In the meanwhile, EventStorming found its way through word-of-mouth, twitter and conference workshops. But it’s looking like a web version of Fight Club: getting viral and secret at the same time. Maybe it’s time to make some change.

EventStorming Community/Mailing List

I’ve started a new public community on Google+: it’s called EventStormers. Here’s the link. I’ve chosen Google+ mostly for the look: our content is a lot more visual than other discussion groups, and I felt that Google+ was a good tool for that. I know there are some drawbacks too, but it’s working well, so far.

Some colleagues were already sharing content on the smaller private community called EventStorming Practitioners. Communities rules prevent me from turning the old one into a public one. So, members of the private community, which are ok with the idea of going public, will have to share their stuff again. That includes me too.

Writing some stuff

It’s no secret that I am planning to write something more than a blog post. EventStorming and Model Storming are tricky topics (and yes, I am aware that I haven’t published much about Model Storming and that many people are still confused about the two terms).

Telling the what might be relatively straightforward, but telling the why  and exploring the how can take ages. However, I finally acknowledged to focus on EventStorming for now, and I am working on readable content. Portions of it are actually making their own way to the blog.

But that’s the offer. I am writing about things I care and think that are worth sharing. But - as every blogger knows - I also write pushed by the urgency of a freshly learnt lesson. The drawback is that this is too much self-centred.

So I am asking your help.

If you are curious about EventStorming, please join the community and start asking questions, or maybe ask what you would like to know about EventStorming right here in the blog comments. I’ll do my best to share the answers I know, and find the ones I don’t.

Thanks everybody

 

 

Go personal to boost engagement.

Weird episode during today's EventStorming session. We had a meeting room with a big wall available, that we set up with a plotter paper roll. The room had a big table, that could not be moved away so we simply moved it aside, to provide more space in front of the Modelling Surface.

Unfortunately, it wasn't enough. Some participants showed up a little late, so we waited for them. When they came in, they saw other participants sitting (cause we've been waiting) and immediately grabbed their seats. Hrmpf! :-/

Well, I thought: "This isn't going to last much" and said politely: "You won't need your seat. We'll be standing most of the time, working by the paper roll". What I didn't consider was that many of the participants were ladies, and the answer was: "We don't have the right shoes for that!".

Ouch. Surprise. I've never thought about it. :-(

Add that to the fact that I couldn't adopt my usual I'll-kick-you-in-the-butt strategy that works perfectly with developers, (I am a gentleman, after all), and for the first time having people stand up became harder than usual, resulting in lower-than-average engagement and less observable body language, for a while.

Time for a Plan B

The surprise trick that really worked well was "could you please add Actors close to the corresponding event?" and since "actor" meant "me" for many of the participants, they all stood up and added information to the model, raising engagement at the same time. Wow!

Ok, lessons:

1. As Jef Claes reminded me, remove seats. I focused on the table and forgot the smaller enemies. Seats were still there, inviting and comfortable
2. Environment matters a lot. And preparing the meeting is really important. I did a survey on the room before the meeting (something which is hard if I travel to lead a workshop), but I focused on surfaces, and space. Maybe is time to set up a room preparation checklist (next post, maybe). As Sun Tzu said: "Every battle is won before it's ever fought"
3. personal involvement (actor == me) works pretty well as an engagement booster. I normally go to actors together with Command exploration, but in this case (small timeframe available) it was better to go straight to the actors.
4. shoes... maybe mention 'bring comfortable shoes' in the invitation.

EventStorming: invite the right people

Invite the right people

People are the primary ingredient for a successful party. You’ll need good music and drinks too, but if the girls won’t show up, the party will be lame

You’ve been reached by some buzz around EventStorming, you may even have experienced it in some evening event t the local user group. Now you fell like trying the experiment in your own company. But then a question pops up.

Who should be invited?

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

When exploring complex business domains (the scope of EventStorming is usually the whole business flow) this implies that a lot of people should be involved, and triggers a lot of warnings. Let's see some.

• They won't be available at the same time.
• The meeting will turn into a waste of time, at least for many of them.
• You'll end up nowhere due to conflicts that may arise.

All these worries are legitimate. But they lead us to do things in a way that doesn't work. The meaningful conversation with the Domain Expert that is at the core of Domain-Driven Design is often not that meaningful.

Should I look for specific roles?

I am somewhat reluctant to map those people to company roles for a couple of reasons: personal attitudes are more important than roles for the workshop to deliver, moreover I’ve seen so many different, somewhat dysfunctional company structures that tying myself to randomly assigned roles is not a wise choice.

So I won’t provide any answer like ‘every developer should attend the workshop’ or ‘only team leaders, business analysts and domain expert should be there’. Instead I’ll suggest to take a different path.

A somewhat zen answer

The best answer that comes to my mind is something that may disappoint you: “Just close your eyes and imagine the perfect meeting, where curious people with the right questions get answered by people who know the answers, or are honest enough to say that the answer is yet to be found”. Now name the people you saw, and invite them.

It’s no different from what you would do for organising a party. The party won’t be perfect if the right people won’t show up. Now, do you invite friends to the party according to their roles or attitudes?

A more cynical answer

If this sounds too mystical, or you feel that the key people won’t show up, you may run the opposite approach: “In a year from now, after the project has been a complete failure, burning a couple of million euros, your company will run a post-mortem meeting. Who do you think is going to be there?” And if they don’t look like interested in your unconventional type of meeting you might present the bargain: join the meeting now instead of the post-mortem, you might save some cash this way.

Conflicts are fine

The most common objection, albeit often implicit, is that if we bring all of those people together we won’t be able to handle the conflicts. This is very likely to happen in a traditional meeting, but remember: this is an EventStorming workshop: no tables, no boredom and an unlimited modelling surface on the wall.

The fact is conflict is there, and probably will be there tomorrow too, and it will probably be one of the most dangerous risk factors in your project, so why waiting?

In GOOS book, Freeman and Pryce introduce the notion of Walking Skeleton like the minimal piece of code that touches all the possible architectural pain point, as soon as possible, because you don’t want discover critical spots too late in the project.

I think this approach is really effective, and I also believe that most of the risk in large scale enterprise projects resides in people, so I'll try to reuse the idea and try to get in touch as soon as possible with the key people that could be the biggest source of risk in my project.

Managing conflicts

In EventStorming we’ll have many people discussing around a model they’ll be building collaboratively. For most of the time they’ll care about the area they’ll know more, and the workshop will achieve interesting speed allowing them to work in parallel (we have an unlimited modelling surface, space to walk, plenty of stickies and working markers, remember?).

You may discover something interesting in the way people group and act in front of the modelling surfaces. Some people will take explicit ownership of given portions of the modelling space (which later you may want to label as subdomains), others would be more reluctant, or dubious, maybe they’re not the real domain experts. Some would try to impose their own view over the system, others would try not to contradict their boss. Help them, provide enough markers and stickies to allow them to publish their view too and to let diverging perspectives emerge.

A place for hotspots

One of the things I love about EventStorming is that it provides a safe place for finger pointing. Given we’re building a modelling artefact, we actually can finger pointing at the stickies. When somebody says “it’s not exactly like that”, that’s the moment to listen to a story: “can you explain us why?”

The interesting thing is that, the physical model makes it easy to trigger the conflict - because you see what’s wrong -  but also helps in keeping the conflict at the model level, without turning into a personal issue. As I said, there’s a lot of value in discovering modelling issues and underlying conflicts, the earlier the better.

Solving some conflicts…

Many conflicts may in fact be solved using one of Domain-Driven Design secret weapons: Bounded Contexts. To put it in practice during the workshop, you just need to accept the fact that two diverging opinions by two domain experts may be both right …in their own place. In fact Bounded Contexts are like separate room with their own private model which is perfectly fit to the needs of their corresponding domain expert.

To put it in another way: you won’t solve conflicts by reaching an agreement, or - even worse - a trade-off. You can solve some conflicts just by assuming that the two views are equally valid, and that it would be your job, as a software architect, to find the best way for them to co-exist.

… and get along with some others

Bounded Contexts are great. But they’re not magic. Some conflicts would be resolved by deeper exploration, and that would need time. Time that you probably won’t have during the workshop. Some others, would never be solved (the I-hate-you-damn-bastard-and-I-always-will category, for example).

The best thing to do here is to mark the hotspot - possibly with a vivid coloured signal - advising that this is danger zone, and move on to the best area. This is already really valuable, and nobody is asking us miracles. Endless debating over a single issue might turn the workshop into a boring meeting, so keep the discussion short if there’s no easy way out. Other participants will appreciate it.

In general I am not trying to solve issues or to take decisions during an EventStorming session. My primary concern is to keep the workshop flow going, to have everybody engaged in what we’re building together.

What if we won’t have all the people?

Given a lot of the value resides in observing the interactions between participants, for every key person missing you’ll be losing the value of the interactions between him/her and everybody else. You can do your math, it’s not headcount, it’s counting relationships.

Beware of those folks who promise they’ll join you later. Especially if they are Italians. They’ll miss all the key information: one can not understand a movie from the ending titles, and being there is the most successful ingredient.

Just getting there

However, one might have to acknowledge what’s the real starting point (and I have an easy one: people invite me to run EventStorming sessions in their companies) and get along with that. Every organisation is different.

Sometimes getting the right people on board might be a long process. One may actually get there step by step, so even if I personally prefer to fight for my right to party there might be situation where a temporary trade-off is necessary. Here are some basic tips to get you started.

• Declare experiments: be honest, this might be the first time you run an EventStorming workshop, and even if you attended one, being on the facilitator side might be totally a different job.
• Manage risk: what is the worst thing that can happen during a meeting? It’s probably wasting time… oh, you’ve never wasted time in your company (sarcasm).
• Timebox: every open ended meeting might bloat. Keep it under control key people won’t be available for the whole day. Keep a visible agenda, or a timer. Just try to use participants’ time in the most effective way.
• Look at people’s faces: bored people tend to look bored. Just ask them why they’re not finding interest. And take some corrective action.
• It’s not a trap: some people will look like they shouldn’t really be there. Let them go if they don’t feel like. I normally try to take mobile phones and the like away to have full attention, at least for a limited amount of time, but some roles have different degrees  of machine slavery.
• Take breaks: engagement is good, but drains you energies a lot. You don’t want to be in low fuel status. Take a break, maybe every 45 minutes, and enjoy it.
• Retrospect: whatever the outcome is, just find some time to highlight achievements and problems of the meeting, to be sure next one will be even better.

In some organisations, key stakeholders won’t be available at the same time, or won’t free their time for just another meeting. It’s fine. You haven’t achieved anything yet.

Let your first EventStorming build some reputation in order to be attractive for key domain experts, in the next session.