#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.




12 thoughts on “#WhyScope – Looking for better measures of success

  1. I wonder – Does this approach hold when trying to coordinate multiple teams? Across several companies? My team currently works (also) on a project that involves two other companies, and we are all trying to create something we suspect will be useful. Our main difficulty up until now was waiting for everyone to be ready – if they were focused on doing their thing instead of a release date (of course it was postponed, but within the expected buffer, so our plans are not foiled), I don’t believe we could release anything by the time we can now.

    Another question – What if your product is regulated, and the regulating body declares “by August 1st, 2016, all software should do X”, or an audit results in “If you won’t fix a,b,c by next month, we’re shutting you down”.

    in both cases, time is more important than content, which can be improved later. So while it definitely feels shitty “scoping out” the things we know are good and valuable, won’t you agree that sometimes time-framing and scoping is the right thing to do?

    • I suggest you attend the 25 Feb BCS class of Tom. I hope you can accommodate the short notice. t will be worth it (I don’t get commission!), besides, it’ll cost you only zero (BCS member) or UKL40 (non-member).
      Your questions will be answered, and you will see that scope is not the most important requirement. You also will learn what is important and how to clearly and unambiguously specify that.

      I agree that in most cases time is much more important than budget.
      In my experience it’s not about ‘scoping out’. It’s more about scoping right. Better focus on what’s really needed and relevant will save time.
      Furthermore, about half of what people do in projects (or ‘in their work’, if you don’t like the word ‘project’) later proves not to have been necessary at all, so it’s easy to be on time. But that’s the subject of my classes I also do at BCS. Next time probably in autumn.

      • London’s a bit far for me (~5h by plane) but I think I’m missing something – How does “scoping right” settles with the claim that “thinking in terms of Scope, Time and Budget encourages bad behaviours”? (Yes, I know you didn’t say that one, but this is actually the point that I makes me think tat either I’m missing something, or it’s just a rhetoric hyperbole – and I suspect it’s the former).

        • Regularly, people from Poland came to this class. That’s even further than Ireland. or are you based elsewhere?

          The so-called ‘iron triangle’: scope, time, budget is a fallacy.
          Budget is much less important than time. Better defining the ‘real’ requirements and better focusing on quality saves so much time. So the idea that larger scope costs more time and budget is irrelevant.

          I regularly help teams and organizations to deliver better results in less time. 30% savings within several weeks is quite normal. Even for Agile teams. See some examples in the box on my home page (www.malotaux.nl).
          However, if you still don’t want to estimate, it will be a bit more difficult to achieve this 30%.
          But the kind of estimating I’m talking about is different from what you think, so perhaps you wouldn’t be too much against it, especially once you see the benefit in practice.

          • Yes, I am based elsewhere.
            I thank you for your comment, which does sound reasonable, but your response still talks the language of scope – even if you do that in a slightly different manner.
            As far as I understood Augusto’s post, the suggestion is to stop talking about those constraints at all, and shifting the focus on creating constant valuable throughput. It’s this view that intrigues me.

          • All projects/work is about >improvingscopewhichhow much< we do things faster, nicer, happier, etc. Those are the values.
            These values have to be clearly and unambiguously defined and quantified, otherwise we don't really know what we are talking about.
            In order to quantify, we need a scale (units of measurement), and meter (how to measure on the scale) and points on the scale, like 'Past': what was the level in our past product. 'Tolerable': if we will not achieve this level, our project failed. 'Goal': this is what we expect to achieve with the time and money budgets.
            I show a simple example at: http://malotaux.nl/planguage

            So, in short: the binary requirements (what should be there or not) are important to scope the work: we're going to improve these functions, and not all the other things we could improve. Good focus on those is important. But the essence is on how much we will improve: the qualities/performances/values.
            This is what Tom Gilb (the grandfather of agile) will teach you.
            Once you see how to define and use these concepts, you will find out that what we call the 'real' requirements hardly ever change. Only the solutions may change, because we learn, they learn, and the circumstances change.

            The moment I see a requirement like: “easy to use”, my reflex is: “3 or 7?” If we cannot put a number on such a ‘value’, we have to decompose until we can.
            If the requirement is “there shall be a password”, we say: “this is a solution, not a requirement”.

            The requirements may be: “We need security”. The reflex should then be: “How much security?”

            I like to quote Tom about these numbers:
            “The fact that we can set numeric objectives, and track them, is powerful; but in fact it is not the main point. The main purpose of quantification is to force us to think deeply, and debate exactly, what we mean, so that others, later, cannot fail to understand us.”
            Better focus allows us to spend less time on delivering better results.

            I hope that the above gives you some hints that we’re not focusing on scope. The scope just confines what we will be working on. The values are the essence. And there is a powerful technique to handle these values.

    • Amit, thanks for your feedback. I am not sure about your first question, could you please explain to me how
      it fits with the article.

      As per the “by August 1st, 2016, all software should do X”, or an audit results in “If you won’t fix a,b,c by next month, we’re shutting you down” this is a clear case where the success is not getting shut down, so in this case you just do what it is necessary by a certain time, this makes me think that my #NoScope can apply to new product development and not regulatory based delivery.

      I am not saying that scoping and time framing is bad, it is an activity we need to do. i am saying that the success of a product should not be based on whether we manage to deliver what, at a certain point, we thought was the thing to deliver by a certain time. What if we do everything in time and nobody uses our product? Merely adhering to scope and time doesn’t encourage checking with the customer.

      • Hi Augusto,
        Thanks for the clarification – it helped me understand the stand against scoping. I was lucky enough to have never (yet) seen a project success measured by “we released on time, within scope”, and I have witnessed several cases in which the product I’m working on had some good reasons to do something by a certain date – either regulation driven, a need to be on market fast, or even a promise to a customer. I also know that in the games industry, hitting the holiday season is considered important. So I wondered why you treat “scoping” as a four letter word – and your answer did put this statement in a place I feel much more comfortable agreeing with.

        (My first question was just another example of a situation I thought time-framing and scoping were important to enable us to deliver anything at all. )

  2. @”your product didn’t deliver the full scope, shame on you”

    The ‘full scope’ is probably defined in, as we call it: ‘wishy-washy poetry’, or ‘management bullshit’ and in a real requirements class you will learn how to traslate it into clear and unambiguous, and measurable descriptions. Huge tame saving.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s