Author Archives: admin

Understanding SDLC


Is SDLC a framework or a methodology or a process?


It’s none of the above. It’s a lifecycle. The clue is in the name.

As such, it’s a somewhat orthogonal concept to everything else. Because it’s descriptive, not directive.

It’s probably closest to being a framework — in that it’s very large and loose. And you could build a methodology out of it.

SDLC is basically a catch all term for longer term software or systems planning — it is most popular when used for Corporate Information Systems.

What is a lifecycle?

Life cycle is probably easiest to understand if it’s followed back to it’s biological origins[^9].

[^9]: All sorts of things are considered to have lifecycles including stars, cultures and empires. But lifecycles clearly have their roots in biology. It is after all the study of “life”.

Human beings, for example all share a common lifecycle. It is well established. Medical science uses all aspects of it. Schools, marketing departments and insurance companies use various portions of it.

The Human Lifecycle looks like this:

  1. We start as two separate gametes
  2. We are conceived and become zygotes
  3. After five days we become a blastocyst
  4. The blastocyst hatches and becomes an embryo
  5. Which then become a foetus
  6. You go through the process of “birth”
  7. After which point you’re considered to be an “infant”
  8. Who then grows up into a toddler
  9. Which becomes a child
  10. Preadolescent
  11. Adolescent
  12. Young Adult
  13. Middle Adult
  14. Old Age
  15. Death

There are expected timings, based on historical statistics for “each phase”. These can be compared across time and between population. How exact these timing can be expected to be varies by stage.

All biological entities have a life cycle. Frogs, trees, fungus.

It helps us understand these things. It helps us plan. It helps us manage. It helps us see problems.

There are developmental markers in human children. We use these to help children who may be struggling.

And there are predictable timelines in all kinds of crops, helping known how long our trees will take to bear fruit.

The concept of SDLC is an attempt to apply the same concept to software or systems development. It’s based on the belief that every software or systems development initiative shares a sufficient similar lifecycle that what happens in one will be applicable to all.

It’s based on the idea that there is a time before a system is first deployed into production (it’s conception and ultimate birth) — and that systems enjoy a youth, proceed into a kind of middle age, and are ultimately decommissioned (death).

Windows XP is now both dead and buried. Windows 7 is now not only officially in old age but in palliative care.

Euthanasia is clearly legal in the SDLC universe as Windows 7 has already been declared “End of Life” as of 14 January 2020.[^2]

[^2]: In some ways though this is more like the old tribal tradition of casting out the older members, as Windows 7 will continue to function, but without the protection of the tribe (Security Updates) it’s going to fall victim to the first hungry wolf it encounters(virus)

Where the confusion sets in — why SDLC looks like it might be a methodology

If you look at some basic SDLC models you will see lifecycle phases such as “Requirements Analysis”, “Systems Design” & “Systems Development”

These look a lot like Waterfall phases. Probably because they are.

And this is where people get confused.

They mistake these SDLC phases for “the” SDLC, and also miss the part that these are the life cycle phases for a Waterfall Project.

