#NoEstimates episode 2 – THE ANSWERS

Augusto Evangelisti Agile Software development, Lean Software Development, NoEstimates

noestimatesA normal person would expect that sharing free content doesn’t create controversy. Well this normal person is wrong. A couple of weeks back I shared a report on #NoEstimates based on my adoption experience in the last 2-3 years.

I got some thanks, some praise, but mainly aggravation. I had noticed this trend before when tweeting about #NoEstimates, when a group of individuals taunted me with replies and links to their articles that according to them clearly demonstrated that estimates are absolutely necessary and vital for the universe not to implode.

Examples are… People talking to each other by replying to my tweets as if I wasn’t there:

Others saying that what I did had no value and I was trying to sell something 😦

Apparently all this because while looking into my crystal ball I didn’t predict I had to answer this plethora of questions:

 

Even though Mr. Kretzman refused to explain why I should answer those questions as part of a free experience report, today I feel generous and I am going to answer them, ONE BY ONE.

Q1: What do you specifically mean by NoEstimates in your case?

I mean that our development teams don’t lock themselves in a meeting room shooting numbers after perceived size of a piece of work, they save that time and focus on breaking the work down in less complex pieces.

 Q2: What were the details of the domain and situation (value at risk, type of project, technologies employed, size and duration of effort, governance model, industry, team size)?

The domain is sports betting and gaming. The value at risk is the value of a bookmaker with well over 8 billion euro turnover. The type of project is all projects, from a simple web site to a complex trading platform. Technologies are web and mobile. All sizes and all durations, from a one day job to a never ending one. Industry as above, sports betting and gaming. Individual delivery teams are normally from 5 to 12 people, more than one team can work on the same product.

Q3: Was this one team among many in the company?

We started with one team, when we saw it worked we adopted it to one department, then to the whole company. Experiment, measure, learn.

Q4: Was it working on a mission critical product?

Yes. And now on every product.

Q5: When stories were chosen, how’d that process actually work? When stories were sliced, how’d that process actually work?

Defining a meaningful vertical slice of value to deliver and breaking down its user stories are challenging exercises that take time and practice to master. Our teams are always improving using good practices and discovering new ones. As you can imagine I can’t explain it to you in 2 lines on this post, but if you are interested I believe that in a couple of months I can get one of your teams going. My special fee for you is $850/hr expenses excluded.

Q6: Did you forecast completion dates at all or keep slicing and delivering chunk by chunk?

We try to educate our business partners that it is not about scope, time and budget, but about delivering products that matter. Scope is meaningless, we try to talk in terms of customer value discovery.

To facilitate the conversations with our partners we also show trends that can be used as forecast.

#NoEstimates a simple experience report

Augusto Evangelisti Agile Software development, Lean Software Development, Software Development , , ,

Screen Shot 2016-02-05 at 11.41.20I’ve been practicing #NoEstimates with my teams for the last 2-3 years if you want to know how it worked for us, read below.

First of all an answer to all the people that in these years have been telling me “Yes, but if you are breaking user stories down, then you are estimating”

Not at all #1: There is a fundamental difference in the the way we think when we are estimating a story and when we are trying to break it down into simpler ones. In the first case we focus on “how big is this?” in the second case we focus on “let me understand this well so that I can identify simpler sub-entities”. The result of the second exercise is improved knowledge, in the first case this is not necessarily the case.

Secondly an answer to the people that in these years have been telling me “Breaking down user stories is dangerous, you will lose track of the big picture”

Not at all #2:  We haven’t lost the big picture in 2 and 1/2 years, I am not saying that it is not possible but I would argue that my factual experience on the field is more valid than your hypothetical worry. And on top of that, there are 2 very underrated but positive effects that comes from breaking down user stories into their smallest possible pieces. Number 1 is the fact that we end up with much simpler user stories; less complexity implies less errors hence less rework. Number 2 is that smaller stories mean smaller size/complexity variability hence higher predictability.

Now don’t get me wrong, breaking down user stories is not easy at first. It takes a lot of patience and perseverance, but once you get good at it, you will see that the benefits strongly outweigh the effort.

Finally an answer to the people that kept telling me “Predictability is important, #NoEstimates doesn’t make any sense”

