Don’t Waste Money On Development Until You Know It’s Worth It

Let’s start by facing up to the largest inconvenient truth of technology: it is expensive. It’s expensive in ways you never dream possible until you get involved in a technical project. Tech projects can eat cash like a shredding machine jammed in “hide the evidence” mode. Tech projects are probably second only to parenting in terms of their ability to generate hidden monetary black holes. You have been warned. On both counts.

That’s not to say that you shouldn’t undertake your technical project (or indeed start a family); far from it. It’s just that you’d probably benefit from inserting another phase early on. By which I mean: in many cases people expect to go straight from Inspired Idea to Awesome Online Service.

Hold your horses.

Would you benefit from a discovery phase? Probably. It’s admittedly a less glamorous and less exciting phase than the others, but it could turn out to be the one which saves you the most money. And money saved at this stage equals less of a dent in your P&L which means less of a reliance on investment early on which in turn leads to increased equity for you in your own idea.

Here are some questions you ought to be asking during a discovery phase:

  • Does your idea work?
  • Could it be improved?
  • Could it be slimmed down?
  • Has it already been done?

If you are the entrepreneur here, chances are that you are reeling a bit at some of those suggestions. They may even feel borderline insulting. If that’s the case then you should definitely stop and think before committing to development: you’re too emotionally attached to the idea and you need to separate your great plan from your (justifiably) sizeable ego and this “exploration” phase is the best way to do that.

Some processes which you ought to consider are:

  • Collecting opinion through canvassing (if your ideal is retail-related, you could pay three or four local students £10 an hour to stand outside shops one afternoon for 3 hours, armed with clipboards and insightful questions. Student labour for an afternoon: £120. Value of insight: priceless)
  • Collecting opinion through online surveys (there are numerous free, flexible, online survey systems available right now. Spending an hour or two crafting intelligent questions and inviting friends and friends-of-friends to complete the survey costs nothing and you will almost certainly learn something of value)
  • Paid experimental ads (think up what you imagine to be your strongest selling points and most searchable traits and invest a few hundred pounds learning whether or not the internet at large sees things the same way you do)
  • Initiate a product steering group (friends, business partners, LinkedIn connections – invite these people to a breakfast meeting with free breakfast – these are cheaper than free lunches and less disruptive to invitees’ working days. Also people are likely to drink coffee and say what you like about the bean, it certainly gets ideas flowing)

Learn from the traditional Product Development community. They invest a lot of time and effort in “keeping things human” way before even a prototype is created. Conversation, surveying, reflection and a few giveaway coffee / croissant combos are way cheaper than even mocking up a clickable prototype.

The services of Drop-In CTO are geared towards maximising the effectiveness of your business idea. This involves verifying its appeal, guiding you through this exploratory phase, knowing which questions to ask and knowing which crucial pieces of information to capture from that discovery phase. All of this will help you to hold off on investment in actual coding until the last possible point in time and until a point where you know your cash will be well-spent. Software is expensive to build and very expensive to change. Do all the learning you possibly can upfront first, before even a single line of code is written.

Email to find out how.


When Sprints Go Bad

From time to time even the most sleek and accomplished product team can hit one of those sprints. Maybe it could have been avoided, maybe it couldn’t. In general, the team usually does well, the project is in good shape overall, and so this one bad sprint is nothing to worry about. We hope.

Then there are the projects in which the good sprints are the rare ones. That’s if any sprint is ever good. What’s gone wrong? The devs are all pretty sharp; the product idea is awesome; you’ve installed god knows how many gaming gimmicks and coffee machines; you’ve even switched to flexible hours and offered free stuff for great performance and still no sprint is successful.

What’s going on?

The signs of a failing sprint pattern are pretty easy to spot: There is usually a chunk of work hanging over unfinished (or even unstarted) at the end of each sprint, and there is often a large fluctuation in the number of points achieved from sprint to sprint. These trackables should already be shouting at you from your project management system.

Within the team there may be other tell-tale signs which include: low developer morale; highly stressed product owners; uncomfortably tense planning sessions; terrifyingly tense pointing sessions; an explosion of Blame Culture in what was supposed to be the most chilled company ever.

All of these factors make work very unpleasant for everybody. If you let it roll on like this for long enough, all the people good enough to secure work elsewhere will be off and you’ll be left with the also-rans who are OK within a healthy team but left to themselves clearly won’t be the workforce that propels your genius enterprise into the stratosphere, commercially speaking.

