Two months off the rat race

rat-race-1After 4 years in PaddyPower I have decided to stop working there and I am newly unemployed.

In the last month, when talking to people about the situation, the questions I was asked in 99% of the cases were: Have you found something else? Where are you planning to work after you finish?

When I responded, “I plan to have a great summer not working and start thinking about getting back into the wheel in September”, I saw worried looks in people’s faces

People generally hear my answer as “I haven’t found anything but I am too proud to admit it and while I struggle with self esteem, financial difficulties and rejection I might hide in my apartment and post on Facebook that I am on an exotic holiday, pray for me”.

It is not so socially acceptable to take a break to think in particular if like me you are  well over 40. It is instead completely acceptable to jump into the next shitty job immediately because it is important to be turning the wheel and if everybody stopped to think the world would likely implode.

Time to think about life. Time to think about what we are. Think about what we want to be.

I am off the rat race for 2 months, ciao!

 

 

What tester are you? /s

Let’s see what kind of tester you are, answer the 3 questions below and find you profile description at the bottom.

You start testing and the product has obvious problems even with the “happy path”, both cosmetic and very obvious bugs are everywhere, what do you do?

  1. I send the product build back and don’t touch it because it is not testable and back to facebook for the day!
  2. I log 124 bugs in extreme detail, one for every problem I encounter. If somebody after 3 days asks me why I am not finished yet, I respond that I am logging bugs and testing is not complete.
  3. I go talk to the developer that made the last check in and ask him why he didn’t test his product. If he says, “because you are supposed to do that” I talk to him about the incredible amount of waste he is creating by delaying the feedback on the product and not testing it himself. I sit down with him, ask him to test the product and fix the issues we find together in a continuous loop until we both are quite happy with the result.
    I then explain to him that if the feedback for each of the issues has to come from a different party (me) the delays in the detect fix retest rate will create a massive amount of waste. I encourage him to test his application before sending it to me and as we are at it I suggest the next time we test it and fix it together.
  4. I tweet to the world how idiotic my developers are and include screenshots of the errors. I spend 2 hours defending my point on social media and catching my interlocutors on inappropriate use of terms to prove my point.

You have been sitting idle on your chair for over an hour because there is a delay in the build you want to test, what do you do?

  1. Yippee I have time to browse the web and watch some videos on youtube! I hope their problem persists for a while, the new Game of Thrones season is awesome!
  2. I look at my test plan, change it a bit, add some graphics, get a coffee and start reading that testing book I always wanted to read.
  3. I have been out of my desk already for 50 minutes. 10 minutes idle time is waste, our customers are getting our product later than they should.They say there is a problem with the build, let me see if I can help out. I go and offer my help to my teams’ developers. They might need me to rebuild a machine to check something or to try something quickly to debug the problem. I get stuck into it, wow, I even learn something about it! I might even resolve the problem altogether using my strong critical thinking skills and looking at the problem from a different perspective. I help, we solve the problem and, yes, now I can test it! Chances are that while troubleshooting the problem I have already gathered a lot of information on the product that will support and supplement my testing.
  4. If developers are idiots there is nothing I can do, I will spend this time blogging about how to become a better tester and how testing is the most important thin g in the universe, much more complex than development by the way.

Developers have nothing to do because the analyst has been sick and there are no refined user stories in the backlog, you just finished testing, what do you do?

  1. BINGO! I might as well re-start House of Cards
  2. I start complaining and moaning about how this company sucks and about how better it would be if I was the decision maker here. We need to hire more analysts and testers of course! I then go back to writing more test cases even if there is nothing to test. I might also create some fancy SQL query to extract lovely bug lists to show to management with graphs and all.
  3. Great opportunity for learning a bit more about how business analysis works. In the previous weeks I have been helping the analyst and I think I can get the job done. I organise a meeting with the team and we start breaking down user stories, as soon as we have a couple ready we can start working. I will replenish the backlog until the flow is reestablished, using WIP limits will help me understand how much work I need to do on this.
  4. There is nothing to do, if development activities are foreign to me, imagine how I feel about doing something that is even further away from my testing world. I am here to find bugs and provide information to stakeholders, not write user stories, hire more analysts if you don’t want this to happen.

