Flow: Value, Visualisation, Verification, Vision

Achieving Flow means getting out of your comfort zone and being fearless in your adoption.


Flow starts with organising, motivating and specifying towards the flow of value to your ultimate customer.


Organise and motivate for Flow then visualise it flooding through your value streams.


Bad features can Flow too. Constantly verify the value and verify the product.


Repetition breeds boredom. Boredom eradicates Flow. Flow needs to be sustainable. Maintain Flow by focusing on a bold vision of perfection. Then pursue it relentlessly.


Group Flow

jazz20bandRenowned psychologist Mihaly Csikszentmihalyi describes the optimal experience as being in the Flow state. In this state, the individual is totally immersed in the activity they are performing, they are focused on it totally, fully concentrating on the task at hand. Self-consciousness is lost and time seems to stand still or go by unnoticed.

To achieve this state of Flow, the skill of the individual and the challenge posed by the task are high (but not so high as to be unachievable), the goal is purposeful and there is clarity in what you are trying to achieve and progress towards it is received immediately and constantly.

Henrik Forsgård extends this in his TEDTalk Group Flow[1], where he draws comparisons to a Jazz Ensemble on how Flow is achieved within a team environment.

To achieve Group Flow, the skill levels of the teams individuals need to be similar, they need to understand each others abilities, position and motivations and know that their teammates are interested in what they are doing. They need social feedback on an affective (emotional) level that helps develop rapport and build trust within the team and, just like individual flow, they need clear goals, immediate feedback on progress and a challenge that matches their collective skill level.

When Group Flow is achieved the self becomes suspended and extends to the group; the emotional state of the individuals becomes contagious and spreads through the group; the group develops a collective sense of purpose, believing they now belong to something greater and they start to institutionalise the ceremonies / rituals that they used to develop rapport and the Group Flow experience.

Satisfying these conditions brings individuals together in a joyful and purposeful endeavour. This is Group Flow.

Many of us have been in teams where Group Flow has been achieved and, having achieved it and the recognition it deserves, we have gone on to institutionalise the approach by describing our practices, artefacts and ceremonies in the belief that other teams would follow our rituals in order to attain the holy grail of optimum performance through Group Flow within their team / organisation.

When we institutionalize these practices and ceremonies we are attempting to shape the activities and team structures to foster flow whilst removing the impediments that obstruct it.

If we look to Scrum or XP we see a number of practices, ceremonies, artifacts and roles that have this intent but lack the rituals that are needed to develop rapport and hence truly develop Group Flow.

It is these rituals that are overlooked and for obvious reasons.

For example, which activity is more likely to develop rapport in a team:

  1. Daily Stand-up
  2. Retrospective
  3. Having a Scary-Mask day at the office

I’d argue the first two are there for synchronization and continuous improvement but the third will help build rapport within the team more effectively. This generates affective social feedback.

And this is why it’s difficult and perhaps another reason why there are so many reports that Agile didn’t quite do what it said on the tin. In no Agile process framework have I come across the Scary-Mask day ritual, or the wear odd-shoes day activity for that matter (though that may have been an accident that sparked an epidemic). They are intrinsic to the team and cannot be institutionalized.

So let’s assume you have achieved Individual Flow and this has been extended to the team and the characteristics of Group Flow can clearly be observed.

Job done!

However, the balance in achieving Flow is intrinsically fragile for the individual and the group.

For the individual and a team, if skills begin to exceed challenges, which they will surely do as the individual and team becomes more experienced, then boredom sets in and Flow is lost.

For Group Flow, the institutionalisation of the practices leads us to become focused on the process rather than on team rapport, the practices become repeatable rather than engaging and team mojo begins to wain. In a one year project of 2-week iterations, that’s 26 Sprint Planning sessions, 26 retrospectives, 26 Sprint Demos and 220+ Daily Stand-Ups. Just how many do you need to do for them to become repetitive and dull?

Once boredom arrives, Flow is lost.

We therefore need to provide individuals with a series of graded challenges, able to accommodate a person’s continued and deepening enjoyment as skills grow[2].

We also need to set the team a vision for perfection they can continually strive for where all practices become subservient to that vision.

And we need to wear scary masks now and again.

[1] https://www.youtube.com/watch?v=gFjsllFukZg

[2] Handbook of Positive Psychology, 2005, Chapter 7, The Concept of Flow, Jeanne Nakamura & Mihaly Csikszentmihalyi