Here are some possible reasons why each two-week iteration is such a complete pain in the rump:

  • Stories are routinely too large, or contain too much implicit complexity (formation of clear stories is actually one of the hardest skills in Agile development and one in which you’d be wise to invest a lot of effort in order to see improvement)
  • Stories are not appropriately focused on the value to the user (it’s so easy to make this mistake – all your stories must must must be focused purely on the user’s needs, otherwise how will you plan the behaviours properly?)
  • Stories have no user (warning signs: “As CTO I want to….” / “As I want to…” Stop this now. Unless you actually like setting fire to cash unnecessarily.)
  • The pointing session was too technical (often there is a tendency to focus purely on the technical implementation of the perceived story, rather than grilling the story author about her vision for the finished feature)
  • The sprint planning or story planning session focuses way too much on technical implementation rather than what the new feature does (you must make story planning purely about what the feature does and how the user might expect it to work. You’ve got the Product Owner or Story Author there – don’t waste their time discussing technical details: engage them and their specialist knowledge of the customer)
  • The code base is volatile and change often brings bugs and breakages (put simply, you clearly need to improve testing coverage and implement strict automated Continuous Integration. Now.)
  • QA is a bottleneck and stories which are in theory “finished” still fail to make it across the line (quite likely to be due to a heavy amount of manual testing for each change – ditch that “click through” approach and automate, automate, automate!)

Drop-In CTO can help you to identify these problems and to work with the your stakeholders and team members to eliminate them forever.

Email to find out how.

How to Improve your Pointing using The Pointing Mantra

Improve Your Pointing

Unless you are spectacularly lucky, your pointing process needs help. Recently in our team, we developed The Pointing Mantra to help soup up our pointing a bit. Using this we have been able to:

  • Double the number of stories we can point in any one session
  • Remove virtually all confusion and “surprise” from stories as they move through the lifecycle

This article will describe why pointing needs to completely optimised, and will show you the steps we take at every pointing session to make sure we get as close to “completely optimised” as possible.

Why? Because pointing REALLY matters

Even if your stories came from a workshop (which really they should have done) then pointing is the first time everyone really gets their thinking caps on. If your stories didn’t come from a workshop then this will be the first time that the dev team and the Product Owner have looked at the story together.

Pointing is the last time the story can be altered and/or split up and because it is the story which is the primary unit of work in Agile, and because it is the story which represents everyone’s perception of the work to be done, then the story needs to be as clear, well-formed and unambiguous as possible.

The story is the most crucial component of the Agile process. The difference between a stream of well-formed stories and a stream of ticking time bombs is pretty subtle and not always obvious to most people at first glance. But worry not! The Pointing Mantra is on hand to make this process far more smooth and more automatic than you thought possible.

The Mantra is included in full at the end of this post, but first here is is, in breakdown, with an explanation of each stage.

For the purposes of this exercise, we will work with a real-life story from a project I am currently involved in. Here’s the original story content:

ORIGINAL STORY: As an employee, I want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown, so that I can see clearly at a glance in a single page everything I need to manage my holidays.

Don’t worry too much about taking that all on board – we will break it down in the coming sections. Just read it and note in your mind how the story “feels” when you start thinking about it.

The Four Steps of the Mantra

1. “Storify” the Story

This is the first step and is absolutely crucial to get right. Pride needs to go out the window at this early stage. Whoever wrote the story is going to have to face the fact that, until they are very experienced, they probably won’t be getting it right first time. A great Product Owner is one who can express the needs of their users very clearly but leave their emotion and pride out of it. Not easy, but it needs to happen.

So, at the pointing session, the Product Owner and the dev team should ask themselves this question first:

Who’s the Actor?

Firstly – the ACTOR. Who is the ACTOR? You need to picture a little model dude, a bit like… this guy



You have to be able to picture this actor and know how they move, how they talk, how they tick. This is a direct link to the User Profiles you would talk about at a Story Workshop. When it comes to the story, these ladies and gentlemen are your actors. They are embodied in the story text within the “As a …” clause. Getting the actor right is crucial before the next step.

What’s in their Speech Bubble? Can you imagine THEM saying it?