Not at all #3: Believe it or not but if you get good at #NoEstimates, due to the practices used in points “Not at all #1 and #2” above your forecast becomes much more accurate. In fact, points 1 and 2 make your delivery more predictable.

NOTE for scrummers: I can understand the frustration of people trying to do #NoEstimates with points 1 and 2 while doing scrum. If you try to break down a large number of stories the further in the future you go the more you will stumble upon unknowns. I practice lean software development and would break down user stories Just In Time. This allows me to work on the next most important thing only (I don’t need to fill up a sprint) We use the learnings from the stories we have just completed trying to reduce speculating on unknowns that will be discovered later.

So I suggest:

1) Delay the break down of user stories at the last responsible moment
2) Stop predicting, be predictable
3) Have fun!

Help me find better measures of success

Augusto Evangelisti Uncategorized
rendered concept of a project management triangle
The project management triangle

The concept of success in software delivery has traditionally been associated with respecting cost (budget), scope and time. This concept is generally known as the project management triangle.

The decision on whether delivering the product and the size of the triangle depends also on another variable that is the projected revenue that the product will create for the company.

Agile and lean product delivery teams have pushed the boundaries and in the process questioned the validity of the approach.

The 3 main issues I see with the above are:

  1. Lack of learning: it assumes that there are no significant unknowns at the very beginning when scope, budget, time and projected revenue are set.  Any deviation from the plan is seen as a failure rather than learning.
  2. Lack of customer focus: no consideration is given to customer feedback
  3. All products are the same: it does not separate contextually different products so date driven products that have a hard link to a delivery date are treated the same way as ones that are “simply urgent” but have no hard relationship with a specific date.

When we measure success based on the iron triangle and the projected revenue we risk of missing or straight out discouraging some extremely good behaviours.

Example #1: If we deliver a solution to the problem (in a form of a product) in half the time because we have helped identify the most valuable features, this doesn’t clearly stand out as a win against having spent within budget, delivered in time and  to the full scope.

Example #2:  If through customer testing and experimentation we realise early that the product is not going to deliver on promises and we decide to stop development, this is not recognised as being better than spending the full time delivering the product that eventually will fall short on expectations. Actually, the first behaviour is normally seen as a full blown failure while the second as a success.

Example #3: The same product could be delivered with great or terrible user experience for the customer but the measure above won’t spot any difference.

If we have learned something from the last 20 years of product development is that customer focus, active learning, discovery and data driven decisions have been key to successful products.

The iron triangle clearly does not encourage discovery and learning, what measure can we use that will make sure our teams feel empowered and will be rewarded for continuously learning about their customers and the solution they are delivering?

If I want to be treated like a professional I should act like one

Augusto Evangelisti Culture, Random Thoughts, Software Development , ,

Drunk-Surgeon-801916Developers and testers often complain that they are not recognised as real professional experts, I wonder why.
One category of respected professional experts is for example heart surgeons.

Now let’s imagine I go talk to heart surgeon Mike and go

<me> I need heart surgery
<Mike> Sure we will schedule it
<me> No no no, I need it now because I have a dinner appointment tonight
<Mike> OK, that’s fine we’ll do it quickly, I won’t even wash my hands

Would you trust Mike as a real professional expert? I wouldn’t

Now let’s think about a common scenario where Product owner Jeff comes to me (developer) and says

<Jeff> I need the new payment feature
<me> Sure we will schedule it
<Jeff> No no no, I need it by tomorrow, we need to comply with regulation
<me> OK that’s fine, I’ll hack it together for you and I won’t even write tests

How can i expect to be treated like a professional?

Thanks for the idea to Marcello Duarte (@_md)

 

Talk to me for God’s sake

Augusto Evangelisti Agile Software development, Culture, Humour, Random Thoughts
If you remember this, you're old
If you remember this, you’re old

E-mail is a great tool, it was the first killer app of the Internet, that directly demonstrated the intrinsic value of the network well before the web became useful.

Before e-mail, people that lived far away could communicate through slow traditional mail, expensive phone lines or simply travelling and meeting each other somewhere. The competitive advantage of e-mail was huge and as a consequence its adoption was fast and furious.

It was a no-brainer for any company to use it. We can save time and money with little or no effort, yippeee!