Change by Assertion

Metrics should also be observed and not set…especially within a contract framework. We are after open and honest measurements to gauge how we are doing and support decision making. If we impose penalties based on failure to hit certain measures then suppliers have a skill at bending the reporting of these measures to suit and hit their targets….thereby obfuscating this critical information.

Steve Handy's Blog

I’ve been involved in process improvement for around twenty years, I think I’ve had some successes.

This is a problem “I think I’ve had some successes” ?
Last year, I was having a conversation with my friend and colleague about how we could approach a particularly tricky question, Mike and I were challenged with understanding the performance and productivity of a large client organisation’s software engineering department – this is difficult to measure.
Our conversation turned to metrics and reporting and we were both struck, and concerned, by the realisation that the approach in the software industry to improving the way teams work is based on the assertion that a particular approach is just “better”. Customers should “have faith”  that if they stick with the recommended program things will improve, many process improvement approaches dismiss an evidence based approach to process improvement as being too hard, conveniently ignoring the issue…

View original post 221 more words

The Stuff We Call Requirements


Now requirements isn’t the best word for it is it?

By saying we require something we place a constraint on it, we limit our options, we are saying we really really want that thing.

And when we say we require the screen to be blue or the button to be big or for a spell checker…are we really stating a requirement or a preference? And what problem or benefit is this lot solving or providing anyway?

And when I say problem or benefit…do I 100% know for sure that the problem being solved is the right problem and will the benefit I think I am going to get be completely realised?

The product shall provide a revenue of £10,000,000…..

Just another requirement…no, preference…no, wishful thinking.

In http://alistair.cockburn.us/Requirements+are+SINs, Alistair describes the stuff that comes out a requirements phase as exactly that – stuff! It’s not requirements you have captured…

“…what goes into that initial collection of decisions, the Here’s What We’ll Build list, it is all of those and sometimes not any of those, and other stuff, all mixed in. They are simply what some key group of people say at some point, “Here’s what we should build.”

Let us no longer call them requirements. Let’s call them ideas of what we should build. I know, snappy isn’t it?

So if they are ideas of what we should build will we build them? A long long history of projects tells us they won’t all get built. Those that do get built won’t all get used. Those that do get used won’t all have been built as originally intended. Those that don’t change then are the original ideas we had that were worthy of being what we usually call requirements…and that is a small fraction of the overall ideas we had back in the hazy days of the requirements phase.

So the first point to keep in the back of your mind is this…

Requirements are not requirements they are our initial ideas of what to build.

Moving on let’s consider why we are coming up with these ideas of what to build.

There has to be a reason. There has to be goals we are trying to achieve, problems we are trying to resolve. Without this, then our ideas of what to build are more like ideas of something to do to pass the time.

What we really want to come up with are ideas to achieve x or solve the problem of y.

There is a great and worthy distinction here. We are not building something for the sake of it. This is pet project territory and should be avoided (unless you have nothing better to do and you want to learn something new).

We are building things for a specific purpose and you need to know what that purpose is. What are the reasons behind building this in the first place.

If the ideas are the what’s then the reasons are the why’s.

But the why’s are just requirements sorry I mean ideas anyway aren’t they? They are the strategic ideas the organisation has deemed fit to invest their money in.

So second point is this…

Goals and solving problems are ideas for things that will improve the organisation.

But how do we know that the ideas of what to build will realise the ideas that will improve the organisation? They are after all just ideas…

We need some means of ensuring our ideas of what to build directly contribute to our ideas that will improve the organisation and we need some means of validating this contribution.

This leads us to deduce that we somehow need to identify what this contribution will be in measurable terms and also, if we are unsure of this contribution, we will also need some means of rapidly gaining feedback to verify that this assumption is valid.

In Lean Startup[i], Eric Ries describes this as the build, measure, learn loop…

Instead of making complex plans that are based on a lot of assumptions, you can make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop.

The third and fourth point are therefore…

Ideas of what to build directly contribute to ideas that improve the organisation

We don’t know if they will – we just think they will. Therefore we need to…

Gather early feedback how our ideas of what to build contribute to ideas that improve the organisation before we invest wholly in the development of that idea.

So some bright spark somewhere has had a bright idea.

How does this bright sparks bright idea see the light of day?

And why is this bright sparks bright idea brighter than some other bright sparks bright idea?