Now, picture a little speech bubble coming out their mouth. In that speech bubble are the words “I really want to….” followed by whatever the actor wants. It has to be – and this is the real litmus test – something you can imagine the actor saying out loud in their own language (or something that you can imagine them thinking to themselves in the event that you are dealing with actors who do not actually speak IRL).

Start by just lifting the “I want to…” clause straight off the story card, and prefix it with “I really want to..”

Here is the “I want to” phrase from our original example story, with “I really want to” added at the front.

Version 1: I really want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown

I cannot actually imagine a regular employee saying this. By prefixing it with the pseudo-childish “I really want to” we can easily expose those stories which are subtly disguised specs and, of course, specs are BAD.

Closing your eyes and picturing the little actor guy in your head, you may get something like this instead:

Version 2: I really want to know how much more holiday I have left to book in any given year

Once you’ve got this straight, there’s your “I want to” story clause, which you can edit back into your story card. You may have already spotted a potential story split already in that second version – we will talk about that later. The important thing to note here though is that we have captured the extra scope of the first version (namely the varying years idea) in that second version, but with less spec-like detail.

Ask the actor WHY

Getting a clear answer from your imaginary actor will help you in two really important ways. First, it will enable you to prioritise the story better, and secondly it will make clear to you the nuances of this story which will elevate it from an acceptable solution to a GREAT solution.

What’s important is that we give them what they want, not a description of the system which behaves in a certain way to give them what they want.

Here’s the “so that” clause from the original story:

“…so that I can see clearly at a glance in a single page everything I need to manage my holidays”

Sounds OK, right? Got value, right? Well, yes and no. While there is undeniable value in (a) being able to see and (b) being able “to see in a single page everything blah”, I don’t think it’s what’s motivating the actor to speak their line. So go ahead, ask the little guy in your head: “but WHY do you want this, fella?”. In our real life work with this story, we did that and we got the following answer:

“…so that I can plan my holidays efficiently and with minimum fuss”

Now, that is a country mile away from “seeing at a glance blah”. These users will be planning holidays, organising personal time with the permission of their employer. Just pause for a second and think of the nuances of that second picture. You can really help them to get their vacation all sorted and organised if you get this screen right. Planning holidays and trying to synchronise a booking with time off work is pretty stressful as it is, and we can really help them here. This is how you move a story from being an acceptable solution to a GREAT solution.

Once you’ve got this piece of the puzzle, edit that back into the original story as well.

The Storified Story

So, here’s our newly-storified story: 

“As an employee, I want to know how much more holiday I have left to book in any given year, so that I can plan my holidays efficiently and with minimum fuss”.

It’s already looking better. Now onto step number two.

2. Can we split this story? Then split it.

Not “should we?” or “are we allowed to?” or “is it OK to?”. Nope. “CAN we split it?” It is a fact that smaller stories are easier to manage and leave more space in their planning and execution (and, as discussed above) for the subtle nuances to creep in which make the difference between an adequate feature and a great feature.

Now, spin back a sec to the previous section – “Storify the Story” – and, in particular, the idea of the speech bubble. Let’s look again at those 2 versions from above, firstly the version we discarded…

Speech Bubble Version 1: I really want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown

Can you split version 1? I don’t know. Give it a go for a second. Can you? Maybe. I don’t know. It makes my head hurt. A pointing session with several of these in is going to be a pretty shitty start to the day.

But look! With version 2 it’s simple:

Speech Bubble Version 2: I really want to know how much more holiday I have left to book in any given year

Don’t forget: we are looking to split the story. We WANT to split the story. So, with that in mind, this second version sounds downright unnatural with that “in any given year” on the end. It almost belongs in parentheses to be honest. Forcing your story’s “I want to” clause into the language of the actor has forced this optional complexity to the surface. So, yes! We can split it, and split it we shall.

This gives us 2 stories for the same actor, each with its own speech bubble.

Story 1 Speech Bubble: I really want to know how much more holiday I have left to book this year

Story 2 Speech Bubble: I really want to know how much holiday I can book in future years

We created that second bubble by lancing that ugly “in any given year” off the end there. You will note here that the logical third speech bubble – “I really want to know how much holiday I can book in past years” – isn’t mentioned because, of course, it makes very little sense. Again, through simplifying our language we have exposed needless scope and eliminated it. If we had ever played the story in its original format, I can imagine that dev time would have gone into getting a previous/future years navigator going, some of which would have been a total waste of time.