Being an e-mail salesman was the easiest job in the world, I was one.

But, hang on a second, why the hell would you use e-mail if you have to ask a question to your team mate sitting next to you?

A conversation is cheaper than e-mail, a conversation is faster than e-mail, a conversation includes much more information than e-mail, a conversation will finish there and then with a solution.

Let me try to sell my new product: Internal e-mail For Lazy Asses©

Send mail one more time
Send mail one more time

Dear co-located colleagues,

Internal e-mail For Lazy Asses© will allow you to avoid getting up your arse all day while you’re comfortably coding and watching the deep youtubes

In the likely event you suddenly lost your tongue or had your mouth welded by accident, you will still be able to communicate with your team mates and be productive!

You will be able to demonstrate you are working on something while actually not giving a shit about it, because, let’s be honest, if you did, you would go and talk to your colleague and not sit on your arse for days waiting for an answer that you haven’t got in 3 days.

You will be able to avoid troubleshooting or even bother thinking about a problem if you forward it to your full team!

You will be able to conceal your body language so that nobody will know you haven’t got a clue about what you’re talking about; when suspicion arises, you can attach old confusing and obscure threads that will implicitly demonstrate you have known the topic all along

Somebody else will eventually do your work, yippeeee!

So, are you buying it?

Mind maps as a testing tool bug me a lot

Augusto Evangelisti Agile Testing, Testing , ,
I use Mindmup.com for my mindmaps
I use Mindmup.com for my mindmaps

There is one thing that bugs me about mind maps as a testing tool, it really bugs me a lot.

Don’t get me wrong, I find mind maps a great collaboration tool to get ideas out of people’s heads and put them on paper. They are great for designing a test plan, a few testers can sit down, brainstorm and create a map that can be efficiently used as a complete plan.

So what bothers me so much?

This: “Why don’t we do the same exercise together with the developers before the code is written?”

Are we so obsessed with finding bugs that we cannot share our thought process and help PREVENT (yes prevent) the defects instead of catching developers out and wasting customer’s money and time?

I really hope that somebody out there will give me a valid reason why we shouldn’t shift left the mind map creation and prevent the defects instead of detecting them.

Otherwise we should start doing it now, no excuses.

CIAC – Certified Ignorant And Curious

Augusto Evangelisti Humour, Random Thoughts , , , ,
Madrid Is a beautiful city
Madrid Is a beautiful city

Speaking and learning about other people’s ideas at a conference is an incredibly energizing activity for me. The reason, I believe, is the fact that I am naturally very curious; people’s thoughts and ideas generally satisfy my curiosity at least for a few hours.

On Wednesday evening, in Madrid, I was involved in the ExpoQA “Great debate” where speakers, sponsors and the conference goers discussed various topics in an open session.

Inevitably the topic of “Professional Certification” was touched.

I briefly made my point by saying that I am not one for certifications because I believe that what the Greek philosopher Socrates said: “I’m the smartest man in Athens because I know that I know nothing”. For me learning is a continuous activity and the most important element is the acknowledgement of ignorance rather than the certification of knowledge.

The discussion went on with the sponsors making some good points pro certifications and some interesting insights from the conference participants.

On the flight back from Madrid I thought about it a bit more and eventually decided I am going to start certifying Ignorant people. What I mean with ignorant people, is:

people that are aware that learning is a continuous activity and can never end. People that, no matter how much they know about a subject, have the humbleness to listen to all voices, including the ones that they don’t like, because they believe there is always a chance they might learn something. These people, know that they don’t know and are driven by curiosity in their continuous search for knowledge.

The certificate
I started by certifying myself

I had a quick chat with with Socrates on Skype, he liked the idea and that’s why I am here presenting to you the CIAC certification.

Do you want to become a Certified Ignorant And Curious professional?

Add a comment to this post or mail me directly with one sentence where you clearly demonstrate you are a humble ignorant in search of knowledge. You can also tweet your sentence using the tag #IknowThatIdontKnow including my twitter handle (@augeva)

If you are successful, you will receive a prestigious certificate signed by me and Socrates.

No industry benefits, no costs associated, it doesn’t need renewal, you can print the certificate, frame it and proudly display it in your office!

Little Tim and the messy house