And which bright spark gave another bright spark the permission to have a bright idea and start working on it? Who comes up with bright ideas?

The principles of the Agile Manifesto are clear on this aren’t they?

–       The best architectures, requirements, and designs emerge from self-organizing teams.

–       Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This suggests that our teams are empowered to come up with ideas for the architecture, the product and the design – they are not told what the architecture is, what the product must do and what the design must be. These emerge through the efforts and imagination of our teams. And we trust them to do this.

So I ask again… Who comes up with bright ideas?

The answer? Point number five…

No-one has the monopoly on bright ideas.

We also need to ensure future ideas are not lost. Deeper analysis of ideas may produce unexpected results that spurn other ideas. These cannot be lost. Ideas for new products, feedback and observations from past ideas need to be captured. Where? Point number six…

Maintain an idea inventory.

With all these ideas bubbling around and a commitment to start building we progress the endeavour with optimism and excitement. There is, after all, nothing like a team of software developers, analysts, testers all pulling together in the same direction trying to build something that is game changing.

But what if its 10 teams. What if its 20 teams or a 1000 developers?

It’s hard enough for a team of 7 to adopt the disciplined approach that successful Agile teams require…but hundreds of them?

You can be optimistic but scaled Agile projects fail just as bad and as many times as traditional ones.

So how do we communicate these ideas to all these teams of people? We can’t expect that we can just visit our teams and talk to them about all these ideas. We should form a backlog of these ideas of what to build and how they contribute to ideas that improve the organisation so they can act as placeholders for our conversations but when we scale it is a good idea to capture a little more.

We need some means of understanding where an idea fits into an overall end-to-end process and we need to know the scope of that idea. That is, we need to know what done looks like for that idea.

In the past we used to write Requirements Specifications. Specifying requirements is worse than capturing requirements when we now know that they aren’t requirements at all. However, I can’t bring myself to call what we should produce an Ideas Specification. It’s more like a map of how ideas are strung together and a set of examples that show what it’s trying to achieve.

The seventh and eighth point are therefore…

Map the ideas of what to build to understand how they relate to one another


Bring your ideas to life with concrete examples

Having produced a map and scaled our project we now need to use this to take our plethora of ideas and somehow distribute them equally between numerous teams. To stand any chance of success the ideas need to be independent yet still contribute to a meaningful clearly stated and communicated set of ideas to improve the organisation that we think would make a decent release.

Our ninth point to keep in the back of our minds is therefore…

Independent ideas are distributed equally amongst teams.

BUT…(and it is a big but isn’t it?)

Are we ready to distribute this much work amongst our teams? How can things be independent without the infrastructure already in place to allow these teams to surge? But getting this infrastructure is costly and time consuming and we haven’t yet verified the Ideas of what to build directly contribute to ideas that improve the organisation. We don’t know if they will – we just think they will. Which one is the egg and which one is the chicken?

My advice is that it doesn’t matter how sweet you’re architecture is if what’s built upon it doesn’t have the business value it deserves. You have to start verifying your assumptions on idea contribution at the expense of architecture…go on, do it…NOW!

Another rationale for deferring architectural perfection is that there is little point delivering a product to market if someone else gets in there first. A great product is, we’ll, great but sometimes getting in there first is more important.

Now lots of people will talk about this and talk about early return on investment and talk about getting the low hanging fruits done quickly. This makes an awful lot of sense. Rather than spending our time perfecting the product lets do the easy high value stuff first and ship it so we can get the first foot in the market and start earning…

Hold on and stop and think for a minute.

Is this always the best strategy?

New innovative products that successfully fill some gap will be copied and enhanced and perhaps eventually overtaken by one of your competitors. New products have a shelf life whereby you will maximise being the new shiny thing that everyone wants.

If you released the easy high value stuff first then how long will it take your competitors to build a similar product when all they have to do is build easy high value stuff to catch up. Plus you’re architecture is pants so its likely to be buggy and difficult to build on. If one of your competitors is a big name then chances are they’ll have more resource, existing assets, better marketing and greater connections and will destroy you in the blink of an eye before saying thank you very much for such great ideas.

So my tenth point is this…

The ideas behind choosing the first thing to build are as important as the thing itself.

Whether this is validating assumptions, time to market, proving architecture, quality to market or preserving the longevity of your market you have to be sure as you can’t achieve them all.