Of course, those 2 stories should be pointed separately, and the second one needs to go back through this whole process again, starting at the first step. For now, we will press on with the first story alone.

Right, splitting is done. On to the next step…

3. Does the story have a definite,  SINGLE ENDING that an ACTOR can see (and TEST for)?

Tests. Remember? We will be expressing everything in terms of Behaviour-Driven Scenarios, when it comes to our sprint planning session. So, each story needs to have an end-point which we can easily and unambiguously test for.

With our example story, this is pretty easy – the actor (the employee) will see an accurate summary of remaining holiday on the screen. But this step isn’t always so easy – however you must ensure this is the case. This is even more specific than the usual insistence that there be “business value”. That’s such a vague term and very, very subjective. So instead of this mythical “business value”, let’s remember that we are implementing experiences rather than implementing systems, and focus on each story having an end-point which an ACTOR can SEE.

  • Beware false end points such as “we can see the system is now configured to do X” – this is merely a spec in disguise (and not a terribly effective disguise, either)
  • Beware the terrible end-point “..and we can see the record in the database”. Unless your story is “as an admin I want to be able to hand-edit data” then this is not an endpoint. Worse, it is the opposite of Agile – your story planning will require that you define the data model spec as part of the planning. Eurgh.

Nope, you need an endpoint that an actor can see. It might not be the same actor, but it needs to be a human, a recognised user. You may even need to put in a super-lite screen to handle this. (For example, a story about “requesting holiday” will probably necessitate that you put in a lite, dumb “all holiday requests waiting on the system” screen to provide an endpoint – if so, add it).

4. OK. Point!

Now – and ONLY now – go through your “democratic pointing process” – whether you use fingers in the air, IM votes, dopey playing cards or whatever. Those digits or chat windows or risible upsell items should have remained unused until now.

But before we point, let’s look at the stories we are now pointing and compare them to the original. Here’s the original story:

ORIGINAL STORY: As an employee, I want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown, so that I can see clearly at a glance in a single page everything I need to manage my holidays.

Now, just pause for a sec and imagine actually trying to point that. Don’t spend long, just… probe the thought. Poke it with your finger. Feel the resistance. OK. Here are our two, new, storified, split and end-pointed stories (with the component sections assembled back into normal story format):

NEW STORY 1: As an employee, I want to know how much more holiday I have left to book this year so that I can plan my year’s holidays efficiently and with minimum fuss

NEW STORY 2: As an employee, I want to know how much more holiday I have left to book in future years so that I can plan long-term holidays efficiently and with minimum fuss

Now imagine putting points on those. Every team’s points scale is different, but I reckon they’re both small and the second is probably about half the size of the first. And how did that pointing thought process feel? Pretty easy. Repeat that for 6 or 7 other stories in a pointing session and you’ve still got the will to live and the energy to get stuck into your dev work for the day.

And – as you may have noticed – straight away those stories are dead easy to prioritise. New Story 1 is clearly a “Must Have” – it’s a high-volume, high-personal-value, used-daily feature. Bosh, straight to the top of the pile. The second story, although arguably important (and of increasing importance when the current year is getting old) is clearly not as high-priority as the first. No argument.

What You Got from The Mantra

The whole point of having this as a mantra is that it is easy to follow, easy to remember, effortless to work with. By following those 4 simple steps, you got yourself:

  • A much clearer story content
  • Everybody aligned on the nature and value of the experience
  • Obvious split-points appearing before your eyes
  • Clear priority differences appearing before your eyes
  • A pointing process which didn’t hurt
  • Stories which will have clearly testable end-points and therefore clear, unambiguous development goals (thus reducing the problem of human interpretation – and Software’s About People, right?)
  • Stories which will be GREAT solutions rather than adequate solutions

Finally… Thanks for reading. Here’s the Mantra, on its own. Feel free to copy n paste to a more convenient location for your team’s reference at every pointing session. We open this document at literally every pointing session and not only have we doubled the number of stories we can point in any one session, we have virtually no confusion creeping in at the later stages of the story lifecycle.

The Pointing Mantra


1. Storify the Story

  • Who is the ACTOR? [Get the “as a….” clause]

  • Do we KNOW the actor? [is the user profile in place?]

  • What’s in their SPEECH BUBBLE? “I really want to…” Is it telling us THE WHOLE STORY?

  • Can you imagine them saying this for real? – i.e. have you used the actor’s OWN LANGUAGE? [if so, there’s your “I want to” clause]

  • Ask the actor “WHY“? [to get the “so that” clause]

