Agile Testing Days 2015, Day 2

Sorry folks!! I’ve just now started the live blogging and it’s 1 pm. OOPS.

The reason is that I had my own talk at 10:50 in the morning and I was too nervous to attend the opening keynote. Which is a shame, because I heard it was awesome. A very personal story from an amazing woman, apparently. Sorry I can’t give you any more information about it than that.

I’m very happy with how my own talk turned out. The support was overwhelming, the room was packed! I hope I gave people inspiration to try out Exploratory Testing with their own team.

It was a thrilling experience to give my talk. This was the first time I gave a talk as a ‘real speaker’. Last year I had a consensus talk and I’m very glad that I was given the opportunity to do it ‘for real’ this time. I think it’s great that this conference offers beginning speakers a way to give their talk.

After my talk I was too hyped up to go to a next session. I also had people coming to me to talk about their own experience with Exploratory Testing in their team. That is great!! We should share our own stories, what went good and what went bad. This way, other people can learn more about it too. We should sort of start a ‘hive mind’ of exploratory testing knowledge. In my opinion the goal should be to get more people infected with the testing mindset. If we could do that as a community, that would be awesome! Start a movement!! (Thanks Karen en Sam!)

Last night was crazy btw. The magician at the party was insane. I had the ‘honor’ to go on stage as well. When he picked me as ehhh ahem..’victim’, I was like ‘Oh god…let’s see where this is headed’, but it was fun. And I was fooled big time.

The dinner was funny again too. David Evans and his quest to get the right people at one table is hilarious 🙂 I decided to keep sober that night because of my talk today. That made me a bit boring maybe, but I felt like it was a wise decision.

Almost forgot, we also did the Escape Room with a group! Oana, Martin, Wim and I just decided to go there and the hosts were so kind to let us go in at once. It was amazing!! We managed to set the record (so far), so try to beat us to it!

The evening was awesome, really what sets this conference apart from the rest. So many nice people, unique atmosphere, great conversations, what more do you want?!

Okay, now on to the present. Ben and Tom are going to give the after-lunch keynote about secret sauce or something. It’s gotta be sateh-sauce right.

Keynote Ben and Tom – Here is secret sauce, there is no secret sauce, SAUCE??!

I feel like wanting to eat something with ketchup. But this talk is about investing in the software development itself. They claim that the same approach in managing finance can be used in this matter.

We spend more time tracking what we do instead of doing it.

Questions: are we investing in the right thing?? How exposed to risk are we?

So how do you invest in making an impact with your software.

Learn, decide to invest, establish performance boundaries, execute and monitor, steer. This is a circle that can go on and on.

Feedback loops all over the place again! But they are very important indeed.

But why are we even here, what is the problem anyway??

We used to delivery software like a glacier, painfully slow. The impact was clear and it was big (but at once). We used to track software with ‘percentage complete’. Release, done.

Then we had the agile revolution. Delivering software become more often. Weeks, days (minutes?). There is impact on the business on a daily basis. But we still are trying to measure progress in software. Yet…that is impossible. We also still track input, when that makes no sense at all anymore.

Project management didn’t go on this journey and is still using old-skool tactics that make no sense anymore.

[is this the right audience for the talk?]

If the goal is making an impact, then why are we tracking software delivery? It only gives an illusion of control, when you aren’t measuring the impact.

Why do we even want fast feedback on software?? You want to know whether the software has IMPACT. So we need to change what we want to see.

Why haven’t we learned this yet? So bang your head against a wall…wait no, don’t do that.

Clear description of a problem I wasn’t truly aware that existed: COOL. They have my attention.

They have a model to solve this? [hmmmmm…I’m a modal sceptic person]

We often believe that 1. write software —> Earn money. But we forget phase 2.

Spend money -> people -> delivery -> impact -> income. That is the model, I guess?

You have to test each phase by forming an hypothesis, so you can invalidate them quickly if needed. Sometimes that led to ideas being thrown out of the window, so that is some money saved right there.

But there is always a level of uncertainty in software projects.

This is a great idea though. To force yourself to write out what you THINK will happen, forces you to think critically about it and throw bullshit ideas out of the window.

They’ve kind of lost me at this point. I really wonder if we are the right audience for the talk. This talk seems to be good for project managers, but for me…I personally find it hard to see what I could practically do with this information. There are still nuggets of knowledge in it for me, but there’s A LOT of information to comprehend. And some of it is lost on me 🙂 I hope for others in the room this talk does hit the sweet spot.

Gil Zilberfeld – Planning with #NoEstimates

I finally have the opportunity to go to a talk/workshop by Gil!! Yay, I met him three years ago on the Agile Testing Days. Great to finally see him in action.

So, what does this No Estimates mean? The term was coined by Woody Zuill, Neil Killick, Vasco Duerto. Woody created the hashtag and quite some discussion happened on Twitter! They wanted to search an alternative to estimating (how it was used at that time).

Why do we need estimates anyway? Audience: To make plans, to please managers, to know when we complete something, to plan for costs, to plan for marketing, dependencies, to address our fear of the future (nice one!).

Summarise: we create an anchor (the plan) and later we can decide how we react to changing circumstances.

Gil asks the audience if they have ever hired a contractor to do work on their house. If you hire a contractor, you have an assumption about when the work will be finished, a general idea. In reality: unknowns happen. We think the plan is under our control, but it is not.

Why do we want estimates? It’s about making better decisions, decide about GO or NO GO, we like to be in control. We want to weigh out options we have.

On the other hand: we don’t like GIVING estimates. Why? We put an expectation on the table, we might feel in our gut that it’s too hard to estimate.