[i] The Lean Startup, Eric Ries, Penguin Books, 2011

The Light Bulb Moment

Our approaches to software development traditionally focus on lengthy phases whereby we understand the requirements, we design the product, we code it then go through numerous test phases until either done or we give up all hope. This traditional approach has few opportunities for feedback and never touches on whether the vision for the project was right in the first place.

Moving forward a number of years, our more contemporary iterative approaches to software development go somewhat further in that they try to get the product in the hands of the users as soon as possible so that we can validate our assumptions straight way. We label these approaches Agile, in that we can react quickly to the feedback we receive, or Lean, in that we remove waste from our process, including the waste of delivering products that are not required.

A project that that is the product of innovation, that exists to produce a product for a new or emerging market, or a product that causes a shift in thinking within an existing market has the most significant need for continuous feedback. This is not just the feedback on whether the products features do what they intended. No, it is much more imperative than that.

Think back to our Saving Lives story. How did this innovative approach become successful? Do you think a group of people got together, had an idea, built it and delivered? They then  sat back and watched the success?

Of course not. An innovation is a guess. It is an analysis of an opportunity that has high risk that it will not deliver the outcomes expected. It is imagining an uncertain future.

In Gamestorming[i], Dave Grat, Sunni Brown and James Macanufo make an analogy from the journey towards an uncertain vision to voyages of discovery:

Like Columbus, in order to move toward an uncertain future you need to set a course. But how do you set a course when the destination is unknown? This is where it becomes necessary to imagine a world; a future world that is different from our own. Somehow we need to imagine a world that we can’t really fully conceive yet – a world that we can see only dimly, as if through fog.

When we have visualized our world we make many steps towards it but the direction is not certain and we need to constantly check where we are and from these results, determine where we go next.

Those that fail to do this may start off in one direction, overcome many obstacles as they travel to their uncertain destination, only to find nothing there or they are back where they started from.

One of the worlds greatest ever innovators learnt this lesson early. Thomas Edison invested time, money and energy in an electric vote recorder. Edison found that the legislative bodies at which the product was aimed exploited the current slow manual process to charm the public for last minute votes.  Edison had assumed that there was a market for his invention but because the recorder would deprive them of this opportunity, the legislators rejected it.

In Edison on Innovation[ii], Alan Axelrod described what Edison learnt from this endeavor:

From this initial popular failure, Edison drew a valuable lesson. He resolved from then on to determine — firsthand — the existence of a market and a need before embarking on any other invention. For him, that lesson was sufficient to turn momentary failure into lifelong success. Nothing, Edison believed, was truly a failure if you managed to learn something from it.

Travelling the route of innovation is different from travelling the common path of business process. The vision and the strategy are not precise so that steps to get there must be different to. We need to provide a framework for creativity and experimentation so that both our vision and our strategy can change as we learn many lessons on our journey to building the product,

The basic assumption of the innovation – the Vision and the Strategy to implement that vision – need to be tested before funds are heavily invested in the product. Edison and the future contingent of innovators treated the approach as experiments with the outcome of learning.

In Lean Startup[iii], Eric Ries describes this as the build, measure, learn loop…

Instead of making complex plans that are based on a lot of assumptions, you can make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop.

The feedback loop is a means to steer the endeavor towards its mission, it’s vision. The endeavor will commence with a strategy to achieve this vision. The endeavor will build (some of the product), measure the strategy’s effectiveness towards the vision and from those measurements will learn whether they should continue with the strategy or change the strategy to be more effective in achieving the vision.

These experiments shape and fine-tune the product over time and many experiments can happen at once to learn many new things. They are important because they provide the constant feedback needed to verify our assumptions to ensure we build the right thing and not the thing we imagine upfront.

The point we enter the world of developing an innovative product is therefore the creation of the Vision. The identification of the opportunity.

At the heart of innovation is the identification of this opportunity.

This is the generation of the vision and the strategy to achieve that vision. These provide the initial requirements for the product.

This is not all of the equation however. We may have a great idea but fulfilling this requires much more. The characteristics of the innovation team are important. This is not your typical stakeholder and requirements manager relationship.

The environment in which innovation thrives is different from our typical office environment. This is where we generate and test the ideas so is an important ingredient in deriving the innovative product requirements.

As discussed, the experimentation process is key to innovation. This impacts the requirements approach tremendously. It is the essence of discovering the right requirements and is a far cry from our traditional review and approval process.