RESULTS

If most of your answers are 1, you are a slacker that happened to be doing testing. Why don’t you find a job you enjoy doing instead of trying to avoid the one you have?

If most of your answers are 2, you are an old time tester that spent the last 15 years in a bubble far away from the evolving world. Nothing outside your little testing world is worth consideration, after all you know better than anybody else and why should you improve?

If most of your answers are 3, keep on doing what you’re doing, you and your company will be OK

If most of your answers are 4, I know who you are:-)

 

 

 

Why are we sprinting?

another-victory-for-cipo

A few weeks back I asked this question on a very popular Agile and Lean LinkedIn Group:

10 years ago not many companies delivered value every month and Scrum really helped the industry with the concept of sprint. People started thinking in terms of vertical slices of value rather than systems and started to deliver value often, it was a great step forward towards agility.

Today most shops do 2 weeks sprints and it is commonly accepted that smaller batches are better than larger ones as they are less risky and also allow for earlier benefit realisation.

I understand how the concept of sprint has helped the industry become more agile and lean, but, and there is a but.

Why have sprints today? Why create artificial deadlines? Why create a minimum batch size, be it one week, two weeks or whatever it is?

If I am a mature organisation, I probably have cut delivery transaction costs and have a good strategy for continuous delivery and I am able to release whenever I want with little effort and risk. Why can’t I release when I have value to deliver?

Can anybody give me a valid reason for having sprints?

The topic became popular with a total of 35 thumbs up and 85 comments (including my replies)

Reading the answers, I am not only more and more convinced that sprints are unnecessary and dangerous artificial deadlines, but I am starting to think that in some agile practitioners thinking, the scrum guide has replaced the true reasons for agility.

If you have better reasons why we should always sprint, please add them as a comment, I am still hopeful I have missed something and want to learn.

 

 

 

 

 

 

Testers Prevent Problems, every day

500_euro_banknoten

Earlier Today, I read an article from the notorious tester Michael Bolton titled “Testers don’t prevent problems“. I would like to use an example to counter this assertion end expand the conversation.

Disclosure – I am a firm believer in prevention over detection in product/software delivery.

The Fact– In today’s news, we read that the ECB will be stopping the print of the 500 euro banknote because of its association with money laundering and terror financing.

(Source: The Guardian)

The Problem: According to the article, producing 500 euro bills was an error. It is a bug in the product “Euro currency bills and coins denomination”. In fact such bug has caused quite a lot of problems to our society according to what reported in the article.

Larry the tester – Let’s imagine that Larry, a tester, happened to be in the room where people where deciding the denominations of the euro notes. Let’s imagine he said “Hang on lads, this could be a problem as it would be easy to conceal large sums of money and smuggle them. Banknotes this valuable might help illicit traffic, should we stop at 200 or maybe even at 100?”

Let’s assume there were smart people in the room that decided to take the objection into consideration, made research to prove its validity and as a consequence decided not to print the 500 euro notes.

The Question – Could we say that Larry had helped prevent the problem?

I say yes, how about you?

What I like about Jeff Gothelf’s lean UX approach

Product development has been my focus (more like obsession) for the last few years. I have read all the books and experimented with many of the approaches from lean canvas to impact mapping to the 100 different ways of framing an MVP.

While experimenting I had some success, many failures but in general I have been left with an after taste of something missing. Sometimes I failed to engage by using the wrong language, some other times I failed to even get started because some people just don’t want to hear that they might be wrong and are threatened by experiments that might just show that.

I had the fortune to attend the workshop “Lean UX in the enterprise”  with Jeff Gothelf in Stockholm yesterday and I think I might have found a simple tool that can help me frame the conversations and get results.

Jeff is an excellent facilitator. During the workshop he gets teams of people to design a product. I was really impressed by the simplicity of the approach and the universality of the language used. But most importantly, at the end of the exercise, making decisions on what to build first becomes trivial.

His approach is linear, simple, easy to reproduce and will resonate with anybody with some understanding of lean and agile. I have to say this is a breath of fresh air in this space where some of the authors sometimes feel they are not great if they don’t introduce some new unnecessary term that creates ambiguity and confusion (but also a lot of discussion and website hits for them).

