A generalist specialist
One of the key motivations that led me to Extreme Contracts was the need for more freedom. This article is the first in a short series to explain why I think we are less free as knowledge workers than we usually think.
Hey folks! On 14 February I published a guest post on Vasco Duarte’s Scrum Master Toolbox website. It is about how I like to build trust with my customers even before the relationship has started.
Enjoy!
Eventstorming is an amazing technique/tool invented by Alberto ‘Zio Brando’ Brandolini to investigate a software process, which I also use to investigate an organization’s culture. I wrote this article to introduce a video in which I describe some Eventstorming nuances I had the chance to play with on a few real customer projects.
Last spring I had again the chance to negotiate an Extreme Contract as a freelance consultant and it went amazingly fine, with a true win-win outcome for me and my customer. I really loved every bit of the story I am about to tell you and I hope it may give you some clue on how a freelance knowledge worker like me could get better deals than usual.
So it happened. I have attended Nassim Taleb’s workshop in New York City on risk modeling and taking. I produced quite an amount of articles around this event and this post is meant to make them all available to you.
Continue reading “Nassim Taleb’s Real World Risk Institute – A recap”
In February I will attend a 5-days workshop held by the Real World Risk Institute, to get a full immersion training on risk taking, management and analysis with Nassim Taleb and a few other risk practitioners.
In last Steve Denning’s article on Forbes titled “Can The 21st Century Corporation Operate Without Agile?” we read:
The new industrial revolution may be enabled by technology, but it is not being driven by it.
[…]
Trying to exploit digital technology or the Internet with the management practices of hierarchical bureaucracy that is pervasive in big corporations today is like driving a horse and buggy on the freeway. To get beyond this horse-and-buggy management, and into something more relevant, managers need Agile.
[…]
These are however the results of Agile management, not the drivers of the new industrial revolution.
[…]
The new mindset begins with a focus on continuous innovation and the future. It believes in banking, not necessarily banks. It believes in accommodation, not necessarily hotels. It believes in transport, not necessarily cars. It believes in health, not necessarily hospitals. It believes in education, not necessarily schools.
[…]
What is lacking is a recognition that the Agile way of running an organization constitutes, not just a random potpourri of management practices being driven by technology. It’s a coherent self-reinforcing system of leadership and management thinking that is driving the technology for the benefit of the customer.
It has been already years since the world of mainstream management realized agile is not just a tree-hugging bandwagon – assuming we don’t really need to hug more trees to solve a bunch of real problems – and this blogpost doesn’t have the aim to show you anything unexpected. But still I have been beating the agile track since 2003 and it is so rewarding to see Forbes acknowledge the value of a path that, well… was mine too.
Ad maiora.
Do you create new products and services under conditions of extreme uncertainty? Do you think any contract will make the project more likely to succeed? Are you even an employee? C’mon, don’t be a turkey! Yes, a turkey!
I had this blogpost in progress for a long time. A few weeks ago a tweet by Nassim Taleb – along with the essay attached – made me think of it and so… here it is.
You are going to meet a customer tomorrow. You will discuss about developing a new product. You know she will ask for a bunch of features, a deadline and a budget. She will ask for estimates. Continue reading “How can a contract reduce the need for estimates?”
As a freelance I often face the request to report about my delivery, to assess the effect of my actions and suggestions. During my years spent as an employee though, I learned to ask my colleagues for an assesment with the aim to become more valuable to them. If we all agree business must be user-centred, then why not being user-centred when working as an employee too? Continue reading “Make yourself a valuable employee by measuring your Net Promoter Score”
On May 8 I joined Juego Serio, Sparkling Strategies and Cocoon Projects in Barcelona to attend a LEGO Serious Play (LSP) Facilitation training. I had been waiting that moment a lot.
LSP is a great envisioning method and I loved the way the facilitation training was held: we mainly ran LSP sessions with Lucio Margulis, one of the few LSP facilitation trainers in the world. He gave us a strong theorical background while using LEGO Serious Play to outline all the main LSP facilitation concerns and showing us both usual facilitation patterns and his own skill in action. He proved to be able to ask very powerful questions. It was amazing to stare in silence at how deep the analysis of an apparently easy subject could become. I saw people talking of their aspirations, their assumptions about the context we were working in, their tentative solutions and I even saw people break out in tears.
A photo posted by Jacopo Romei (@jacoporomei) on
The best feature of LEGO Serious Play by the way is not just using LEGO on job – which is actually the very reason why most of the people are curious about it at first. The best of LSP is gracefully forcing each person attending a meeting to formulate, express and share her thoughts on the meeting’s subject. All of her thoughts about the subject. Even the least fair, the most uncomfortable ones.
Have you ever been in a meeting? Sure.
Have you ever seen a meeting in which 2 people out of ten talk all the time? Sure.
Have you ever seen a meeting in which, while 2 people don’t stop talking, other 4 just nod (?) and 4 chat on their smartphones? Sure.
LSP puts an end to this.
What does that mean for an enterprise? For a team? For a non-profit org? For a board?
Mainly two things:
I am already using LSP in my workshops and coaching sessions. I just started to walk along my path to LSP mastery. Will I meet you along the road?
A few weeks ago I attended a NoEstimates workshop held by Woody Zuill and Vasco Duarte in Helsinki. It has been an intense and fruitful day and here is the main insight I brought back home.
The day was led with a very nice pace, the two speakers showing a very different style in explaining their ideas. Their continuous turnover on stage made the workshop very light to follow though packed-up with contents.
The concepts explained during the workshop resonated a lot with what I have discovered through the years about planning product or software development: an estimate is not a promise and both are not a forecast. The first two are quite unhandy too.
According to Merriam-Webster, an estimate is
an opinion on the nature, character, or quality of something.
forecasting is
to calculate or predict (some future event or condition) usually as a result of study and analysis of available pertinent data predict
while a promise is
a statement telling someone that you will definitely do something or that something will definitely happen in the future
Well, that’s enough to spot a linguistic abuse: we are always asked for an estimate, thus for an opinion, while we are committing to a promise and no one cares enough about forecasting – if any useful at all.
I would recommend this workshop to anyone willing to get out of the big bubble lie “sharp estimation is the key factor for success”.
It was only yesterday that I incurred into this old tweet by Kent Beck:
the *craft* of programming begins with empathy, not formatting or languages or tools or algorithms or data structures
— Kent Beck (@KentBeck) February 13, 2015
This message resonates with many reflections I have been through lately.
First, this made me think of all the comments hard core programmers do about the people trying to fix dysfunctional teams, or better: trying to fix dysfunctional IT teams. “What is this? Psychotherapy? We just need more unit tests!” is just an example of the comments I read and heard about people trying to address the problems of a failing team.
Unfortunately, if we agree on solving problems with the right tools, people problems can’t be solved with solutions meant to fix programming problems. That’s easy like that.
Sure, adopted solutions must be evaluated too and it may happen that some get a bit over the line. Sure, we don’t need – and can’t afford – 10 years of psychoanalysis to deliver our next project. Sure, many are trying to oversell the tools they just know about to fix a broad range of problems which may just be too broad.
But please do remember: people problems are to be addressed with people solutions, be it a user requirement, a collaboration issue or a learning resistance.
This is a topic which once in a while brings the teams I am working with to an a-ha moment: programming languages were not invented to talk effectively to machines. Programming languages are meant to bring people on the same page in the cheapest way when facing a programming problem.
Amazingly enough the tweet by Beck is a perfect brief reminder for all of us. Programming:
Programming languages are a tool to help with step 3. Sometimes with steps 2 and 4 too.
If programming languages were optimized on the machine side of the human-machine relationship we would all be writing assembly code today, OK?
The third thought triggered by Beck’s tweet is about linguistic skills in developers and, more in general to all team workers.
If we understand that innovation bottleneck is learning, then we must agree that talking and communicating the slightest nuance of meaning is a key factor when learning together with a group of co-workers.
If we agree that a team is built around a goal – and maintained around a vision, then we must agree that fostering cohesion with the right conversations is a key skill for all the people belonging to the team.
Thus, if we want our conversations to be effective, we must recruit people with good linguistic skills. If we want our conversations to even be efficient, we must recruit people with great linguistic skills.
I have no doubt on this: when hiring a new coder I am willing to trade some of their hard skill for a very good linguistic skill. You think what you talk, you talk what you think.
It has been an intense May and among the several nice things happened to me I had the chance to attend XP2015, in Helsinki, to talk about LiquidO, the open governance model shaped within Cocoon Projects.
The XP conference series is among the top conferences worldwide about agile methods and lean thinking. What do I bring back home from this event? Mainly two impressions.
The first one is about the paths agile methods have followed along the years. I wrote “paths”, plural, because I see more than one.
On one hand I see people involved in a grassroots movement made of user groups, code katas and code retreats but also made of non-coding communities of practice: agile coach camps, agile UX events, lean management gatherings and so on.
On the other hand I see an academic world trying to formalise the whole agile body of knowledge, still looking for the ultimate metric, for the one-size-fits-all step-by-step handbook or for the finally business-agnostic way to analyse the dynamics of a team leading you to a guaranteed success.
While talking with an academic who had just presented his paper about refactoring automated analysis tools, he asked me: “what do you mean with ‘code kata’?”. I don’t have an exact idea of what it is right or wrong, but the impression here is that we have a split community: those who are learning to surf by surfing and those who are trying to learn surfing by describing the whole physic model of a wave with a surfer on top.
How many papers about surfing can you write before becoming able to surf?
Sorry. Agile processes are not formal. But do read Kent’s book, mines, and Jim Shore’s.
— Ron Jeffries, June 2010 [1]
The second and best impression I bring home with me is the one about the community I am in. Actually, the community I am the centre of.
This is not to say I am any important, indeed this is to say I love my network of contacts, made of people who listen from and explain to me. Year by year this network grows stronger and larger – which are not the same attribute – generating opportunities and providing crucial validity checks.
It was amazing to meet good old friends, to meet new ones and consider the chance for new collaborations across geographical and cultural borders. From India to USA, from Finland to Italy, we are all trying to uncover better ways to deliver value with one final aim: happiness.
For taking part of this endeavour I feel grateful to each one of you. Thanks!
[1] Source, my first comment [ITA] and a comment about my comment.
After the rewarding premiere held in last March, on June 23rd I will be holding again a full-day session about agile contracts in collaboration with Alberto ‘Zio Brando’ Brandolini’s Avanscoperta.
It is going to be a very important day for me, considering the chance I am having to re-think the workshop based on the super precious feedback I got after the debut. On one hand I have a better feeling as the date approaches by, considering the positive feedback I received. I was pretty nervous that morning, I had waited that day for years. On the other hand I will strive to treasure the negative feedback I got, mainly about the expectation for even more games! 🙂
I will do my best. Good news already: I will introduce LEGO Serious Play in the workshop after having completed the facilitation training in Barcelona on May 11th!
I. Can’t. Wait.
After the chat I recently had with Greger Wikstrand about Extreme Contracts, another nice video was made by Greger with Joakim Lindbom, both Enterprise Architects from Capgemini. In the video they discuss the nice behavioral and economical patterns emerging with the use of such contracts which I forged a few years ago when I was coaching e-xtrategy‘s team.
It is rewarding to see how e-xtrategy still keeps on using those contracts after years and, at the same time, seeing Greger, such an experienced person in enterprise software development, being so interested in them along the years.
e-xtrategy, Greger, thank you all: you are the best incentive to look for better solutions everyday.
I will also be talking of Extreme Contracts in Bologna next June, during the Agile Contracts workshop.
Now sit back, relax and enjoy the show! 🙂
Extreme contracts and immediate rewards – Architecture Corner, episode #13 from Casimir Artmann on Vimeo.
As I wrote some time ago, we want our deals to be compliant with three main criteria:
Extreme contracts are meant to be simple and address all the criteria we want to use to define a good deal among all the parties involved.
Just three rules, everything follows as a side effect:
That’s all.
The customer express her needs. A team is set up to address those needs. The team starts working on analysing those needs and one week after delivers anything they think worth the fee. The customer evaluates the deliverable and has two options: accept the delivery and pay the flat fee; reject the delivery and keep the money.
If the customer accepts we repeat this short story one more time. If the customer rejects we can either stop the collaboration or try to run another iteration, maybe – but rarely – after having agreed on a different deal about iteration length or price.
On Apr 07 2015 I had a Google Hangout with Greger about this kind of contracts, willing to get his raw feedback. Enjoy our video!
Tonight I dreamt of Giorgio and Danilo. They were ticking me off. They were upset. The build was broken and they had just found a bug, introduced months before by me while refactoring some remote legacy area of our codebase. They were speaking words of reproach about how hard it would be to fix the bug now, being that code as legacy as untested code can be. They were blaming on me because I had introduced a bug in a hard-to-manipulate area of the code. How hard would the fix be now? Why, should I have ever refactor that untested code at all? Continue reading “Dream of your build & build your dreams”
If you are a developer and you were born in the 80’s or in the 90’s, it is very unlikely that your mum and dad pushed for you to start coding. If you are even older it is close to impossible then.
Parents from the 20th century were – and are – usually more concerned about jobs that have been around since the dawn of modern era: lawyers, doctors, architects and all those like these. That also reflects on kids dreams: “I will be an astronaut!” you’ve always heard. You never heard a kid stating with steady shining eyes “I am going to be a programmer!”. So far.
To tell the truth, odds are that you had to fight quite hard to convince the whole family that what you were doing everyday once back from school was not wasting time on videogames, but exploring some very interesting new problem, building your mind up around a brand new kind of job that eventually became yours: developing software.
You started developing software because you liked it and you wanted to.
How does it feel now? Does it still feel amusing? Are you still feeling the urge to solve that very next problem? Are you still willing to improve the way you code? When was the last time you learned a new technique?
At least, the bare minimum: do you still like to code?
Ask yourself this question and be sincere for your health’s sake. If your answer is “no”, think about the reasons that brought you here. No one was pushing on you when you started coding, no one asked you to become a professional programmer, you liked it when you started.
What happened in between?
About one year ago I took part of a Stoos Sparks program hosted by Sander Huijsen and Dawna Jones. We talked half an hour about Cocoon Projects and its open governance model which a few months later we distilled out into LiquidO, made available for everyone with a Creative Commons license.
After one year though the video still irradiates the good vibe it meant for us at that time. Enjoy!