We also need to ensure future ideas are not lost. Each experiment may produce unexpected results that spurn other innovations. These cannot be lost. Requirements for new products, ideas for new experiments, need to be captured on an innovation inventory.

In order to succeed and sustain these ideas we need to ensure we keep an eye on the commercialism of the innovation. Without investment and a profitable outcome then the endeavor will fail. It is therefore key that the requirements for the product also cover affordability aspects and ideas for ensuring the longevity of the product in its target market.

What I’m getting at is that innovation isn’t just about having a great idea.

The idea is not enough.

[i] Gamestorming, Dave Grey, Sunni Brown, James Macanufo, o’Reilly Media, Inc., 2011

[ii] Edison on Innovation: 102 Lessons in Creativity for Business and Beyond, Alan Axelrod, Jossey-Bass, 2008

[iii] The Lean Startup, Eric Ries, Penguin Books, 2011

The Offside Rule explained using Specification by Example


People who know me know that I like two things:

I like my football.

I like my Agile.

Why do I like these things?

The beautiful game.  The beauty of a team, each player knowing the role they play but willing to step into other roles as needed for the benefit of the team. Each player excelling within their own role, some dazzlingly so, but the whole that the team produces is significantly more than its individual parts.

They are self-organizing and cross-functional.

A team who have many practices they work on tirelessly in the pursuit of perfection.

They pursue technical excellence.

They focus only on the next game, each game contributing to the overall objective – Premiership Champions……

They iteratively pursue their goals (and measure progress in points).

You may be forgiven to think that this article is leading to a comparison of football teams and Agile teams. Sorry – that must surely have been done already – it’s just I get carried away when I talk about the beautiful game (now am I talking about football or Agile?).

This article aims to bring an Agile technique together with a football rule in an attempt to explain both.

The off-side rule explained using Specification by Example.

Should have something for everyone.

So let us start with an overview of Specification by Example.

Simply put, it is a technique from the school of Agile that is used to specify requirements using examples. It also goes by the name of Acceptance Test Driven Development. However, I personally feel that dilutes what it is trying to achieve.

Although it uses tests as its primary angle, it is primarily a technique for elicitation and understanding of requirements.

Does that make sense?

It may not as it reverses a traditional viewpoint and achieves something that often comes up in a traditional projects lessons learned.

The traditional viewpoint is that we derive our test specifications from our requirements specifications. In Specification by Example, our tests are our requirements specification.

The lesson learned we do something about is to bring our testers into the project earlier. That is, during requirements elicitation. If our tests are our requirements specification, then it stands to reason we need our testers wonderful edge case seeking brain in the starting position to start coming up with these tests / requirements / whatever.

Make sense yet?

When we sit with our clients during those early stages to try and understand what they want, our Business Analyst often asks our client for concrete examples or scenarios to explain and help the analyst understand the requirement.

When the analyst has this understanding, he tends to discard those examples. They are transitional artifacts used only to get it. Once they get it they then write it down in the form of a Software Requirements Specification or a Use Case or a Functional Specification where they try and describe, in as much detail as they can and as precisely and accurately as the English language will allow, what the system should (or should I say Shall) do.

Even worse, the analyst never got examples in the first place or these examples were basic happy-day scenarios leaving big gaping holes and questions in the resultant specification.

The developer comes along and codes to the spec but some of the meaning is lost so they are forced to make assumptions. They come up with their own examples in isolation to test their work before handing it over to a tester, who has spent the same amount of time coming up with his own assumptions and his own examples in the form of tests.

They come together and the assumptions clash.

They work through the clashes, agree solutions and show it the customer who declares that’s not exactly what I meant, here let me give you an example….

So what if we get the tester and developer involved with the customer and Business Analyst and as a team they come up with examples? The tester will ask all sorts of difficult to answer questions around business rules that the analyst wouldn’t have thought of and the developer will be able to input technical knowledge and his experience on what normally gets missed in order to support the development and automation of tests.

Make sense now?


Time for an example.

The offside rule.

To break the off-side rule a player needs to be in an offside position so let’s keep it simple and start there.

To be in an offside position a player needs to be nearer to his opponents goal line than both the ball and the second last opponent.

Position of Player from opponents goal line Position of Ball from goal line Position of second last opponent from goal line In offside position?
10 yards 12 yards 11 yards Yes
10 yards 9 yards 11 yards No
10 yards 12 yards 9 yards No