I am going to experiment with Jeff’s approach for the next product I see, I really look forward to it. Thanks Jeff!gothelf

 

What I learned about helping teams use WIP limits

traffic

The Work In Progress limit (WIP limit from now on) is one of the most powerful but counter-intuitive concepts I had the fortune to encounter in my work life.

When suggesting teams to introduce a WIP limit to their boards, I hear objections like “are you saying that doing less things at the same time is going to make you faster? You must be wrong? If I start 10 things I’ll finish earlier than if I can only do 2 at the same time!”

or “Working on one thing at the time only? That’s NOT efficient!

It is indeed a counter intuitive concept, proven by the fact that most people object to it based on common sense.

You might say, why don’t you explain the reasons behind the value of WIP?

Don’t get me wrong, I am familiar with queuing theory, Little’s law and the relation between resource utilization and queue size, but these concepts are not something that can be explained easily every time that the objections are brought forward. Funnily enough, explaining them, is not really efficient.

I have been helping teams use Kanban and the Kanban method for a while now and I have used different approaches around WIP limits to identify the one that gives the best results for the teams.

I have come to the conclusion that the most efficient way to go about this is by (I hate the word) imposing the WIP limit at the very beginning of the adoption, as part of Shu in the Shu Ha Ri learning pattern.

The great thing about having a WIP limit is that it gives strong signals to the team

What’s the most important problem we have to solve now?
What’s the highest risk our kanban board is telling us about?

If your board has a WIP limit you will have to answer the questions and act, if you don’t have one, you can always pick the easy cop out of taking a new less important task
The questions posed by the WIP limit are uncomfortable ones, they won’t allow the team to take the easy option. That’s why I believe that teams will benefit from having them since day one.

I have seen WIP limits cause turmoil in teams, people initially feel uneasy. I believe, the feeling derives from the fact that team members don’t believe yet WIP limits will work, and this is due to their aforementioned counter-intuitive nature.

Eventually teams will internalise the fact that WIP limits help the team focus on delivering instead of retreating to more comfortable, less valuable tasks and it does indeed improve flow. But that’s after a while.

My point is, that if we don’t impose the limit at the beginning, the team might not get there on their own.

As I said before I tried many different coaching approaches, the one that worked for me better so far is this

a) A session with the team in which I go into the details of the mathematical reasons why WIP limits improve flow  (most people won’t believe everything but will have some context and hopefully some curiosity)

b) Get the team started with a system that includes a WIP limit initially set by me and low enough to be uncomfortable (see above)

c) Attend team’s standups, to discourage breaking WIP and ask the difficult questions I mention above if the team is not able yet to read them from the board

d) Facilitate a retrospective after 2 weeks of use and have a conversation around whether the limit is too low or too high

What was your coaching experience? Can you share alternative paths?

#WhyScope – Looking for better measures of success

I’m sick of it. Sick of hearing the scope of this, the scope of that, it’s in scope, it’s out of scope, scope creep, full scope, MVP scope, we need more developers to get the full scope in time, we need more time to get the full scope with these resources. Scope ad infinitum.

Why are you so upset, you might ask?

The reason is simple: thinking in terms of Scope, Time and Budget encourages bad behaviours.

For example, delivering a pot of crap filled to the brim within timeline and budget is considered a success! Yu’ve got to focus on timelines and accurate estimates, you are not required to give a shit about what the customers really need but just to make sure you deliver the full scope, to the brim.

Screen Shot 2016-02-23 at 15.26.41

(Image from Claudio Perrone @agilesensei stolen from this beautiful piece of work that everybody should see)

Instead, if you think out of the box, happen to talk to the customers and understand that what you are building is actually a pot of crap that they don’t want, you have failed, your product didn’t deliver the full scope, you are a failure, shame on you!

I don’t want to work in an industry that thinks in these terms. Am I quitting? No? I want to change it.

Do you want to help me? Start thinking about ideas to shift the conversation from scope, time and budget to measures of success that are meaningful. How about value to customers? How about ability to adapt to their demands? How about development team’s happiness? How about <%add your idea here%>?

Tag these ideas #WhyScope and let’s discover a better way to describe success for a product delivery team.