Augusto Evangelisti Agile Testing, Culture, Humour, Lean Software Development, Random Thoughts, Software Development , , , ,
The messy kitchen
The messy kitchen

A cute little boy, Tim, lives in a messy house.

In the morning Tim’s mum, Tina, spends an hour looking for rubbish in the house, when she finds some, she writes a note on a piece of paper where she describes the steps that she followed when she found it, and sticks the note in one of 5 different drawers. Each drawer is labelled “Severity 1”,  “Severity 2” and so on down to “Severity 5”.

Tina and Tim’s uncle Bob, meet every evening to discuss the daily findings and after arguing for a good while they agree on how to file the notes written during the day into 5 folders with labels “Priority 1”, “Priority 2” and so on up to “Priority 5”.

Tim’s father, Oleg, every morning picks the folder with label “Priority 1” reads the notes Tina wrote, follows the steps, finds the rubbish and throws it in the bin. He then writes an extra note on the piece of paper saying that he has thrown the rubbish in the bin. If the Priority 1 folder is empty, Oleg picks the Priority 2 folder and follows the same process. Some times Oleg cannot find Tina’s rubbish even when following her written steps, in this case he adds a note saying “there is no rubbish there!”. Sometimes Tina takes it personally and Oleg sleeps in the spare room. Oleg barely ever opens the folders with Priority 3 to 5. Such folders are bursting with new and old notes from many years back.

Tina spends an hour a day rechecking the Priority folders to see if her husband has added his notes. When she finds one, she will follow her own steps to make sure that Oleg has removed the rubbish from where it was as he said he did. If he did it, she will shred the original note, if the rubbish is still there she will add a note at the bottom saying, “the rubbish is still there, please go and pick it up!”. She will spend some more time adding some extra information on how to find the piece of rubbish. Sometimes, while she is tracking some old rubbish she finds some new, in this case she creates another note and adds it to a drawer.

Each piece of rubbish was filed neatly
For each piece of rubbish, a report was filed neatly

From time to time uncle Bob calls around asking for rubbish reports and rubbish removal trends. In these occasions Tina and Oleg spend the night up counting and recounting, moving sorting and drawing before they send a detailed rubbish status report.

Strangely enough, no matter how hard Tina and Oleg work at identifying, filing, removing, reporting and trending rubbish, the house is always full of shit and uncle Bob is always angry. Tim’s parents are obsessed in finding new rubbish but they don’t pay much attention to family members dropping chewing gums on the floor, fish and chips wrapping paper in the socks drawer, beer cans in the washing machine and so on. After all Tina will find the rubbish and following their fool proof process they will remove it!

One day Tim calls her parents and Uncle and sits them down for a chat. He suggests to stop throwing rubbish on the floor and messing up the house so that they can reduce the amount of time spent finding, removing filing and trending the rubbish. He also suggests to get rid of the folders labelled Priority 3, 4 and 5 as nobody has done any work on them and after all the existence of a minuscule speck of dust on the bathroom floor is not going to make their life uncomfortable. He also suggests that Tina calls Oleg as soon as she finds some rubbish so that he can remove it straight away, without the need for adding notes.

Uncle Bob tells Tim that what he says is nonsense, because the family are following a best practice approach for rubbish management and in agreement with Tina and Oleg locks him up in a mental facility.

Everybody lived unhappy ever after.

Have I eventually gone bonkers and started talking nonsense?

No, I haven’t suddenly gone crazy. I am Tim and I want to change the world.

BDD is – BDD is not

Augusto Evangelisti Agile Software development, BDD, Software Development
socrates11_2074496c
Hang on, this is not the real… Ah, OK, it’s a joke 🙂

 

“I’m the smartest man in Athens because I know that I know nothing.” —Socrates 470-399 BC

BDD stands for Behaviour Driven Development

What BDD is (for me)

1. Conversations

BDD is about conversations

The conversations help us understand what we are trying to build and identify the behaviours of our application

The conversations help us share the knowledge about what we are building

Through the conversations we deliberately discover the behaviour of what we are building and remove some of our first order ignorance

BDD uses continuous feedback for deliberate discovery

The discovery helps reduce the unknowns and deliver software that matters

2. Documenting the behaviour of an application

BDD scenarios (or tests) help document the behaviour of the application we are building as they document the outcome of the conversations