Our tester will surely ask now – what if they are in line?

The ball can be played sideward so although you may be in front of the second last opponent the ball has to be played forwards for you to be off side.

Also, you can be level with the second last opponent when the ball is played forward without being in an offside position.

Tables gets updated to now look like this.

Position of Player from opponents goal line Position of Ball from goal line Position of second last opponent from goal line In offside position?
10 yards 12 yards 11 yards Yes
10 yards 9 yards 11 yards No
10 yards 12 yards 9 yards No
10 yards 10 yards 11 yards No
10 yards 12 yards 10 yards No

Now matter where on the pitch, if the player is in front of the ball and the second last opponent, is he offside?

No – they can only be offside if they are in the opponents half.

Now lets imagine our football pitch is 100 yards long, resulting in the half way line being 50 yards from either goal line.

So if our player is more than 50 yards from the opponents goal line they can never be in an offside position. Even if standing directly on the half way line.

Position of Player from opponents goal line Position of Ball from goal line Position of second last opponent from goal line In offside position?
10 yards 12 yards 11 yards Yes
10 yards 9 yards 11 yards No
10 yards 12 yards 9 yards No
10 yards 10 yards 11 yards No
10 yards 12 yards 10 yards No
51 yards 53 yards 52 yards No
50 yards 53 yards 52 yards No
49 yards 53 yards 52 yards Yes

So that determines if the player is in an offside position.

Yes – but many pundits often make errors with regard to the second last opponent so we should clarify that with an example.

The error they make is that they miss the fact that the last opponent (not the second last opponent) is usually the goal keeper and is often disregarded from the decision. For the player to be in an offside position this is irrelevant. The player must be  closer to the goal line than the ball and two players (whether this is the goal keeper of not) to be in an offside position.

Position of Player from opponents goal line Position of Ball from goal line Position of second last opponent from goal line Position of goal keeper In offside position?
10 yards 12 yards 11 yards 1 yard Yes
10 yards 9 yards 11 yards 1 yard No
10 yards 12 yards 9 yards 1 yard No
10 yards 10 yards 11 yards 1 yard No
10 yards 12 yards 10 yards 1 yard No
51 yards 53 yards 52 yards 1 yard No
50 yards 53 yards 52 yards 1 yard No
49 yards 53 yards 52 yards 1 yard Yes
10 yards 12 yards 11 yards 80 yards Yes

In this last case the goal keeper is up for a last minute corner in an attempt to get a last ditch equalizer. It happens but to be onside when the ball is played forward and the player is in the opponents half the opponent would need to have at least two outfield players further forward than the player for the player to be onside.

Make sense?

We now need the rules to determine whether being in an offside position causes an offside offence and the resultant raised red or yellow flag followed by the blowing of a whistle.

The player in an offside position only commits an offence if the ball touches or is played by one of his team and the referee considers the player in an offside position to be interfering with play, with another opponent or is gaining an advantage.

Player in offside position played by or touched by other team member interfering with play, opponent, or gaining advantage offside offence?
No N/A N/A No
Yes Yes Yes Yes
Yes Yes No No

In reality, when designing your tables, you’d probably need to ask a few questions of your customer (a referee in this case) to get a deeper understanding of the requirement.

For example, what does “touched by other team member mean?”, “what constitutes interfering with play?”, “what gives a player an advantage?” and most importantly, “can you give me examples of each?”. You can then build those examples into the tables for a clearer picture.

Back to the next part of the rule.  The player cannot be penalized if the ball was played from a goal kick, a throw-in or a corner kick. We therefore need to include the type of play that is leading up to a potential offside call.

Player in offside position played by or touched by other team member interfering with play, opponent, or gaining advantage Play Type offside offence?
No N/A N/A Open No
Yes Yes Yes Open Yes
Yes Yes No Open No
Yes Yes Yes Goal Kick No
Yes Yes Yes Corner Kick No
Yes Yes Yes Throw-in No
Yes Yes Yes Free Kick Yes

There we go.

Specification by Example explained with an example.

The offside rule explained using Specification by Example.

Today sees the start of the Premier league so go impress your friends in the pub tonight with your knowledge of the most discussed rule in football. There will always be a bad offside call this afternoon that needs dissecting over a pint.

A final note…..

Come on Villa……!