Why are we sprinting?


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* [do|don’t] (help) [prevent|detect] problems**.

Prevent or Detect.png

*For some definitions of “testers”

**For some definitions of “problems”

Hopefully, that title can be read in ways that will please everyone.


Before I start, I’d like to thank Gus for graciously allowing me to guest-post on his blog. When he offered me the opportunity to guest-post, he included: “If I say you’re my guest, it doesn’t mean that you can only say what I like:-) You can say whatever you like!” which I found to be very mature and a little bit crazy.  So, “Thanks, Gus!”


Onto the topic du jour…


Each time I’ve encountered this topic and debate, I’ve been able to refine my own thoughts on it. And now, I think I finally have a reasonable viewpoint that I’m comfortable sharing.  What follows is an approximation of that viewpoint.


I’ve tried to distill my thoughts on this topic into a few different-but-related themes:

  • Understanding Problems
    • Cause and Effect
    • Perspective
    • Definitions
  • Understanding Abilities
    • Wholly or Partially
    • Prevent or Detect
  • Modeling
  • Purpose, Meaning, Importance, and Value


Cause & Effect

I’m fascinated by causality and love to ask “why”. Sometimes, I enjoy thinking about single or multiple, direct and indirect, past causes and future effects of a given thing.  So, when confronted with a particular thing (such as a “problem”), In order to better understand it, I sometimes think about the past and what cause or causes might have directly or indirectly lead to the “problem”.  And I also like to think about the future, and what effect or effects might directly or indirectly result from the “problem”.  Thinking about all this allows me to better see that some “problems” are just effects of other, different “problems” in the past.  And I can also see that some “problems” might cause other, different “problems” in the future.  While the form (shape) of the problem may change, its essence remains.



I also recognize that a “problem” is only a “problem” to someone at some time.  A “problem” to Jane might not be a problem to John.  Similarly, a “problem” to Jane right now might not have been a problem to Jane earlier, and might not be a problem to Jane later.


And so, with a bit of work and imagination, I can see different perspectives and imagine far into the past and future as single and multiple problems change forms and directly and indirectly become causes and effects of other problems.



Once I’m able to consider the wide variance of what might or might not be considered a “problem”, it is easier for me to see how my definition of “problem” might not match another person’s definition. And so, if/when I want to discuss this topic with others, I first try to establish a shared understanding of the word “problem”.  I try to determine exactly what the “problem” is, who it affects, when it affects them, and how it affects them.  Only then am I better able to begin to understand and discuss whether or not a “tester” can contribute (wholly or partially) to the prevention or detection of the “problem”.


NOTE: I also try to establish a shared understanding of the word “tester”, but I won’t go into that in this blog post.


Wholly or partially?

Adding or omitting the word “help” in the title of this blog post can change the meaning of the statement drastically. By omitting the word “help”, the statement may be interpreted to assert that a single individual, completely unaided, does/doesn’t totally do some action.  However, by adding the word “help”, it allows that the individual may only partially contribute to some action.  Which action?


Prevent or Detect?

If the action in question is “detecting”, then I think that an individual can do it completely unaided. However, if the action is “preventing” (defined previously as “the action of stopping something from happening or arising”), then I think it is less likely that an individual can do it alone.  In my experience, it is rare that a single individual has the ability or authority to “stop (a problem) from happening” alone.  In my experience, it is more likely that a single individual only partially contribute to the action of “prevention”, and must rely, to some degree, on others, as well.



“All models are wrong but some are useful” – George Box

Problem Cause & Effect.png

This is one model I made and found useful as I try to visualize and understand this subject and the ideas above. Hopefully, you will find this model useful, too.  This model attempts to show various problems (represented by red shapes) as they change from one form into another form through time.  Each problem is both an effect of previous problem(s) and a cause of subsequent problem(s).  I use this model to help me think about different problems at different stages in time from different perspectives and ruminate on the assertions posed in the title of this blog post.


For example, I think that some people may focus on the “helping to prevent problem 6” while others focus on the “detection of problem 3”. In fact, I think that both are right and it is reasonable to say “By detecting problem 3, a tester might help prevent problem 6”.  By traversing the timeline, I can also find other ways of saying similar things (such as “By detecting problem 2, a tester might help prevent problem 9”).


However, without first understanding which problem I’m referring to, and from what perspective, it might be possible to appear to disagree with supportive statements.  I frequently see people that believe they are debating this topic, when in fact I think they may simply be talking past one another (https://en.wikipedia.org/wiki/Talking_past_each_other).  Another term to describe this phenomenon is “shallow agreement”.


I also used this model to help me visualize more specific examples, like the one posed here: https://mysoftwarequality.wordpress.com/2016/05/05/testers-prevent-problems-every-day.  For example, the thought experiment posed that Larry could have helped prevent the “problem” (which was ostensibly, “500 Euro banknotes could be used to conceal money”).  I went further backwards in time and wondered if the problem could’ve also been prevented by not hiring the people who were deciding denominations in the first place.  And even further backwards, I wondered if the “problem” could have been prevented if those people were never born, at all.  And then going in the other direction into the future, I wondered if Larry’s help also helped prevent the “problem” of “concealed money being used to buy guns”.  And further, did Larry also help prevent the “problem” of “guns being used to murder people that might give birth to children that would grow up and decide on bank note denominations”?


I then used this model to think about a more personal example of a common “problem”: a software bug. Going forward in time, if I “detect” a bug, it might be said that I helped “prevent” a bad user experience.  And further, it could be said that I helped “prevent” road rage caused by a bad user experience.  And on and on.  Alternately, if I go backwards in time, it could be said that if I had “detected” the typo that caused the bug, I could have helped “prevent” the bug.  And further, if I had detected the exhausted developer that caused the typo, I could have helped “prevent” the typo and the bug.  And on and on.


For me, it is now easy to see how simply moving in time or shifting perspective can change the idea from “detection” to (helping) “prevent”. So, why debate this, at all?


Purpose, Meaning, Importance, and Value

Above, I said that I’m fascinated by causality and enjoy asking “why”. And so, I thought deeply to see if/where there was value in this debate.


But first, with regards to this topic and others, I’ve seen people wonder, “I don’t know why you bother with a reposte against this symatic bullshit”, and similar. Common definitions of “definition” and “semantics” are very similar.  They are, essentially, “a statement of the meaning of a word”.  Likewise, this is also a definition of “meaning”.  So, I think that when folks debate and struggle with “symatic bullsh*t”, they are, in fact, attempting to gain a shared understanding.  A common meaning.  And understanding what each other means is absolutely essential to effective communication.  I think it’s also worth noting that understanding what someone means does not necessarily require that you agree with them.  Two parties can understand one another while disagreeing.


Back to the reason of this debate: I’ve also seen people ask, “Why is the distinction important?”, and similar.  Importance is a matter of value.  So, why is understanding the distinction between “preventing” and “detecting” problems valuable?  I suggest a few reasons:  First, as stated above: it helps us gain shared understanding, which allows us to better communicate with one another, which is extremely valuable.  Secondly, I think the distinction has value because words can shape our thoughts, consciously and unconsciously.  Subtle phrasing can affect the way we view the world, whether we realize it, or not.  And finally, I find that thinking deeply about seemingly pedantic topics can sometimes help me gain insight into other, related topics, as well.  And this helps give me a better understanding of the world, which I find valuable.

Testers Prevent Problems, every day


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


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.



#NoEstimates episode 2 – THE ANSWERS

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. Governance model? What’s got to do with estimates? 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.