2. Can we split this story?


3. Does the story have a definite,  SINGLE ENDING that an ACTOR can see (and TEST for)?

  • could be the same actor, could be someone else). If no, may need to ADD TO the story.


How to do Sprint Planning

It’s the top of the sprint. The backlog is prepped. The stories are all pointed. Everybody is raring to go.

Let’s plan!

Asleep Meeting

Oh my. Planning sessions are hard. They’re hard for all sorts of reasons, generally bad ones. Here are some characteristic antipatterns from planning sessions which I have both attended and run in the past:

  • They are way too long – like, spirit-crushingly long – I actually almost resigned at the end of one planning session, so depressing had it been
  • The highly verbal minority drive the thing – the same few people push the agenda each fortnight
  • It is very draining doing deep technical dives on a variety of subjects in quick succession
  • People revert to classroom mode (giggling, chattering, falling asleep)
  • The meeting has little value for non-developers – the Product Owner / Customer and even QA people are left somewhat out in the cold as various forms of technical noodling unfold

It’s pretty clear that Sprint Planning has a very great capacity for becoming the low point of the sprint cycle. This is a massive shame since it is at the very start of the sprint!

So, when I took over as Head of Tech at my most recent firm, we opted for a different approach. We use the Sprint Planning session for two purposes, neither of which are tech planning:

Firstly, we use it to confirm with the Customer which stories are in the sprint. This is a very brief process since (a) our Product Owner is organised and has prioritised in advance and (b) we don’t waste time bartering menainglessly over Points Commitment since we use the points bagged in the last sprint as the Commitment in this one.

Secondly, we use the session to write the Customer Test Scenarios for the top priority stories. We do not go any deeper than this. We aim to list the scenarios, and fatten those scenarios up with the pre-conditions (@given steps), the test actions (@when steps) and the post-conditions (@then steps) [We are using the Python Behave behavioural testing language – see here for details of how]

We also don’t do this to death. We do this for just enough stories to fill the next few days. We then do “just in time” planning during the rest of the sprint. This keeps the stories fresh, keeps the planning sessions as close to development time as possible, and reduces the exhaustion factor in the Sprint Planning session itself.

Some of the benefits of this approach will be immediately apparent to you, benefits such as:

  • Keeps everyone involved
  • Avoids tedious technical posturing / competition
  • Keeps the focus on testing 

However there are other, more subtle benefits which fall out of this which really help with the biggest problem factors in development: human interpretation and implicit assumptions. To see what I mean, first consider these two versions of events for the same story.

Story: “As a site user I want to be able to search for employees by first name and last name so that I can locate people’s data without having to know their employee number”

Version 1 – Sprint Planning focused solely on technical planning

Takeaways from session:

  • Add indices to those 2 columns
  • New URL / view setup in Employees app
  • Handle mid-word searching (e.g. searching for ‘mit’ returns all the Smiths)
  • Show number of returned results on the screen
  • QA to confirm tests with Customer tomorrow

Sounds pretty sorted, right? I can see this story going well. Or rather, I can see it going well until I compare it with the takeaways from the “Customer Scenario Writing” style of Planning Session:

Version 2 – Sprint Planning focused solely on Customer Scenarios

Scenario: I can search on any part of a name

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘mit’ in the search field and hit enter
  • Then I see only John Smith and Joan Smith
  • And I see “2 employees found”

Scenario: I can enter more than one term and if I do, each result should contain all of the terms:

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘oh mit’ in the search field and hit enter
  • Then I see only John Smith
  • And I see “1 employee found”

Scenario: End spaces and spaces between words should be stripped out

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘  oh   mit    ‘ in the search field and hit enter
  • Then I see only John Smith

Scenario: Clearing the search field resets the search results

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘  oh   mit    ‘ in the search field and hit enter
  • And I click the ‘X’ in the search field
  • Then I see John Smith, Priya Patel and Joan Smith
  • And I do not see “employee found” or “employees found”

Scenario: If no records match then I want to see a polite message and an empty result set

  • Given we have John Smith
  • When I enter ‘foo’ in the search field and hit enter
  • Then I see ‘No employees match your search’
  • And I do not see any employees
  • And I do not see “employee found” or “employees found”

