#NoEstimates a simple experience report

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 meYes, 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 meBreaking 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 mePredictability 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

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

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

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

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

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!