And then try and apply these same phases to an agile project, which has the effect of making that agile project, well, a waterfall projects (but perhaps with JIRA® and stand-ups.

The problem is however that unlike say a human being or a frog where the lifecycle just sort of happens, (largely predetermined by our DNA), people tend to feel that they can dictate the lifecycle of a software system. In effect taking on the role of some kind of divine creator.

It’s some what meglomaniac if you think about it…

Anyway, whilst it makes complete and total sense to plan for your systems potentially inevitable demise, it makes a lot less sense to insist that you know exactly how long puberty should last.

Never forget that **real **lifecycles are based on facts and observations. On homogenous samples across long periods of time. By people really good at that sort of thing. The entire insurance industry was founded (and continues to thrive) on this concept.

Whilst our personalities might all be as individual as snowflakes — our bodies don’t know this and tend to follow some fairly well established patterns.

Our educational systems are based on the same principles.

“Based on our experience, we know that humans at this age are now able to assimilate these skills and concepts and take this long to do so.”

And even then, working all with the same species, there are exceptions. Fast learners and slow learners and even children that are far ahead in one are (say reading and writing) but deeply behind in maybe maths or physical development. Even with hundred of years of data on the same species there are confounding outliers.

Lifecycles are useful without a doubt, but they have their limits. And when they’re treated as “the objective” rather than informational guidelines, that’s when things start to go very wrong.

If you and your organisation use or are planning on using SDLC the first question you really to need to ask is “how alike are our projects really?”

Because only things that are very alike should share the same lifecycle.[^0]

[^0]: And of course, if you try and overfit a single lifecycle to a diverse set of things, you end up with something so abstract and general as to be useless — such as “Born”, “Alive”, “Dead”

But this doesn’t entirely stop people from trying.

Because there are, or at least there were, so called SDLC Methodologies created. The one that comes to top of mind is “SSADM” which was quite popular with the UK Government in the early 1980’s

Purely as an example SSADM focussed very much on the pre-writing-code part.

Stage 0 – Feasibility study
Stage 1 – Investigation of the current environment
Stage 2 – Business system options
Stage 3 – Requirements specification
Stage 4 – Technical system options
Stage 5 – Logical design
Stage 6 – Physical design

SSADM is therefore, simply a variant of the Waterfall Framework. Waterfalls within Waterfalls really.

SSADM is basically “Lean Start-up for Grandpa’s” — as it focussed on solving the problem of “should we build it” rather than “actually building it” — that was pretty much regarded as an after thought. It’s very much routed in the belief that “coding is the same as manufacturing” — which was basically the mindset that inspired people to create agile as a rebellion against this idea.

(Agile is fundamentally the enemy of “Software Engineering” — Software Development is nothing at all like engineering. Which any actual engineer will gleefully tell you.)

If you compare the SSADM and Lean Start-up it’s quite clear that one was designed for the civil services — with a deep emphasis on analysis and making very considered and controlled changes at a glacial pace — and the other (Lean Startup) with finding a good market fit for a product in a fast moving competitive landscape.

Life Cycle Stages and Activity

The point that most people seem to miss though is that the concept of SDLC does not demand that we use Waterfall. It is however perfectly understandable however why people think this — especially when you look at generic and (overly) simplistic models which simply look like Waterfall with a “maintenance” phase added after deployment if you’re lucky.

It does not have to be the case however.

A “Scrum Project” for example could be considered to be “in development” for the entire time that you’re sprinting.

When applying SDLC to agile or scrum initiatives it’s rarely useful to “split out” things like “testing” — as this is an ongoing integrated part of the process. It was only separate in many historical SDLC’s because it was a separate phase in waterfall. It’s not part of the concept itself.

Remember life cycles are descriptive, not directive.

So depending on your environment, “Deployed” might not make sense either!

If you’re building up (for example) an SAAS web application — which is updated with new functionality every month. Then deployment is an ongoing activity, not a once off phase. Thus new terminology needs to be created. Perhaps “ongoing development” simply becomes “bug fixes only”

We do not code -> test -> deploy in separate phases. Instead we are “in active development” unless we’ve met some business goal.

You might also choose to follow more design lead approach where you are alternating between “development” phases and “assumption validation” phases where you are simply collecting and analysing data on what you have just deployed in order to see if you’re finished.

**Bottom line — the classic “Waterfall Phases” are not “the” SDLC. **

You see them around because somebody in 1982 was describing / drawing the SDLC for a Waterfall Project.

To apply the same steps to a completely different framework does not make any sense at all. In fact it’s dangerous and misleading.

In the same way that a human, a frog and a Californian Redwood all have completely distinct lifecycles, every organisation (and quite possibly every sub system inside that organisation) should have a set of lifecycle stages that make sense for that organisation or system.

The Fungibility Issue

Bottom line here is that SDLC can be applied well and usefully, or it can be applied mindlessly and stupidly.

Lifecycles are useful for things that are alike. They help us plan for the inevitable.

It is however not that practical to declare a single lifecycle as “best practice” and then insist that everything single thing follow the same stages. We may as well insist that humans live as long as bowhead whales (200+ years if you’re curious).

Useful Applications of SDLC (in my opinion)

I think that SSADM got the focus wrong. SDLC is most useful when we consider the entire lifecycle of a software system or product[^1]

By this I mean not so much the software development phases themselves but rather everything else — as an example of something that might be more compatible with an agile way of working consider:

  1. We are considering the need to build a system
  2. We are figuring out what problem exactly the system should solve
  3. We are negotiating a suitable budget and timeline for our system
  4. We are building confidence that such a system can be built
  5. We are building the system
  6. The System is now in production and generating value
  7. The System is still under active development
  8. The System is in maintenance mode
  9. The System is now at end of life
  10. The System has been entirely decommissioned and we had a party

It’s very useful for senior management to have some indication of the expected lifetimes of systems as well as having plans for data retention and migration once we reach stage 9 (in the above model) — it also helps co-ordinate with other functions inside the average enterprise, such as those people deploying PC’s, Servers and Helpdesks. Not to mention working with vendors whose products the internal systems are likely based all of which have their own lifecycles.

Finance people also find SDLC useful for purpose such as capitalisation and depreciation. Especially if they’re running in a traditional CAPEX / OPEX type of accounting model.

The final useful bit in the SDLC concept is thinking of it as Systems, rather than Software.

This focuses people on planning for the non software parts of systems change. The hardware, the hosting, the policies, the procedures, the people and yes the accounting.

SDLC is best employed when it encompasses a far larger remit than just the development of the software.

Kind of like Design Thinking really 😉

[^1]: Although when this kind of concept is applied to Products, I tend to refer to it not as SDLC but rather as Product Strategy a more general set of practices and principles with application outside of pure software systems. SDLC is a very IT centric view of the world.

CSPO with Design Thinking

If you’re ready to start building the right things, then the LASTing Benefits Certified Scrum Product Owner (CSPO) is the course for you. It’s not just about becoming a Product Owner, it’s about becoming A Great Product Owner.

Perhaps more than any other role, the Product Owner has the potential to create the kinds of benefits that your customers and stakeholders will really notice. Whilst velocity is nice, it’s not as meaningful as results.

LASTing Benefits (Australia, UK) has been on this journey with the Scrum Alliance from the very beginning, and as such, is one of the most experienced providers of Scrum Product Owner training and coaching services in the world.

Who Should Attend?

The course is open to all. There are no prerequisites or pre-reading required. All you need is an open mind, a desire to succeed, and maybe a pen.

In our experience people with the following background, get the most benefit from attending1:

  1. Prospective Product Owners wanting to prepare for their upcoming role
  2. Practicing Product Owners wanting to hone their craft
  3. Traditional Product Managers wanting to know what all this Product Ownership business is about
  4. ScrumMasters wanting to broaden their knowledge of Scrum
  5. Managers of all kinds wanting to improve how they select, work with and manage Product Owners
  6. Stakeholders of all kinds wanting to better understand Scrum from a business perspective and how to get their needs met
  7. Customers wanting to better understand how Scrum works and what is expected of them
  8. UX, UI, & BA – a trio of roles long neglected by Agile. Whether you’re wanting to learn how to work with, or become a Product Owner, this course will give you the practical and definitive answers you’ve been looking for.
  9. Traditional Project Managers wanting to better integrate with existing Scrum Teams or wanting to pivot into Product Ownership.
  10. Anybody curious about Design Thinking in general or more specifically how it works with Scrum.

You will learn

A Product Owners Perspective on Scrum

Learn how to see Scrum not as a series of baffling rituals and obscure artefacts, but rather from the Product Owner’s perspective; as a tool that helps you stick to schedules, manage risks and generate business value quickly and effectively.

  1. Working productively with other members of your Team
  2. Working effectively with your ScrumMaster
  3. Keeping stakeholders, users and customers happy
  4. Implementing Product Ownership well in any context
  5. Scaling the Product Owner Role efficiently and effectively

How Organisational and Industry Context Affects Product Ownership

You will learn:

  1. How your context shapes your implementation of the Scrum Framework
  2. Tools to help you best implement Product Ownership in your context whilst still retaining as many core benefits as possible
  3. How your implementation affects the kinds of benefits you should expect to get from Scrum. What you should expect will get better, and what might stay the same.

The Fundamentals of Design Thinking

Design thinking is more than just beards and buzzwords, it’s a proven way of approaching product development and problem solving that produces great results and fits together beautifully with Scrum.


  1. What Design Thinking actually is
  2. The Benefits of taking a Design Thinking Approach
  3. How Design Thinking differs from typical enterprise approaches
  4. Important ways in which Traditional Design and Design Thinking differ
  5. How Design Thinking implementations can go wrong (pitfalls to avoid!)
  6. How to use Scrum and Design Thinking together
  7. The Role of the Product Owner in Design Thinking

Product Ownership Practices

Release Planning

The afternoon of Day Two is given over to our LASTing Benefits’ World Famous 2 and exclusive Release Planning Exercise.

“Release Planning” is the glue that bridges the gap between Agile and the Enterprise. It’s the process that provides the answer to the question some believe is unanswerable with Scrum:

“What am I going to get and when am I going to get it?”

Working as a team, students will be given the opportunity to apply everything they’ve learned so far and maybe even gain a few new insights to boot!

Our Release Planning Exercise is hands on and concrete. It makes the abstract real and joins up the dots.

We’ll start with a vision and end with not just a backlog, but a plan that we’ll have confidence in executing on.

Students have come away from this exercise calling it “engaging and transformative”. It’s so effective in fact that some organisations have licensed it from us for ongoing in-house use.

About the Instructor

Our Founder and Managing Principal, Simon Bennett, may well be the ideal instructor for your next Certified Scrum Product Owner (CSPO) course.

Here are just some of the reasons.

  1. Over a decade’s experience in teaching the CSPO
  2. Real World Product Ownership and Product Management Experience
  3. A wide range of experience in different industries
  4. Extensive International Experience
  5. Scaled Scrum Pioneer
  6. Global Recognition / Agile Stalwart
  7. Thought Leader in Agile Contracting and Out Sourcing
  8. Thought leader in Mindful Management and Emotional Intelligence in Agile Leadership

Click here to learn more about Simon

Course Includes

  • Full Colour Workbook containing the courseware as well as additional reference materials
  • Two weeks of post course support via email
  • Discounts for colleagues or future training
  • Hearty Lunch Both Days
  • Fully Catered Morning and Afternoon breaks both days

Click here for a more detailed course description on our website

  1. And if you don’t see yourself listed here but still feel like you’d like to come along, feel free to give us a call and talk about whether or not the LASTing Benefits CSPO is right for you!
  2. No really! It is! Honest!

Leaps of Faith

It’s a common trope that agile requires a leap of faith. It requires trust. Trust and faith that I’m guessing are absent in the cultures from which these comments arise.

But this statement makes it sound like trust and faith are exclusive to agile. And I don’t think that’s true.

To better explain this, let’s for a moment reflect on what I call the “Outcome Stack”

Outcome — the results
Output — what is produced
Activity — what is done

Agile, at least if it’s done properly, focuses primarily in the space of outcomes and outputs. Scrum in particular asks us to “allow the activities to look after themselves” in the guise of the “Self Organising Team”1

This is where the trust and faith part comes in, and, in many “Agile Transformations” falls down. Not only does “management” continue to feel a deep seated need to command, control and supervise, a surprising number of team members also feel more comfortable remaning in this paradigm. There appears to be a sense of comfort and safety gained from knowing that “if they (demonstrably) worked hard” they will therefore be entirely insulated from the outcome. (Or indeed lack of output, as long as “their bit is done”)

This sounds a lot like waterfall, the supposedly faithless process that requires no trust, because who needs trust when we have paperwork!

But is that true?

Well it depends on the part of the stack you’re looking at. Sure most Waterfall Style processes have a lot of processes, procedures and active governance in them to make sure that people are busy and doing the right thing. But there is still a leap of faith in there. If you care to look.

This leap of faith lies between the output and the outcome. A long time ago in a board room far far away, somebody, decided that “if we build it, they will come” — that if this particular software was built, then this result would happen. And not only that, but the cost of building that software could be predictable and contained.

“The Business” just put a lot of faith in that person or people. So it’s quite surprising that they usually remain nameless and blameless2 (and why none of them ever want to be the Product Owner3)

That’s trust with a capital T.

So maybe the difference between “Agile” and “Waterfall” is not so much that one requires trust and the other does not. Instead, it’s about who and where that trust is placed.

And that apparently makes all the difference.

  1. This does not of course prevent people from ignoring that maxim and micro managing their teams into the ground. But remember we were talking about doing this properly
  2. I remember a story from a friend about a senior manager who sold a project budget timeline up the chain to the execs — which was based on absolutely nothing at all but wishful thinking. Not even rough estimates. When the project ran “over” these expectations, the team was hauled over the coals, lost their bonuses and had all their leave cancelled whilst they were effectively forced to work nights and weekends to “make up” for their apparent shortcomings. The manager who provided the completely fictitious budget and timeline was not only completely unblamed, but collected their bonus and a modicum of sympathy from her peers for having such a “disappointing project team”. The worst part was that this story seemed to be not uncommon knowledge in the organisation, but people just accepted it. 
  3. I once had a client tell me that Scrum was the exact mirror image of their corporate culture. For them all decisions of business significance were completely anonymised and “laundered” through multiple committees (which also gave them the property of irreversibility) — but the more junior the employee got, the greater the resolution of scrutiny applied to how the person spent their time. 

Defining Different

The Definition of Done is by far the most commonly omitted and poorly implemented part of Scrum.

The reason for this is clear. Nothing suggests a more radical departure from the way in which people in a traditional organisation work than the Definition of Done does.

Sceptical? Confused? Read on…

Done, not Do

First up, let’s look at the meaning of the language used.

It’s called the “Definition of Done“, not the “Definition of Do“.

In most Non Scrum Worlds, employees are used to being told what to do. And of course, if and when you rise up off the bottom of the corporate hierarchy, you might just start telling other people what to do. In either case, the focus here is on the activity. The effort.

So it shouldn’t really come as a surprise that people might quietly drop the “ne” from Done in their minds. Or simply interpret it as “Have you done this?”

Done Defines a Standard

But our definition of done, the Scrum Definition of Done, does not apply to people.

Instead, it applies to the work produced the output of the team. Not their actions.

And that, entirely changes its meaning. Your output cannot “do” anything until it is finished — and so either our work can be used (and is therefore Done) or it cannot, (and therefore is Not Done).

Disputes around this seemingly simple issue, that is, whether work is done or not, is a big driver behind why we bother Defining Done in the first place (where defining means both writing down and more importantly agreeing _to) _what we all mean by Done.

So we should probably define what is meant by “all”.

A standard defined by the recipients

As people progress towards a better understanding of Scrum, their first port of call is usually “what does it mean to work as a team?”.

The initial rung of this ladder is often to move away from the individually focussed “I am done”, towards the collective “we are done”. Note though that in both cases the emphasisis is still on the completion of tasks.

The focus is directed inwards, towards what we are doing.

And thus The Team might say “Ah yes, we have done the testing!! And because we are a good cross functional team, we forced one of the developers to test for an hour on Friday! Please give us a Scrum Cookie! For they are delicious!”1

To which their ScrumMaster may reply: “But when you did the testing, did you fix the bugs?”

“Ah no…” says The Team, “We did not. But we did ‘Raise a JIRA®’. And we got all our points. Cookie Please!”

The focus is on the people and their actions. Were you busy? Did you do all that was assigned to you?

For Scrum, this is not the correct focus at all.

We are interested in the work that is done not the people who are done with their work.

Many teams simply define what they mean for them to be done. Which is valid if they are building something for themselves, but most of the time that is not the case.

Instead, most, if not all, Scrum Teams are building solutions for other people. Other people who have needs and standards (beyond their “functional requirements”) — other people who live in an ecosystem which also, has needs and standards. Needs which must be met. Standards that must be adhered to.

It is these people, and these people alone, who truly know what it means for something to be done.

Done is a treaty

Done is fundamentally a treaty, an accord. Between the people who will do the work and those who will receive it. It is a matching of requirements (typically non functional) to capability.

It is the middle ground between “This is the standard we need” and “This is the level of quality that we can provide”

Of course, like with any good marriage, if the match is no good, then the ceremony should not proceed.2

Too many DoD’s are however created in isolation, supposedly collaboratively, by just the teams — where the greatest achievement seems to be discovering that each of member has a slightly different skill set, and only wants to “do” certain kinds of work.

This results in a DoD which is not so much agreed to, but rather inflicted on our customers. “This is what we are prepared to do, and no more. We say it’s done. So sayeth Scrum.”

It’s about this time that customers start hating Scrum. And not without reason.

If you’ve not actively involved the recipients of your work3 then you’ve not defined done at all.

Done drives non linearity

Once we accept that Done defines a standard rather than a list of activities. Then we begin to see that it drives non linearity.

For example, if we Define Done as “All changes Integrated and Regression Tests passed” (as opposed to merely performed).4 Then all of a sudden our team is responsible for fixing regressions bugs! In the middle of the Sprint!! Work to do that they had not planned for!!!

Now, in order to Get to Done, our developers have to stop working on what they were doing (lower priority functionality we can presume) and immediately onto regression bug fixing — this is hardly the orderly linear view that guideline driven burndown charts portray!

For once the bugs have been fixed the regression needs to be run again5 and we continue this cycle until the standard of what it means to be done has been met. Regardless of the consequences on our velocity.

Done requires Self Organisation and Close Collaboration

This is not something that can be easily or efficiently orchestrated by a single individual. This is something that best emerges from self organisation. In the close confines of a 14 to 30 day Sprint there is no time to raise documentation, there is only time to talk, scribble and gesticulate. Quickly, concisely and purposefully. Because most importantly, we need to act.

If you’re truly Defining Done, Self Organisation is not an optional nice to have, something your tree hugging LEGO® toting hippy coach promotes for no good reason. It’s essential for your survival. But only if you Defined what it means to be Done.

Done Defies Predictability

And here is where the rubber meets the road. Where the organisation rejects or corrupts the Definition of Done. 6

Done destroys predictability.

And that’s usually not acceptable.

If we are going however to be more precise here, it would perhaps be more accurate to say that Done reveals our current lack of predictability. Something that is often only truly revealed, once we take the entire project into consideration, rather than solely focussing on how our developers spend each minute of their waking hours.

So at first it will seem that this is a very bad idea.

How can we predictably deliver on what we “committed to” in a Sprint if we stop and fix bugs! Let alone mess around with refactoring, documentation and architecture!

Defining Done has simply shown us how true predictability is impossible if we continue to make quality a 2nd (or 3rd) class citizen.

After all, that’s why we’ve got so many bugs in the first place!

Done destroys the appearance of productivity. The illusion. It destroys the ever increasing precious velocity we’ve been desperately mining.7

What value is there in quality software? When you could have points!

Done might show us just what a mess we’re in. The damage that’s been done.8

Done can show us just how long things really take around here. From the End Users perspective. And why.

But only of course, if we’re prepared to listen, instead of casting blame and pointing fingers. Which is of course much easier.

Done is hard..

These days, it’s not really that technically difficult; at least not compared to how problematic all this might be politically and emotionally.

Defining Done makes us face our imperfections.

The gap between how we’d like to see ourselves, and how we really are.

It makes us face the visceral unfairness of inheriting a problem created by somebody else.9. And the fact that this in no way stops making it our problem now.

It shows us clearly that we are not an island, we can’t do it all by ourselves, and that we need other people if we’re ever going to get anything really done. And that makes us feel vulnerable. Out of control. Exposed.

Nothing changes the way in which people work more than the Definition of Done

Done changes everything.

Maybe we should call it The Definition of Different.

  1. Scrum Cookies, made from naturally sweet, pure velocity! The secret to hyper activity! Um, I mean productivity 
  2. And just like marriage, often does anyway. Even when everybody knows this is a bad idea. 
  3. Hopefully not because you don’t know, or care who they are. 
  4. Because nothing we have built is ready to use by our customers until this is true. 
  5. Which is typically less drama if you’ve automated it. 
  6. (If they’d not already done so at the crossroads of Self Organisation) 
  7. There has to be a LOTR reference here. Digging for velocity in the Scrum Mines of Moria. 
  8. Or not, I’m mostly referring to legacy code bases here. 
  9. Whether deliberately or not. Whilst it does happen, the majority of technical debt is not created by malice. 

Semantic vs Syntactic Scrum

When I first started doing what I believed to be “Scrum” there were very few rules.

At it’s heart, in the beginning1, scrum was really just about working inside of a self organising cross functional team (of any size) where everything happened at once, instead of in sequential phases. Simple, but also radical. It also wasn’t limited to (or indeed for) software. As time went by thou, things got added to Scrum, although if I’m being totally honest I didn’t really notice that until much later.

The first and perhaps majority of these newly added things were summed up in Ken Schwaber’s seminal book “Agile Software Development with Scrum” (aka The Black Book) – and so that quickly became The Bible. The things that had been added since I first tried it, were, on reflection, largely to do with how you did Scrum than they were about changing what Scrum was. But then something interesting happened. “Agile Software Development with Scrum” began to define Scrum. The How started to become the What.

And almost overnight Scrum became a set of practices.2


Much like a phone stopped being a thing in its own right and became just another app on our Smartphones. The Self Organising Cross Functional Team stopped being the definition of Scrum, and simply became another one of the practices. And not only! All of a sudden those teams were restricted to covens of 7 +/- 2 members. The rules had arrived.3

In the early days of the the 21st Century, Scrum was rather uncontrolled & ungoverned. Whilst The Black Book certainly added new rules, roles and restrictions to what was previously a very open framework, it still focussed a lot on what Scrum was, and why we needed it.

Talk to a few older Agilists and you might find that it’s one of their favourite books, even if they now regard it as a bit dated. It covers many esoteric topics. There is a section entitled “The Kuhnian View on Scrum” which is closely followed by a treatise on “Knowledge Management”, and it was, for a great many people, their first taste of complexity and the works of Ralph Stacey. It was rich with well documented references. It was in some ways more of a proof of Scrum than it was anything else. A way to convince you that this seemingly crazy idea might just work.

The CSM appeared a few years later, around 2003 and at the time it was a prerequisite that you must have read The Black Book before attending. All 158 pages of it. And that was pretty much the only “control” placed on Scrum.

With the students having read the book, and attempted to practice Scrum, in those early days, the the CSM® was much less about the practices and more about the spirit of Scrum. The Philosophy. I have fond memories of Ken teaching a CSM in much the same way a philosophy professor might teach at a University, presenting conundrums to the class which on the Surface appeared to have nothing at all to do with Scrum, but in truth offered transformative learnings to all those ready to listen. Some readers might find a smile appearing on their lips at the mention of “Squirrel Burger”. It was not all roses of course, I remember fines for being late to both your Daily Scrum and being back to class, something that seems outright harsh and clumsy today, but generally it felt like we were focussing on the right things.

Since then, the CSM® has changed, and so has Scrum.

Looking at what passes for Scrum in some places these days, you do have to wonder what happened. I’m tired of reading blog posts about how awful Scrum is and then reading about a process that doesn’t sound remotely like any Scrum I’ve Ever practiced. And there is no point saying that, because you’ll just get the reply “That’s what Scrum is now, I’ve never seen anything different. It’s not a conversation worth having.

And this is happening in a world, where Scrum is now defined and controlled. We have the Scrum Guide! Ownership has been declared! We even have two Separate Certification bodies based off of it.

There is a missing set of years thou, a wilderness, a time after The Black Book but before The Scrum Guide, where existing practices were quietly altered and new practices were semi-officially or defacto added to Scrum. And all the while the community would declare “Scrum has not changed” — even thou Sprints went from “Strictly 30 days or it’s not Scrum”4 to almost universally two weeks long, and the meteoric rise in the number of “Agile Coaches”, started to deeply infringe on the territory of the ScrumMaster — a role so new that it was only barely beginning to find its feet.

But apparently Scrum had not changed.

A Tale of Two Scrums

It’s taken me a while to get this all straight in my head. My first point of call, was of course, like every other coach and trainer “You’re Doing it Wrong” — “Yeah, I know it says X, but it means Y not X”. Some people accepted it, some did not. It worked better back in the days when people got help from the get go. It works less well now when people struggle with Agile for months before getting assistance, long after everything has gotten its own local and binding definition.5

I then started to feel more compassion for my clients — especially since I noticed that so many of them were getting it “wrong” all in the same way. I then took a hard look at the wording of Scrum as it was then defined and realised that it was very ambiguous.6. I started talking about what I called “Misunderstandability7 with friends and at Conferences — and after some encouragement eventually wrote about it.

As it turns out, people don’t like to think that they’ve misunderstood something anymore than they like to be told that they’re wrong, after all those are very similar things, on the surface it seems to indicate that the person themselves is at fault here.8 (Even thou my original intent was to ascribe blame to the object of the misunderstanding and not the person — which I think is still a useful concept)

Additionally, some people seemed to like this New Scrum.9. And with the Scrum Guide in hand they were now able to defend it.

Sure it wasn’t a Scrum that I recognised, but it was spreading. Fast. Depending on when you encountered “agile” in your career, it may well be the only Scrum you’ve ever seen. Even if you’re an “Agile Coach”.

So what shall we call this New Scrum?

The problem with the term “New Scrum” is that it sounds better. So that’s out. As is the term “Modern Scrum”. And “Scrum In Name Only or SINO”, sounds kind of narky. As does Scrum Coloured Paint. Additionally with these last two we’ve ventured into the territory of not doing Scrum at all, but calling what we’re doing Scrum, and that’s not at all what I mean. By New Scrum, I mean people who are certain they are doing Scrum, and can, to some degree prove it (with maybe an audit).

So perhaps the answer lays in letting this “New Scrum” steal the term from us and relable the old — but that didn’t work very well either.

“Real Scrum” is obviously inflammatory and implies, once again, that you are Doing It Wrong™. “Original Scrum” and “Scrum Classic” have exactly the same problem as “New Scrum”, but in reverse.10

It’s a veritable mine mind field. There is change, but no progress. How do we label it?

A Parting of the Ways

And then it hit me, if we didn’t have an evolution or a progression (which we most certainly didn’t) and we didn’t have a devolution either (jury’s still out on that one) — then perhaps what we had was a separation.

A separation of mechanics from meaning.11

A separation of Syntax from Semantics.

And maybe that was OK.

It was time to separate the Syntax from the Semantics of Scrum.

Syntactic Scrum

Syntax is the rules. It’s the processes. The ordering.

Syntax is not only easy to write down, it is what’s written down.

Syntax is the instructions.

Here is an example:

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. The Daily Scrum is held at the same time and place each day to reduce complexity. The agenda of the Daily Scrum is as follows:

What did I do yesterday that helped the Development Team meet the Sprint Goal?

What will I do today to help the Development Team meet the Sprint Goal?

Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

You now know:
1. Who should attend the Daily Scrum (assuming that you know the Definition of “Development Team”)
2. How long the daily Scrum should be (15 minutes)
3. The fact that it should be held at the same time every day

The Syntax of Scrum is the easy part. Hell, you can learn it all in two days!

Once we start talking about Syntax thou, there are of course additionally details which people might want to know such as:12

  1. What should we do if the timebox is exceeded?
  2. What time of the day exactly should we hold the meeting?
  3. What is the definition of an impediment?
  4. Does every day also include weekends?
  5. What should we do if one or more teams members is not present? Late? On Holiday? Sick?
  6. What is the definition of a Sprint Goal?
  7. What if we don’t have a Sprint Goal? (Because we’ve not implemented that part of the Syntax yet)
  8. If the Daily Scrum is held at 0900 one day, but not until 1015 the following day, how do we know what to do in the hour and fifteen minutes of unplanned time!!! (given that the team only plans out the next 24 hours)
  9. Who ensures that people do what they say they will do?
  10. What kinds of punishments are appropriate for violations
  11. Is Gary an impediment?

Syntax tends to lead to a hunger for more syntax. It’s the nature of the beast. You don’t (have to) think, instead you (just have to) apply, which means when you encounter a case which is not covered by your existing rules13 you either wait for external input or go off piste.

Syntax scales

Syntax also has another property that makes it very appealing to the average enterprise – it scales. Syntax is way of creating standards (in action if not output) — it’s no wonder that SAFe is popular in some circles as it’s a massive amount of Syntax, it provides a huge degree of comfort to a certain kind of person. “Well I don’t know whether or not Gary is an impediment, but I’m sure the SAFe Guidance will tell us” — you don’t have to read it, but you do have to know it’s there for this to work. It is also of course easy to measure and manage. I have literally seen consultants from a well known, but will remain nameless consultancy running around timing how long each team’s stand-up (Sorry Daily Scrum) took — and then creating a lovely Control Chart in PowerPoint.

Syntax is absolutely vital, but it also (obviously) has it limitations. Which is why we need Semantics

Semantic Scrum

Semantic Scrum is different. It’s hard to explain exactly how in writing, because that’s the nature of it.

Semantics are the part that’s not Syntax, semantics are the meaning.

If Syntax flawlessly communicated the Semantics then we would have no need of the two words.

Semantics are built out of context, knowledge and experience. And that’s where the problem begins — we’ve all got different knowledge, contexts and experiences.

Not all semantics are hard to explain. Some contexts and experiences are sufficiently shared that it’s fairly easy to explain general if not precise meanings. If you had never, for example experienced “mustard” before, I could quickly convey its meaning to you by saying “It’s a condiment, like tomato ketchup” — and this analogy (because analogy and metaphor are both very useful tools for conveying semantics) would help you understand some very useful things such as:

  1. This is added to food, but is not food (unless you are four)
  2. It generally makes the food taste better
  3. It is savoury, not sweet

But the semantics of Scrum are actually hard to explain — and that’s the central issue. Scrum represents and has always represented a paradigm shift from the default way in which the majority of organisations operate14. This is where the conflict comes in, why “you’re doing it wrong” was the catch cry of the mid 2000’s and also why it was so poorly received. People just kept thinking “but this way makes more sense to me”.

Engaging only with the syntax of Scrum allows us all to avoid that discomfort. By focussing on the syntax and simply assuming you already know what the semantics are meant to be made Scrum seem easy, more palatable. It made it popular.15

But it also changed it.

When we defined Scrum purely by the syntax. The rituals, the artefacts, the roles. The shell became static, fixed. But the underlying meaning was allowed to alter, change and vanish. And suddenly it wasn’t there anymore. And there was also no useful way to talk about it. It was like watching an actor for a character change on a beloved TV show. You knew it wasn’t the same, you could feel it, but everybody was insisting it was the same person and that nothing at all had changed.

Original Semantics

So the pitfall here, is, once again, to tell people they’re doing it wrong. It’s a trap that’s so easy to fall into. It’s sitting right there in front of us, begging us to say “Ah, but the real meaning is this”. Now we’re double dumb. Not only are we wrong, we were tricked! That sucks. Hulk Smash.

And whilst they’re the original semantics to me, they are probably are not to you.16

And nobody really cares what the author thinks after they leave the room.

Alternate Semantics

Instead, I think it’s more useful for us to embrace the concept of alternate semantics. What is original for you is almost certainly not what is original for me, and even authors find later and alternate meanings in their own works.17

Alternate Semantics allow us to get rid of the tyranny of “is” and “should” — it allows all parties to accept that the meaning they have ascribed to the Scrum Practices may not be the same as those of the practitioners that came before them, will come after them, or in any way match the original author’s intent. But at the same time, this does not mean that they are right or wrong. At least in some absolute sense of the words. They are at best, logically coherent and justifiable.

I have noted on many occasions of late, that most of the organisations that are, for want of a better phrase “Doing Scrum Wrong” — would never, ever have attempted it, if they had grokked the original semantics. A particularly enlightened example can be found here.

Useful Results

The concept of Alternate Semantics needs a friend thou. Whilst I’m prepared to accept that multiple interpretations can have value, albeit different kinds of value. I’m not at all prepared to accept that all interpretations are useful. For this to work, we need some level of congruence. That our actions, driven by our interpretations, somehow link up to our goals, and if they don’t, then we have a mandate to explore whether or not it’s our interpretations that might need some revision. Moving away from the rather binary right and wrong, into the world of better.

Room for both

I like this separation. To me, it allows Scrum to be free. It allows both the Semantics of Scrum that I knew (and still believe to contain value) to co-exist peacefully with the Defined by the Syntax Scrum  that in 2019, people love to hate.

I also think it adds something important to the conversation, that context is everything, that simply following the steps is not necessarily going to give you the same results as every other Scrum “Success Story” — it also might give you pause to stop and think critically about what people might actually mean when they say “We are doing Scrum” — sure, they might be following the rules, but what is the meaning behind those rules. What are their goals? Do they line up?

Whilst I’m a known vocal critic of “Waterfall with Stand Up’s” style Agile, that has more to do with me than anything else. It also comes from my assumption that the people who are doing it “wrong”, want to be doing it “right”. And that’s really not a reasonable assumption to make anymore.

All I ever really wanted is for the Original Semantics of Scrum to not disappear. Not fade away. To be remembered for what it was. To always remain as an option for those wanting it to try it. To have a handle onto which to hang the concept. And now I’ve found it.

So now you can practice your Scrum and I’ll practice mine and there is no need at all to have a war about it.

Syntax Diverges Syntax Improves

Whilst it’s never possible to create a perfect string of syntax that will universally and unambiguously conveys the semantics you intend it to.

It is of course possible to improve on your syntax, especially as the context you’re working in changes, matures and is understood better.

Not the least of which is what semantics have people ascribed to your syntax?

I’d like to think that that’s what’s happening with the Scrum Guide. Whilst it’s still far from perfect (primarily because it never can be) it’s lightyears ahead of where it was back in 2008 when I first laid eyes on it. The yearly update cycle, even thou it can get very bogged down in pedantic minutea sometimes, seems to be overall a good thing for it. Perhaps there is hope.

For myself, I’ve continued to evolve how I present my own message, as the audience for it, and the context they come from changes. In many ways this is a dance with the aforementioned misunderstood syntax — as it gathers semantic mould of it’s own, I’m required to refresh the message in ways that are unpolluted and pure. As least as well as I am able to make them.

Mainly, I’m trying to get people to think about the things they often take for granted. To start with the end in mind, to ask what am I trying to achieve, how am I trying to achieve it? What beliefs underly that approach? Is this in line with my organisation’s goals and beliefs?

How about the other people I work with? Are we sufficiently in alignment? (If the immediate answer that comes to mind is “yes”, then I’d recommend counting to 30 and asking again)

Whilst this sounds like it might be hard work, at least compared to following a set of rules and accepting whatever semantics your context and experience automatically ascribe to them. It’s ultimately a far more meaningful, far more effective and dare I say it friendly and relaxing way to approach the world.

Viva la difference.

  1. A decade or more before the Agile Manifesto. 
  2. If you for example read “The New New Product Development Game” you will find little to nothing on the how of Scrum. But rather a treatise on the underlying philosophy along with a few real world project examples (none of them software and all devoid of implementation details). It is so devoid of “how to do Scrum” that if you took the word Scrum out of it (which doesn’t actually feature prominently) many readers would fail to associate what is being described as Scrum at all. 
  3. Yes, this particular rule changed a few years back to 3-9. Just in case you didn’t think I was paying attention. 
  4. Which is why I’m amused that the the Scrum Alliance, at least for a period declared that no Sprint may be longer than 28 days, which is of course 2 days short of the “original” 30. Syntax is tricky. 
  5. Not to mention it’s now possible to hire a an “Agile Coach” or “Trainer” who will provide you with any definition of Agile or Scrum that you want! 
  6. Sure it was less ambiguous if you followed all the rules, which was close to impossible if you misinterpreted them, but by that stage people had adopted a “linear scrum” approach whereby you could just follow the rules or practices, one by by one in isolation. That approach is ripe for problems. Which is probably why there is such a large Agile Industry out there right now. 
  7. Misunderstanabilability is the natural pre-disposition that an idea has towards being misunderstood. It is not the same as ambiguity, where you are uncertain of a meaning, but rather where something clearly appears to mean something, when it, in fact does not. (And often the opposite) 
  8. Or worse, the boss has misunderstood and no correspondence will be entered into with you, the designated implementer. 
  9. Don’t get me wrong thou lots more people hated it. Mostly those to whom were made to comply without any say in the matter. 
  10. My favourite terms of all was “Honest to God 20th Century Schwaberian Scrum” — which represented the Scrum as described in “The Black Book”. I used it for a number of years, and it took off mildly with a small audience for a short period of time. 
  11. I first covered this topic in my Agile 2011 Workshop “Scrum as a Thinking Toolkit” where (amongst other things) the participants learned to interpret the Scrum Practices from the point of view of various stakeholder persona’s. We even threw Cynefin into the mix. It was a fun day. 
  12. I’ve had all these questions asked of me. I’m sure there are more. 
  13. Either because the author didn’t think of it, or because putting in every single case would be tedious and unwieldy. 
  14. That HBR article is called “The New New Product Development Game” not the “Same Old Project Management Game” 
  15. Which to be fair is how most adults get through the day. Encountering fundamental context or paradigm shifts is the exception, not the rule. 
  16. If you ever bother to lose a week researching all the early writings on Scrum as I did a year or so back, you will quickly discover that around the turn of the century there were already semantic and syntactic disagreements between Schwaber and Sutherland. I can only imagine that the Scrum Guide when it came out (endorsed by the both of them and declaring themselves as the “co-creators of Scrum”) was some kind of peace treaty, designed to create a single merged syntax at the bare minimum. Whether or not their personal semantic views have now aligned I could not however say. I guess my point here is that, if Ken and Jeff could not entirely agree on the meaning of the Scrum practices, back when they were creating them, we should not feel too bad about our own personal interpretations clashing with others. Even Ken and/or Jeff. Lastly, each practice may have many potential meanings and benefits, and what we’re often seeing is not disagreement, but rather emphasis and awareness. 
  17. If you don’t believe me that this is true for Scrum, you need only look to the early writings, where the ScrumMaster was described explicitly as a manager, and had authority over the team. Ten Years later and this manager has become a servant leader, who has no direct authority over anybody. The weirdest part about Scrum is that nobody talks about these quite extreme changes in official position. 

Harder, Better, Faster, Stronger

Ask the average person today why they’re currently doing or planning on moving to Agile and they’ll probably say “it’s faster”.

It’s a very popular answer.

But faster at what exactly?

If pushed, they might elaborate “faster delivery“. And then give you a funny look as if to say “What other kind of faster is there?”

So whilst on the surface of it, this sounds like a purely good thing — there is, or at least there can be, a dark side.

This focus on faster delivery in my experience has often led to implementations of Agile which are nothing more than a relabelling of Waterfall, with stand-ups, “stories” and JIRA® added like props1.

The “agile” or “Scrum” part is applied only to the bits of the endeavour deemed to be “the delivery”, which in its most extreme form2 means “The part where the code is written“ 3.

This is what I believe most people mean when they say “Agile Delivery” — a practice which I would prefer to refer to as “Incremental Delivery” — but more on that in a separate post.

But what if that’s not all there is? What if there was more? What if there was better.? (Even if it was harder)

On the Origins of Faster

As ubiquitous as this “Agile is Faster” belief is today, it’s hard to pinpoint exactly when people started equating Agile with speed. After all, the term is “Agile” not “Speedy” and it’s the “Agile Manifesto”, not the “Go Faster Manifesto” so the origin doesn’t entirely lie with the name. eXtreme Programming also offers no real hints, the scrum is probably the point in a rugby match with the least amount of forward movement and Crystals, well they just sort of sit there4. So it’s not immediately intuitive. It’s certainly not misleading.

At a guess, I would conjecture a few things might be casual here:

There are two Agile Manifesto Principles5 which mildly allude to speed:

  1. ”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and;
  2. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Which both sound at least a little bit urgent. Although they seem (at least to me) to emphasise regularity more than they do raw speed. At least the term “deliver” is there.

And then there is Velocity

Whilst a Rugby scrum may be relatively static wrt to delivery, one of Scrum’s6 most (in)famous contributions to the Agile canon along with The Sacred Lemming Mantra is velocity.7

If was a betting man, I’d put my money on velocity and it’s cheerleaders being the culprit here. Whilst the Agile Manifesto principles somewhat allude to speed – they don’t outright say it. Whereas the concept of Velocity absolutely does.

How fast is your Waterfall?

OK, so that’s where it might have come from, but so what? Velocity is great!

What could possibly be the Problem with Velocity?

Well, depending on your perspective, maybe nothing. Or maybe everything.

My personal problem with Velocity is that it’s just a raw measure of output. Even its biggest proponent Jeff Sutherland, talks about how he “rates his Product Owners on a dollars per point metric” — which signals very clearly that the Velocity metric itself, is completely devoid of any value or benefit component.

On an Agile Project, that’s kind of a problem. Especially if you’re not tracking anything else except velocity. It’s no good being early and continuous if you’re not being valuable.

But on a Waterfall project, that’s not a problem. Velocity and lots of it, is all you need. By the time we get to the delivery part in Waterfall, value is assumed. Value was pre-determined and fixed really quite early on in the project, sometime around the point when we got our requirements right and estimates acceptable and it was all signed off.

In this situation, Faster Delivery is absolutely a good thing. We know what we want, you just need to get it done.

Faster in this context also often defined as “Faster than your original estimates” — which is why claims of “move to Scrum get hyper-productivity” are so seductive.

It’s less of a state of being and more like a request “Can’t you get it done any faster?”8


But what if that wasn’t true? What if the requirements were not in fact right?

What if, <gasp> the estimates were wrong?

And what if, that sort of thing happened on a regular basis?

I mean, that’s absolutely ridiculous of course, and would never happen where you work I’m sure. But let’s just imagine it’s true, just for a moment, and explore what that might mean.

If this was the case, then when would you want to know that a mistake had been made? (Assuming you have rational and not political goals and additionally don’t have a job lined up at a competitor)

As soon as possible right? Would that be valuable to you?

Damn right that would be valuable. The more time that passes between having made a mistake, and finding it and correcting it, the more damage we do. We humans have a tendency to compound our errors — and this is doubly true with Software.

Therefore, in a world where we only have imperfect information and mistakes are made, then early detection and correction of those mistakes is something we’ll definitely want.

Work it harder

So how do we discover that something is not as we’d like it to be?

Perhaps we should just rely on our people to tell us.

Because people just love to show you that they’re wrong don’t they? I mean, if a developer suddenly knew that a requirement was wrong (and they’d know surely?). Then they’d ask somebody.

And if and when they asked, they’d also be taken super seriously too, I mean there is no chance at all that they’d be branded as a whinger and told to get back to work and mind their own business? (Which is of course delivery)

And further, even if the problem detected was nominally in their realm of responsibility, say the implementation approach or the estimated time to complete. Then there is no chance that said developer would be branded as incompetent having revealed this information?

It’s a good thing we have professionalism, because if any of those things were true people might be tempted to hide problems rather than face the possibility of criticism and ridicule.9

Not to mention the fact that a great many people just don’t like feeling incompetent. So they tend to hide the truth not just from others, but also from themselves. Oh right, professionalism totally fixes this too, I forgot.

So considering all of this, there would therefore be absolutely no need whatsoever to say, stop development every two weeks, on the regular, so that we could give feedback on what had been done to date, and then immediately act on that information? And there would also be no need to share a common definition of what it means to be done with something; because there is absolutely no chance that something might work on a developers laptop, and not at all once integrated with all the other changes and put into production. And that we showed you it now, because, well you were here, and we assumed that there would be no problems. Because we are, of course, professionals.

None of this is required obviously, because we don’t ever get angry with each other, not even passively and as a result people never want to hide their mistakes (because we’d also never decide to just stay back and fix them quietly) and because none of this ever happens, none of this is necessary.

The Horror of Harder

Because if you did do that, if you did stop to fix the issues when you found them, then that would impact your delivery schedule.

And that would be terrible. I mean, fixing mistakes slows down your delivery. (As does quality and testing, but that’s a story for another day)

Much better to simply raise a ticket. So when a stakeholder says “You better raise a ticket on that” you can professionally reply “I already have”. And then you will get a serious nod, so that you know that you have been sufficiently professional.

After all, a ticket is as good as a fix. Ask any user!

Raising a ticket allows the Developers to Continue On With Delivery and let some business proxy representative Showcase just how on schedule we are to anybody who doesn’t have anything better to do that afternoon.


Unless of course we interpret the “early” in “early and continuous” to meaning gathering feedback early and continuously?

And not “early” as in “earlier than your pessimistic original estimates you lazy bastards”

Even the delivery focussed “with a preference to the shorter timeframe” principle could also be interpreted to being about getting real world feedback on what we’ve built ASAP as much as it’s about Capital D Delivery.

“Delivery” has such a ring of finality to it. A ring of correctness. Which is the way we like it in Waterfall. A land where everything is perfect and there are no mistakes. Just disappointments and failures.

And ironically if you focus on delivery, you’re more likely to be predisposed to ignore feedback you’re getting from your production users (assuming it’s going to the delivery team at all and not to some BAU or maintenance function)

So putting stuff into actual production quickly and regularly is really just another way of gathering feedback, really really meaningful feedback, as to whether what we’re doing is working or not.

The concept of Early from this viewpoint means “in time for it to be easily and cheaply corrected“.

Time to make it Better.

Defining Working

One of the key characteristics of “Agile Delivery” is that it runs off The Engine of Acceptance Criteria. When I first tried XP as a practitioner, a User Story was a sharpie scrawl on an index card. Most of the User Stories I see today would probably need to be printed out on a roll of toilet paper there are so many details and acceptance criteria. Which is why I guess, these days, User Stories rarely dare to venture outside of their JIRA® branded fortress.  Where they are very safe indeed.

In this case, “working” can and usually is, defined as “meets all the acceptance criteria” (or in some case “provisionally meets” as there will of course be a giant test phase at the end of the Project after the “Agile Delivery” is over). Once said “stories” have met these pre-contracted and comprehensively documented criteria, then and only then is it considered safe to “demo” them, as we are now sure there will be no surprises. And surprises are of course awful. 10

But what if there was another way to define working? One that actually required people directly affected by the software to use to the software before they could make the determination? I dunno, in some kind of regularly schedule review?

If we did that, we could save a bit of time on all these acceptance criteria, sure we might still need a few, but instead we’d be tracking towards whether or not we’d done something useful, instead of merely what we had been told (or could justify having done).

But that sounds like it would slow down delivery! I can hear at least some of you cry.


The good news here is that there is a different kind of faster available to us, not of delivery, but of faster problem solving.

This is what it means to me, that Agile is faster.

It does however mean that we have to start measuring from a different point. Faster Delivery by definition only starts at the point that you’re declaring that you’re ready for “delivery”.

At best, Agile Delivery looks something like this:

We are timing how long it takes from the point we’ve defined and designed our solution to when it makes it into production. You might be overlapping some of those “phases” and I hope you are, but we’re still tracking the same two endpoints.

Sometimes thou, Agile Delivery does not include deployment. In some places, that belongs now not to Agile (apparently) but to some newer, younger, cooler thing called “Dev Ops”11 — and thus Agile Delivery has in these places been redefined to this:

Or God Help us, this:

Faster Problem Solving on the other hand is measured from two different end points. Two points that are not even on the above diagrams — because they sit directly before and somewhat after Define and Deploy in our above Waterfall Hybrid Agile examples. Something you might hear referred to in Lean Circles as Concept to Cash.

To navigate down this little stream will require a degree of iteration. The linear left to right arrow is, I apologise somewhat misleading, and merely represents the passage of time, and not linear, even progress.

But problem identification and value realisation are not typically seen as IT issues, that is the domain of The Business! If you define the project like that, then we’d end up with Business People and Developers working together daily, and what would that lead to!

A prominent head of contract negotiation at a major bank once declared it to me as total madness. And pointed out that collaborating with the enemy IT Department is considered in many organisations to be treason. Punishable by lack of career progression.


Solving problems creates value. There is nothing more valuable to a person, or an organisation, than solving a problem for them.

Everybody likes to talk a big game about “value” and as a result the term has become a little abused and ill defined. I’ve seen BA’s argue until they’re blue in the face that the requirements document that they just spent two years writing is VALUE. (Even thou 30% of the original users have now retired). Perhaps this is a legacy of the term “Value Add” (as in Value Added Reseller or VAR) — a world where simply doing extra things, was regarded as “increasing value”.

But my guess is that the problem with the term “value” is that it people take it personally. Deep down most people want their work to have value, so that they themselves feel valuable. If you’re a BA in the 21st century workplace, maybe you feel that you have to “declare value” at the point of writing your requirements, because the chances of you seeing them make it into production are terrifyingly slim12.

Which is why, for reasons of clarity and equanimity, I’m talking about Problem Solving. But if you’re a traditionalist, you can think of it as Value Creation if you like.

Either way, it’s a far bigger deal than just quicker delivery.

Makes us stronger

To me, the Working Software alluded to in the Manifesto has never meant software that merely compiles and runs. Software that can stay up for the 5 minutes required to “demo” it.

Frankly I’m not sure why anybody see it that way, but they do. I guess it’s easy. (See Harder)

To me, Software is only Working when it’s solving the problem that we originally hoped it would, or other problems that we didn’t even know we had, but are glad to have removed from our lives.

Software that is working for us.

Software like that does not live in isolation, but is part of a bigger thing. Part of a solution that makes us all individually stronger, capable now of achieving things we could never have done before without it13

Now you might end up with a result like that if you just focus on faster delivery.

But is that a risk you really want to take?

  1. This is of course only a problem if this was not what you intended to do. 
  2. Actually this is not the most extreme form, the most extreme form is “just some of the Software Developers on the days where it suits us” 
  3. By which I mean the coders, or programmers, or whatever else you want to call them. The whole concept of “developers” meaning everybody never really took off in any meaningful way and is at best confusing, so I think ideally we should give up on that one. 
  4. Regardless of colour. 
  5. Interestingly enough there is nothing that could even remotely be construed as providing or requiring speed in the Four Agile Values. 
  6. Although XP also had the concept of Velocity, it is, and always seems to have been, more closely associated with Scrum. Scrum thought leaders have certainly been the most active in promoting it. 
  7. And it’s slighter more attractive half sister from Florida — hyper productivity. 
  8. Said the Project Manager to the Pregnant Woman. 
  9. Unless being professional means never making mistakes in which case… 
  10. Unless of course you’re interested in gathering information cheaply and effectively, in which case they’re awesome. See my talk “Adventures in Advanced Product Ownership” for more details, or take an Information Theory course at a nearby University. There are probably other options, but those are the best two I can think of at short notice. 
  11. Now some readers might be under the impression that Dev Ops has something to do with Developers getting involved in deployments and operations! But according to some very Senior and very sure that they are correct Managers I have met, a “Dev Op” is a new kind of person in a new kind of team and the developers better damn well keep their nose out of it. 
  12. There are at least two factors at work here in my personal experience. I spent a few years consulting to one organisation which cancelled projects with an alarming regularity. Usually after they had been running for several years. Additionally if you work in a place where almost all projects are large, then depending on the industry it’s not unlikely that the lifespan of the project far exceeds the tenure of the majority of the people working on it. 
  13. Even if the only thing it does for us is give us back extra hours in our days, which might be the most valuable gift of all. 

A time box is both a limit and a commitment

Time Boxing is an interesting technique that’s found at all sorts of sizes in all sorts of places. My favourite time boxes probably belong to the Pomodoro Technique.

The Pomodoro Technique is not only a great practice in itself, it’s also a great way to understand what a time box is, and explain it to others.

If you’re not familiar with the Pomodoro Technique, the basics of it are insanely simple:1

  1. Pick a thing to do
  2. Do that thing and only that thing for the next 25 minutes
  3. Stop and take a five minute break
  4. Decide whether to continue to work on your original thing for another 25 minutes, or switch to a new thing and do THAT for 25 minutes2
  5. Repeat

You get the idea.

This also beautifully illustrates the dual nature of the time box.

On the one hand a time box is a commitment to:

  1. Focus exclusively on just one thing
  2. To maintain that focus for a full 25 minutes3

It’s the perfect antidote to today’s attention scattered world. You’re not committing to finishing something, you’re just committing to working on it and only it for the next 25 minutes. And if you’re not willing to commit to spending 25 minutes, then perhaps it’s not that important.

On the other hand a time box is also a limit

So whilst you have to work on your thing for at least 25 minutes, you can also only work on your thing for a maximum of 25 minutes.4

In my experience, this actually makes picking what to work on a lot easier. Knowing that the maximum investment is going to be limited to 25 minutes, you can worry less about ensuring that you’re working on the absolutely positively highest value thing. The time box caps the amount of time you can “waste”5 before you realise you should be doing something else.6

What’s brilliant about this system, is that it exploits the fact that humans best understand the following three things not by thinking about them, but by doing them:

  1. How important something is
  2. What’s important about it
  3. How long it’s really likely to take

So through this process, we not only Get Stuff Done, but also learn to make better, more informed decisions (in shorter amounts of time).

The commitment aspect helps us to get more done.7

The limiting aspect helps us to get the right things done, the right way at the right time. Thus maximising the return we get on our overall investment in time.

  1. Although like so many things of this nature, it’s very easy to make it more comprehensive if that works for you. 
  2. Now that I’ve written it out, it looks a lot like Lean Coffee, which in 2019 more people may be familiar with. The Pomodoro Technique, pre-dates Lean Coffee by a good ten years (at least) — and whilst it was originally designed as a personally productivity tool I have memories of running meetings using it. I remember running a planning day in 2007 using the Pomodoro technique which was both productive and exhausting. 
  3. Actually, you can focus for any length of time, 25 minutes is just the most popular, possibly because you can fit both the work and the break into a half hour, which makes them easy to schedule and plan with. It’s also just a good length of time for most personal tasks. 
  4. This can for some people actually be the harder thing to do. 
  5. I personally don’t think time is wasted if you discover what your real priorities are. I defy most people to do this well through 25 minutes of inaction. 
  6. Whilst at the same time allowing you to progress something that was important enough for you to start
  7. It’s a WIP limiting technique if you think about it, except it’s not using stickies, it’s using time. 

Grooming will tear us apart

Grooming, or Product Backlog Refinement if you prefer, has always been a troublesome, not to mention kinda-boring concept in Scrum.

And in recent years it’s somehow turned into a meeting, which it seems most people hate, but do anything, because apparently they were told to. Apparently unless you don’t do something in a meeting then it’s not Agile (how ironic).

Having practiced Scrum for years without such a meeting I found myself wondering what people were doing in it. Turns out, at least in the cases I observed, that it seems to be mostly a combination of Planning Poker™, followed by demands for more detailed acceptance criteria and then arguing. Whatever floats your boat I guess, but it wasn’t my idea of a good time.

This “Grooming Thing” was also creating some kind of weird division, in what I’d always assumed was a Cross Functional Team. Suddenly the world was divided into The People Who Did The Work and The People Who Prepared the Work for The Other People To Do.

Weirdly, it was only The People Who Did The Work whose time seemed to matter, and was thus tracked and reported on in great detail, the preparation people were apparently free.

It was all beginning to sound like Waterfall, but with stand-ups and some other new thing called JIRA® (very useful for tracking how The People Who Do The Work are spending their days)

I however was keen to get back to the collaboration and cross-functional team stuff. I had good memories, it was both fun and effective. Neat!

But damn, Grooming is tearing us apart. How could we get the band back together?

What we were missing was a A Bright Line for Grooming. A way of describing Grooming that didn’t involved creating Groomers and Groomees.

And then it hit me, it’s so simple.

Grooming is any work you do that results only in a change to the Product Backlog.

Oh, you’re an idiot, I hear you say, we already knew that, that’s not new.

But hear me out. Because a simple example might make all the difference in understanding what I’m talking about.

Imagine a team that starts a story, and for whatever reason (it really doesn’t matter) the story is not finished at the end of the Sprint. We asked for a feature, a deliverable, but we don’t have that. What we have instead is increased WIP. No cause for panic. It happens.

What are the relevant Scrum Rules in this situation?

  1. Don’t demo the feature (mostly because it doesn’t exist)1
  2. Don’t put the feature into production (again, because it doesn’t exist)2
  3. Re-estimate the story to completion and return it to the Product Backlog

So what has the team done exactly? What’s their output?

A New Estimate.

What do we call it when the team estimates a Product Backlog Item?


The Team just spent the entire Sprint on grooming that story.

Wait a minute I again hear you cry (I really should get that web cam fixed)


That’s exactly my point, Grooming is an outcome not an activity. And above all Grooming is Work. It consumes both time and people3

Sometimes it’s obvious that we’re grooming, but other times we don’t know that we are until after the fact.

In my example, the only difference is that in this case the Team’s Estimate was based on coding, building and testing rather than (say) Planning Poker™.4

I don’t have my feature, but I do have an updated backlog, so you, my dear team spent the entire sprint grooming. ALL OF YOU.

What’s even more fun is that now we can finally make better sense of the Scrum Guide admonition that “A Team should spend no more than 10% of their capacity on Product Backlog Grooming”

It we take this rule into the my context for grooming it’s just saying “Hey Team! Try and spend 90% of your time on finishing things, not just starting or progressing things”5

To me that’s a far more useful interpretation than “Let’s disrupt the Sprint to ‘play’ Planning Poker® for 2 hours every Thursday”

And the best part? There is no longer an us and a them. There’s just us, because you never know when you’ll find yourself grooming.

  1. But that certainly doesn’t stop people from trying 
  2. If you’ve not finished a story, but you do have a feature you could demo and put it in production then you probably have another problem. You’ve definitely misunderstood a few things. 
  3. and souls if you do it the boring way 
  4. So yes, we’re also closer to finishing delivery of said feature. But the same is true of “other work” that many people relegate to the realm of Grooming, such as designing the User Interface”. It’s no different. Defining the end of Grooming as the start of coding is not particularly useful in my personal opinion. In fact I’d argue that if you’re doing anything to your Backlog Items that doesn’t bring them closer to final delivery, then you might want to think about why you’re doing those things! 
  5. A side effect of this is that you’ll need to start making things smaller if you want to achieve this goal. 

Scrum it like a toddler

Most people (reading this blog at least) are familiar with the format of the Daily Scrum, where everybody on The Team comes up with an answer to the following three questions:

  1. What did I do yesterday?
  2. What am I planning on doing today?
  3. What impediments do I see?

But what a lot of people don’t seem to realise is that this is pretty much all there is to Scrum.

Scrum is pretty much just these same three questions repeated over and over and over again.

Don’t believe me?

At the Sprint Review the entire Team answers the question: “What did we accomplish last Sprint?”

And at Sprint Planning the Team again answers the question: “What are we planning on doing in the next Sprint?”

And finally at the Sprint Retrospective we are ask and answer the question “What impediments do we have? (and what are we going to do about them)”1

And of course the very same pattern can and should continue to repeat at the Release Level if you have one.

It’s far too easy to get caught up in the mechanics of Scrum — at which point it starts looking like a laundry list of artefacts to create, time boxes to keep and meetings to attend – but IMO that’s overcomplicating it.

All you have to do is connect with your inner 3 year old and keep asking (and answering) the same three questions over and over and over again.

“Just keep Scrumming, Just keep Scrumming”

  1. Careful readers will notice that the meetings could be considered to be out of order. That’s because the Daily Scrum Questions IMHO are out of order too! It’s far more effective to discuss what has been done and what impediments have been uncovered before figuring out what you’re going to do next. 

Not Original Artists

When I was in school, there existed a very popular packaging of music which I remember as “Hits Picks 100!” – basically these were compilations of all the songs that had been “on the charts” for the last few months. I guess in many ways it was the precursor of Napster – teenagers wanting to consume giant bags of unrelated popular music instead of albums from a single artist.

Anyway, there was sometimes a catch. Occasionally a very sheepish looking individual would arrive at school the next day, having spent all their hard earned cash on one of these massive compilation albums and when questioned about how it was1 – the reply was “Not Original Artists”

I don’t know the specifics exactly, but to keep costs down to the bargain basement prices that have ever attracted the younger purchaser, the publishers of said massive compilations would not licence the original recordings, but instead have somebody else effectively “cover” the song for the album (with varying degrees of success I might add)

There were of course legitimate compilations made, but these tended to attract higher prices. The two products looked the same, and so the average consumer assumed that they were the same.

Now of course to protect themselves legally, the advertising and packaging had to contain somewhere the dreaded “Not Original Artists” labelling – but nobody ever said how big the font had to be…

Inspired by the movie…

A few years later, a similar thing started to happen with Movie Soundtracks, which were equally as popular at the time as the pop compilations were a few years early. I’m not talking so much about Epic Original Scores such as Star Wars here, but rather more pop culture outings such as the soundtrack to Bas Lurman’s Romeo and Juliet.

These again were compilations, but this time around they were based around a curated set of songs chosen as the background for a particular movie.

Now these albums were created from licensed music and they were also combined with the licensed movie property. (No wonder they were popular!)

Hoards of people descended on music stores to buy these soundtracks and reconnect with their favourite movie.

In some ways, the movies became ads for the CDs. I think this was especially “a thing” in the days when you had to wait a year or more to own the movie yourself or even rent it from a video store. The music however you could get right away.2

But the popularity of this format once again drove marketers to exploit this demand by creating something that looked like the popular thing but wasn’t actually the popular thing.3

I remember being given an apparent movie soundtrack by a friend, putting it on to play and then halfway through thinking “I’ve seen this movie twice, but I don’t remember any of this”

So I went back to see the movie a third time, then went home and listened to the soundtrack again – to once again be baffled. Until I inspected the case a little more closely and found the phrase “Inspired by the movie…”

Inspired by Scrum

So how does this relate to process?

I think there is a lot of “Inspired by Scrum” out there that people are calling Scrum.

Who knows the full set of reasons why people do this4, sometimes it might be because people never saw the (Scrum) movie and don’t know that what they’re doing isn’t really Scrum.

Sometimes it might be just like the Hits Picks CDs – Scrum looked too hard and too expensive, so let’s do a cover version instead! Hey, it looks right doesn’t it?

Or maybe Scrum just wasn’t plain right for you and you’ve come up with something a lot better. And for some reason you’ve decided to call it Scrum anyway.

But for whatever the reason, it’s not Scrum, so please don’t call it Scrum.

Why does it matter what I call my process?

I think it matters for a few reasons, but here is the main one:

There are no end of people and blog posts out there who say that Scrum is awful and should perhaps “die in a fire” and then they describe the process that they were following and yes, it’s usually awful, but it’s also never Scrum.

Just once I would like to hear or read an “I hate Scrum” rant that actually describes Scrum.

But this distracts from the real issue – and the real problem is that you can silence that argument with “Oh, but what you were doing wasn’t Scrum”

And that’s the problem.

Because that answer presupposes that Scrum was the right thing for these people to do.

That is to say that doing Scrum correctly would have solved all their problems. Now maybe it would have, but that’s beside the point5. You can no longer have a sensible discussion about it because we’ve placed all the blame on Scrum.6

You can’t judge a process if you’re not following the process.

So what should we call our process?

Scrum Butt?

Scrum Butt was a popular term, I dunno, maybe 5-6 years ago? If you don’t remember it, the concept came from people saying “Oh we’re doing Scrum, but we don’t deliver working software at the end of each Sprint”

As cruel as it sounds, it was useful in the beginning. Because the people who genuinely wanted and needed Scrum often skipped over the active ingredients of the process and thus didn’t get the benefits. And thus “Scrum Butt” was originally a playful way of saying “Yes, I’m totally on this diet, except I’m still eating as much as I want”

But at some point in time, it suddenly became “NOT OK” to say Scrum Butt – I remember one guy at an agile conference basically losing his mind at a panel who just told him that he was doing “Scrum Butt” because they were being abusive and not helpful (Frankly, they both had a point, what he was doing was not remotely Scrum, but telling him to simply do Scrum properly wasn’t very helpful either, because that simply wasn’t feasible for him. He knew what to do, it was his company that would not permit it)

So in these days of “little ‘a’ agile” saying Scrum Butt might seem harsh, but it was at least clear.


So in order to salve egos and increase sales we got Scrum-like. This to me is the “Not Original Artists” of process naming.

The problem with the phrase “Scrum-like” is that it begs the question “In what way?” – because 9 times out of 10 the primary way in which the not-Scrum process is “like” Scrum is in the way it looks.

Inspiration over Like-ness

I think it’s more accurate, and dare I say transparent to say that your process is “Inspired by Scrum” rather than “Scrum-like”

The “Inspired By” CD’s were true originals – both artists and content. Sure they weren’t in the actual movie, but a lot of the time that didn’t matter, they were still good songs. (most of the time)

And some people even preferred the “Inspired by” CD’s to the Sound Track CD’s and that was OK too.

So if you’ve been inspired by Scrum, in whatever way then own that. Don’t feel compelled to pretend you’re doing something you’re not. Don’t wimp out and say you’re “Scrum-like”7own your originality.

Claim inspiration and invention, not mimicry.

And then we can leave Scrum to mean, well Scrum.

  1. Which was code for “Can I get a copy please?”. Napster didn’t create the concept of “sharing” music it just scaled it. 
  2. And who doesn’t love a fast feedback cycle!? 
  3. In those days there was a less torrential stream of movie production. 
  4. Scrum is of course also not unique in this regard. 
  5. The is a secondary problem here which is we never get a decent chance to talk about the problems with Scrum itself – because we’re too busy telling people what they’re doing is not Scrum. 
  6. For what it’s worth, I’ve seen the same thing happen to kanban. 
  7. The process equivalent of using a really small font.