Funny, this talk really gets the audience engaged and stirs something up inside people! It’s a sensitive subject!

Estimates are sometimes treated as: commitments, inflated (or deflated!) by others, and can be a waste of time and money.

[personal thoughts: estimates can also heavily be influenced by the anchoring effect. If someone says a certain number, you are influenced by that number. You won’t give a ‘clean estimate’. Source: Thinking, Fast and Slow book]

But what is the real problem? Do estimates really help in making better decisions? Are you really in control? We make decisions based on biases and gut feeling.

The cone of uncertainty is mentioned. At the beginning of a project we know the least about how it will end up. When we progress and near the end of the project (if you can ever reach ‘the end’) we know more, and less things are uncertain.

Douglas Hofstadter is mentioned, yay!! I love his books. Quote here is: “It always takes longer than you expect, even when you take into account Hofstadter’s Law”.

First exercise starts!! Guessing with a low range and high range on a bunch of questions. I mean estimate….estimate…

Wow, some of these questions were so funny. And in the end I had only ONE estimate that was even remotely close to reality.

We want confidence if our project is going to succeed. So giving a range is one way to increase the confidence a little. The goal of an estimate therefore is not to predict a projects outcome. It is to make sure that the project targets are even realistic enough to be controlled.

Next exercise! We’re going to estimate a space ship. Oh, a space ship simulator (software).

Well our team really struggled with this exercise. We didn’t have a baseline, there were a lot of requirements, weird shit that could happen! To me, it felt like it was impossible to make a planning that was even remotely feasible.

Gil says: it’s very important to write assumptions. That forces you to think about the risk and what you don’t know. Admit what you don’t know!

There are more ways to estimate. Examples: trains. If you knew that every 10 minutes a train to your destination leaves the station, how much is your estimation worth? Sometimes, extra information can help us decide if the estimate is even relevant. Do we even need it in this case?

Break from the session!

After the break we are getting right back to it. The pungent smell of sweat and cigarette smoke is making it a bit hard to for me to concentrate. Some speakers are just so popular! Or the rooms just too small, I don’t know.

Ok, deep breath (ughhhh) and concentrate. Delay cost. Right. When we’re delaying stuff, we’re missing out on possible profit. That is delay cost.

This makes it even more paramount to get the core stuff out in production and not wait. Delay is almost never good. (I think there are exceptions, medical equipment for example?).

We’re going back to the space ship. We have to find out what is important to test first.

This is easier! It’s a bit more in the comfort zone for me as a tester 🙂

I’m getting a bit of a headache because there’s so little oxygen in the room.

After the exercise people tell about their test strategies. Most of them have a risk-based test strategy.

In the end you’ve got to ask the right question: where’s the value? Why do we make these choices?

Liz Keogh’s complexity scale is mentioned next. Great one! View it here: http://lizkeogh.com/2013/07/21/estimating-complexity/

The best way to project something is to look at the data we already have. We then can give SOME level of confidence. Thus it is very hard to project something you have no data about.

Although I like the workshop, I do wonder where all this is leading towards. I cannot perfectly place the #NoEstimates movement in relation to this workshop. I would have liked to get a little bit more context from what this movement is about to paint a better picture in my head.

Now on to something I really was looking forward to! The keynote from Mike Sutton.

Test Beyond Quality, Beyond Software

Mike is a great guy, I love his energy. He wanted to ‘infiltrate’ the agile testing community. Well, welcome man!

He has seen a shitload of companies. His hobby is ‘tasteful swearing’. He has seen a lot of different people.

He wants to provoke, poke, tease and inspire.

What would you do if you cared enough? [in context of the organisation your work for/with]

For me that would be delete all middle management and look smugly at how the company would still work juuuuuuust fine.

We should be able to shape our work in a way that is proportional to what we invest in it. We work a lot so we should at least enjoy it!

Every business is searching. To improve, to increase profit….but how do we search? That what’s this talk is about.

The search is complex. Tiny startups are searching for the first 50 customers (or anyone…to use the product). Mid-sized companies are searching to go international perhaps. Huge companies are trying to break through the 50 billion revenue a year barrier. The higher you go, the expectations are becoming bigger.

Focus your search! Don’t go all over the place. It needs leadership. It needs guidance. It needs our PASSION!

If everybody is searching….then what does that mean for the structure of our organisation. What does that mean for the leadership in our organisation? How do you coordinate a large search? New roles in the search?

Most business decisions are guesses that are said with an air of certainty. Who has the mindset and skills to CHECK and validate those assumptions?

Agile teams are quite isolated in organisations (more often than not). But we need to create this mindset in the whole company. When you are in your fancy, happy, agile team and you don’t want to kill each other that seems alright. Still….it’s just enough to survive, but not enough to thrive. But the rest of the organisation…CHAOS.

Mike asks us to go out of the petri dish and go into the wild. Get this mindset into the rest of the organisation. A better world starts with YOU! So go beyond testing, beyond software development and into the organisation. Ask questions!

What do YOU bring to the search? What are your strong points? What are you passionate about? Do you have a desire to make things better? If a lot of people combine these strengths a movement is born!

Your personal growth and passion is incorporated in the success of your company. Sooooo true!! I’m so glad to work for a company that understands this.

If you start the search, and ask people questions: prepare to face angry people. Be prepared to maybe even lose your job. That is the ‘cost’ of striving to make the world a better place.

Try to find other like-minded souls to go on the search with you, though. I think it’s a good idea to start working for a company that also believes in the things that align with your personal values.

There are NO excuses to NOT do this search. No time? Make time. Don’t have the skills? Start learning. What I face resistance? Keep going!

Great keynote!!!