I bet the team from the first version of events missed at least one of those. I also guarantee that everyone who was at this second session is in no doubt as to how the feature works. Developers, QA people, even the Customer accepting it – especially the Customer accepting it: At least 2 of those points (the second and the fourth) are things which classically a Customer would not think up until the first demo, which in theory is a bit late in the day to be rethinking some of the ORM/database layers. Writing these Scenarios as a group means that we have already bridged the human gap for this particular story, and we haven’t written a line of code yet! We have also ensured a much more ‘luxurious’ user experience and avoided that ‘unfinished’ feeling which many new releases often have.

A further benefit of this approach is that these style of scenarios lend themselves very well to doing the actual development in proper, bona fide, Kent-Beck-Approved Test Driven Development. Your team truly is writing software from the outside in, which means the tests are written from the outside in. Compare that with the classic approach of writing from the database outwards: Talk of database indices, manager methods, boolean operands, blah, nowhere to be seen yet. And rightly so! We are Agile; We deliver working features, not code which we then bend to provide those features. Even better, our Customer Tests and our Dev Tests describe the thing we are building – a massive help when we come to refactor / alter things in the future. Imagine the tests which fall out of these scenarios naturally, then compare them with the sorts of mechanical, restricting unit tests you get supporting dev tasks like “add 2 indices”. Our tests here will be much more organic and useful to future coders.

Finally, it also means that you only write what’s necessary. There’s no scope here for some time-wasting, generic SuperBooleanMultiColumnSearch object, written “in case we need it later”. Nope, you’re just delivering something that hits those 5 scenarios. Job done, onto the next thing. Agile.

Intro: Putting It All Together

At the time of writing, it’s eleven years since the signing of the Manifesto for Agile Software Development. That’s a long time.

In that time, much has been done to try and introduce Agile successfully as a standard development practice (for some values of both “try” and “successfully”). Most times however, you will see Agile implemented as a kind of loose mish-mash of “we do 2 week sprints” and “we use stories” and “we have daily standups”.

There are two honking great problems with these piecemeal approaches. The first problem is that you can’t just cherry-pick your favourite ideas from the Agile principles (unless it’s git cherry-pick hohoho etc) and the second – less obvious – problem is that these doomed attempts are clearly only being applied at a dev team level. That is to say that they suffer from 3 enormous and fatal shortcomings:

  1. They don’t actually address any practices that take place at a coding level or a knowledge-sharing level in the dev team
  2. They provide no conduit or mechanism to ensure that the stuff built is the stuff that’s actually wanted
  3. They say nothing about the rest of the up-line business, or the idea of long-term product plans, deciding what will be worked on during this sprint, next sprint, in 3 months’ time, etc.
So in this way, most current attempts at “doing Agile” focus purely on the middle layer, and fail utterly to comprehend the required behaviours needed both upstream,  in the commercial parts of the business, and downstream, in development practices.
Often businesses can get away with this – particularly those small startup pods that are essentially funded software research projects. However, while so many play expensively at being the next Page/Brin combo, there is a real need to plug a practical gap and start sorting out companies whose product lines are actual, functioning software. These guys are still thrashing around with late-running projects, unhappy customers and long-lasting bugs. It doesn’t seem to matter how smart their teams are; they still have these problems. The so-called “enterprise” toxic bloatware pedlars have had a stranglehold on this capable, organic sector for too long. It’s time for businesses everywhere to realise that the future is Agile with SCRUM and XP, and that the tools required to make this happen are necessarily Open Source and not “enterprise” – because of the very reasons Open Source exists.
That’s what this blog is about. It will aim to show that the only workable, reliable delivery stack for software provision in real businesses is:
  • Commercial Schedule: Agile
  • Product Owner: Agile
  • Devs sprint-by-sprint: Agile/SCRUM
  • Devs day-by-day: SCRUM
  • Devs hour-by-hour: Extreme Programming

In this model, Agile is a common conduit from Commercial Schedule through to the developers’ sprint involvement but from there on in, SCRUM is a handover mechanism on a daily basis, down to the hour-by-hour, blow-by-blow, key-by-key use of Extreme Programming. It is this handoff, this synchronisation of differently sized cogs, which makes for the truly “Agile” approach.

That’s what is meant by “Putting It All Together”, and that’s what this blog is about.