3. The tools

There are a number of tools that allow automating the execution of the scenarios.

4. Testing

BDD tests assumptions through conversations, no other relationship exists.

My conclusion:

“BDD is about conversations and collaboration to generate software that matters”

that means: the conversations generate the software that matters

“Wherever it makes sense, describing the the behaviours in business language through scenarios and automating them will help you produce fast feedback and maintain the application as it grows.”

that means: using scenarios and good engineering practices you can be more effective

If you don’t do point 1 (the conversations) you can produce as many scenarios as you want, automate and run them continuously in a server farm bigger than Google’s but you are not getting much value and in my humble opinion you are not doing BDD.

Liz Kheogh, whose contribution have strongly influenced the evolution of BDD puts it very simply saying:

22havingconversations0aismoreimportantthan0acapturingconversations0aismoreimportantthan0aautomatingc-default

What BDD is NOT (for me)

A recurring problem I have encountered with teams starting to use BDD is the emergence of fallacies where teams conflate the problem that BDD is trying to resolve with other concerns, in particular, tools, artefacts and testing.

I am going to come clean straight away, I have been culpable of this for a good while and learned on my own skin how mixing up concepts can be extremely dangerous. See some of my lessons learned below.

 #Fallacy #1: BDD is Testing and automation

This is a very common problem. Often it originates when somebody (usually a tester) hears or reads something about BDD and starts using Gherkin and BDD scenario style to write their tests. This has usually a honeymoon period in which benefits are reaped because tests are now written in business language hence readable/understandable by everybody. This seems to help communication, but in the long term it actually makes it worse because testers and developers start communicating through scenarios written in Gherkin and stop talking. I have personally done this many many years ago. Hands up I screwed up my team communication badly!

In some cases a decision is made to use BDD scenarios to replace automation tests. This creates a confusion around what scenario should be written for developing some behaviour (BDD) and what scenarios should be written for testing the application. Using all boundary, invalid, special scenarios for development is not optimal, we are not looking for bugs, we are building an application based on its behaviours.

Very often, testers will push for having the scenarios automated through the UI and run in an end to end full integration environment. This generally creates a large slow and non predictable automation suite that is not suited neither for BDD fast feedback loops and discovery nor for end to end integration tests.

When conflating BDD with testing we create unnecessary confusion and end up with things that are neither regression tests nor BDD scenarios and are unusable for their original purpose (development of software that matters).

Do you want to avoid all these problems? Separate BDD from testing. They are 2 solutions to 2 completely different problems. Use the appropriate tools for each domain. Live happy.

#Fallacy #2: BDD scenarios are a communication tool

In some shops I have seen business analysts and product owners that had heard or read of BDD decide that they were going to formalise the requirements into BDD scenarios. I have seen this approach, suggested by a few people that do BDD training, but it is a recipe for disaster.  The most important part of BDD is completely ignored and the PO will elegantly formalise his assumptions in BDD scenarios. Once a developer gets the BDD scenario, she will deliver the PO’s assumptions into elegant code.

Tests for their nature cannot be ambiguous, there is no need for questions or conversations if requirements are defined in the form of tests. This is brandished as a great advantage by some people, instead it is the death of deliberate discovery, and the birth of Assumption Driven Development(*).

Do you want to avoid this? Use 3 Amigos conversations as communication tool. After you’re done, you have all the information to formalise the findings of the conversations into BDD scenarios

#Fallacy #3: We use Cucumber we are doing BDD (Feel free to replace Cucumber with Jbehave, SpecFlow, et cetera)

This is a non sequitur.

Some developers get very excited by neat tools and the ones I mention above are quite cool. Using a tool and writing software through BDD scenarios in the absence of conversations is different from doing BDD. Again, in the absence of conversations, inevitably we end up doing Assumption Driven Development(*).

A similar non sequitur fallacy: “We use Jira, we are agile!”.

 I am looking forward to the day in which I will feel ashamed of what I wrote above, because that day I will have learned something.

(*)Assumption Driven Development (ADD) = A person single handedly builds a set of unquestionable assumptions about the behaviour of an application in the form of tests. Normally this approach fails late, when at exploratory testing, somebody questions the PO’s assumptions now built into code.