Will increasing "free" childcare actually cost working parents?

So as a little background, in Wales, it is the intention that 3 year olds get a minimum 380 hours of free educational childcare a year.
But in reality, it doesn't quite work like this. Children are entitled to attend up to 5 sessions, which are between 2 and 2.5 hours a day, depending on the nursery. They must be taken on separate days.

The issue I am trying to raise, is that the funding for these sessions has not been put up for many years and now falls well below the actual nursery costs. When I first took issue over this, I used the Family Information Service database to work out the average nursery cost in Newport, and found that the there was not a single nursery that cost the same or less than the funding level.

While it could be argued that if you sent your child to nursery at a school, then the free places would genuinely be free - this is not possible for working parents, as school nurseries only provide the free sessions, and this would mean collecting your child at the end of that session, or paying for wrap around care to get them delivered to another childcare location.

Here is the maths...

Newport City Council Funding

£6.83

per session

£34.15

Per week for 38 weeks

If 10 hours is funded, the day rate would be

£34.15

In a year

£1,400.15

At Buzzy Bees, a session is 2 hours 15

£8.55

per session

£25.65

Per week for 38 weeks

The actual daily rate is

£38

To fund 10 hours at Buzzy Bees, the funding is £3.85 short per week

To fund the 2 hour 15 session would be

£8.60

short per week

If a child arrives at 12:30 and is picked up at 2:45, then the parents pay nothing at all, and the nursery is paid £6.83 for the session by NCC

If the child stays for the rest of the day, the parent gets £6.83 knocked off the bill, so the day costs £31.19

This means in reality, the child gets 9 hours of free childcare, below the 10 hour minimum

However, I believe that people who work, like myself had no choice but to use the nursery for the full day. There is very very little chance you could practically work in the 2 hours while you child is at nursery.

The sessions must be taken on separate days, so you can't have a whole day.

Therefore this free funding benefits non-working parents the most.

Additionally, I believe that this "free" funding is actually putting up the costs for paying parents. For each child that goes home immediately after their free session, there is a weekly shortfall of £8.60 at my nursery

This may not seem much, but let's say at our nursery there are 30 children and 20 go home after their sessions, the nursery is £172 short. That's like having 4.5 children at the nursery not paying their fees

Nurseries have costs, they must pay their teams, so let's say this cost is spread between the children who stay all day

So my child who started nursery at 9 months old, and will be eligible for rising 3 funding when he is 3 years 3 months old, will be subsidising other children for 2.5 years

and then in his final year, he will be eligible for funding, but will still stay all day, so will continue to subsidise other children, so

In his final year, Oscar will get

£1,400.15

in government funding

But over the 3.5 years he will have subsidised other children to a tune of

£2287.6

Therefore the government funding will cost me

-£887.45

over the 3.5 years he will be at nursery

Or, If the nursery is able to silently absorb the underfunding without going bust, at very best, my little boy will get

368.465

Hours of free childcare, when this should be a MINIMUM of 380

A story about a Project Manager and a Programmer going shopping

So once upon a time I walked into town one Friday lunch time with a colleague and friend who happens to be a developer.

I told him I wanted to buy a green cardigan, and he said he had nothing better to do and he’d come with me.

In the first shop we wandered around, couldn’t see any green cardigans and wandered out again.

Same in the next.

In the 3^rd shop he helped point out 2 green cardigans, but I didn’t like either. One was too fluffy and one was “the wrong green”.

After about 20 minutes he lost interest, told me that this was impossible and he was going back to work.

That evening, I arrived at the pub – he looked me over and asked if I’d bought a cardigan.

I gave him a spin and said that no I hadn’t, I’d bought a green handbag and green nail varnish.

This did not compute! I’d told him I was looking for a green cardigan. How could a green handbag and nail varnish possibly meet that brief? He’d been looking at the wrong items all along! He could have spent the whole day shopping and still wouldn’t have come up with that solution.

So when I said I needed a green cardigan, this was only what I thought I wanted! Actually, what I needed was something to tie my new green shoes into outfit I had chosen for the evening! Pretty much anything green would have done – belt, scarf, necklace, bag, nail polish – green accessories.

As a user story

Frances wants to buy some green accessories, so that she can wear her new shoes with a black dress

Although this may appear to be a story about shopping, it’s actually about ensuring that your requirements don’t jump the gun and guess a solution rather than outlining what you’re actually trying to achieve…

Frequently when I asked people what they are trying to achieve, or what is the objective of the project, I am told things like to implement a database of training courses.

 No, no, no! This is not your objective, or if it is, then something it wrong!

Firstly at this stage, perhaps don’t be so certain that a database is the answer, maybe SharePoint list would do the job in half the time and at no cost? Don’t limit your options or guess the solution too soon.

But more importantly, share the purpose and context - it helps give a shared understanding, it ensures that we understand your goal, how it contributes to the business and allows us to appropriately prioritise work. It also allows us to explore all options and to ultimately ensure that you achieve what you actually need to achieve.

I'm pretty sure you're not implementing a database just for fun, what is the background and reason for this?

Potentially the real objective of your project might be to  improve ease and visibility of accessing/booking training courses, or even to zoom out one step further, the objective might be to increase the number of people on training courses or increase revenue generated by training.

Getting your objective wrong, could mean that it is possible to achieve your objective, but not achieve what you need to achieve

You may have implemented a new training database, but no one has entered the courses, or no one approves booking requests, or it is located where no one can find it

Alternatively you may get exactly what you asked for, but then realise that that isn't actually what you wanted at all!

Story about the rabbit and the cream cheese

It's the way you tell 'em - user stories vs requirements spec

Return to GeekSpeak page

The story about the rabbit and the cream cheese!

It’s not really about a rabbit and cream cheese, it’s actually a story about user requirements, how they are specified, assumptions and context!

 

A long time ago, I sent my boyfriend a text message and asked him to buy some low fat cream cheese on the way home.

 So what do we think? Clear instruction of what I wanted and when?

 Well no, when I got home he said to me, “you didn’t tell me how much you needed so there’s two packets in the fridge”
 

And in the fridge there were two packets of low fat Dairylea Triangles

Ok, so they are low fat, there is enough for what I needed, and they were purchased on the way home – does this meet my specification?

 Well, after a little debate and looking up the definition of cream cheese, we agreed that does actually meet what I asked for.

 Which means that I was happy right?

Well no. Although I loathingly agreed that that did mean my specification, it was not what I wanted and would be difficult for me to use.

 Why?

 Because actually I was making my pet rabbit a carrot cake for his birthday, and needed cream cheese for the icing.

The actual cream cheese itself would have been ok, but I would have had to open every triangle and scrape the cheese out. Far from ideal!

 So what’s my point?

 Well my point is about context and shared understanding of what is trying to be achieved. Without this information, it is very easy misunderstandings to occur, or for one person to think they know what is meant or wanted, when in fact they don’t.

 In Scrum, instead of saying “Please buy some low fat cream cheese on the way home”, this would have been expressed as a user story

 

Hector would like you to buy 500g of low fat cream on your way home, so that I can make the icing for his birthday carrot cake

 User …. Requirement…. Context

With this additional context information, I like to think that my boyfriend would have made a slightly different choice.

 Potentially of course I could have just asked for 500g of low fat Philadelphia (which is exactly what I wanted) – but there is also danger in being over specific, or guessing the solution rather than telling your development team the problem and letting them find the best solution.

 If Philadelphia hadn’t been available, or there was an own brand equivalent for half the price, then actually, he could have bought me what I needed, without meeting my (too specific) specification.

 I also have another true story – about the project manager and programmer going shopping (which is actually about specifying the solution, rather than outlining the problem/task you are trying to achieve)

 

Returnto GeekSpeak main page

 

  

It’s the way you tell ‘em – User stories vs Requirements

In traditional project manager, someone spends a lot of time putting together a specification, then hand it over to the development team.

Something is developed, there is a big reveal and then faces are pulled, it’s not quite what they wanted!

During a training course we were put in pairs, one person was shown a simple picture made up of shapes, and had to write down instructions as to how to recreate it. The other person then had to try to draw the same picture from just the instructions, without looking at the original, or asking any questions.

We did pretty well, but there was one point of contention – I’d been told to draw a cross in the bottom left hand corner. I deliberated for ages over whether this should be

 

Eventually I went with the one on the right – If  you’d told me to put a cross in the box, this is what I would have drawn, therefore this must be a cross.

I revealed my drawing to my partner who declared “What have you drawn a kiss for!”

Another of his instructions had been to “draw a pac man facing left” – which I did with no issue, much quicker than the people who had long instructions about drawing a circle, with a chunk out of it etc etc

 

 

I think the point of my story is that it is easy to make assumptions,  requirements are hard to describe, often what is clear to one persons (the expert in the field) makes no sense to others.

 

So what’s different about Scrum?  Two things

1.      Requirements are written in a User Story format that provides context
2.       Customer involvement

 

User stories are written in 3 parts User…Requirement…Context

e.g. Manager wants the wall blue, so that it is clear that it is associated with the shop

This is intended to ensure that the requirement will benefit at least one user type, and that there is valid reason for doing it.

 Customer involvement is also key. Scrum encourages co-location and regular conversation and demos. This means that if the developer is unsure which way round a cross should be, they can ask, or alternatively if the customer sees the builder with a colour chart, they can mention they wanted Royal Blue before too much time/paint is wasted.

 

Read a story about the importance of context – the rabbit and the cream cheese!

 Previous section: Focus and the minimal shippable product

 Next section: Turning a good story into a usable backlog

Do you want to build a snowman? (Scrum style)

The basic principle of scrum, is to deliver the absolute bare minimum to make a product do its job, and then develop it incrementally over a number of short sprint periods.
 

Start basic, and then go back to add the bells, whistles, nice to have features and extras afterwards.

It's also worth mentioning that these sprints don't have to run back to back - it's ok to work on other things in between - particularly if this gives your customer time to think about what they need, or find out more information (like decide what colour scarf they'd like)
 

	So if my product is to draw a snowman - in the first sprint I do the minimum possible to make it recognisable Imagine it's pictionary!
	In sprint ii you can start to think about the other features of a snowman, so maybe the hat and scarf, and buttons. As you only have a set amount of time, you'll need to weigh up how much you want each item against how long it will take to implement. In this sprint we could only achieve buttons and a hat, no scarf, so that rolled forward to the next sprint.
	In sprint iii scarf was the top priority, but we also had enough time to start adding "extras" such as stick arms.
	By the time you reach sprint iiii and iv you've already got a well established product. Potentially you should have already stopped, and moved on to something else. However, if you have the business need and the time available - why not add some colour and other embellishments. Just make sure that these do benefit the customer, or at the very least do not irriate people or inhibit use of more essential features.

Minimal shippable product - do "enough" and no more

So in September I started my annual Christmas knitting. Except every year the children get bigger and so the jumpers take longer to make.

This year I planned to make a cardigan for my son featuring holly leaves.

 

 

 

Last week my daughter saw my knitting, asked if I was making her one… it’s hard to say no. My instinct was to put down what I was doing and start a new jumper immediately.

 

If you have 2 jumpers to deliver, is  it better if come Christmas I have two half-finished jumpers, or one complete wearable jumper?

Sometimes trying to keep everyone happy, working on everything at the same time just delays delivery of anything, and may lead to everyone being disappointed.

(and actually it was much better to fess up that I had no chance of making my daughter a jumper in time, and take her to a shop to choose and buy one, than wait until the week before and end up buying two jumpers in a panic because I hadn't finished either!)

 

•      Focus! There is no value until the product is done!
 

 Focusing on what is actually needed is also essential – ideally the cardigan should have little red pompoms between each pair of leaves, but really this is just a  "nice to have".

Although it’s very tempting to sit making pompoms because that’s fun, rather than knitting a plain green sleeve, one is fairly critical to creating a finished product and should be completed first, before the embellishments are added.

Which leads us nicely to the concept of the minimal shippable product…the concept of doing just enough to make it work – ask “is it good enough” for the intended purpose.

Make sure you aren’t designing a Ferrari when all you need is a bike

Work through requirements in priority order and add features incrementally.

Knit your cardigan first, you can always add your pompoms later

Watch my snowman drawing iteratively develop from a minimalshippable product through 5 sprint cycles!

 

Previous section: What’s all this Scrum nonsense

Next section: User stories vs Requirements

Scrum in a nutshell

I wanted a way to quickly and succinctly explain what the agile framework scrum is all about, and try to put across why I’m so passionate about it.

Unfortunately I think my passion has caused it to creep slightly out of nutshell and into a chocolate covered nut selection box, but hopefully it still has some value.

What’s all this scrum nonsense?

A scrum in rugby is an ordered formation of players, used to restart play.

 

 

The scrum agile framework is also intended as a way to keep the game moving and get the ball back into play.

It’s just a different way of controlling projects, that fits particularly well for IT and development projects.

 Managing projects

In projects you usually have 3 variables, time, resource (inc money) and quality

 

 

So if resource and time is no object you can have amazing quality, or if you have a short deadline but loads of money/resource you can still have great quality.

Otherwise there needs to be a trade-off somewhere, do it quick but low quality, or get it quick by adding extra resource.

If you’ve ever worked on an IT project you’ll understand by Scrum was borne out of developer frustration at constantly being nagged at and blamed for work being delivered late, and their perceived inability to be able to commit to when new work can be scheduled for delivery.

 In reality the reason the projects usually overrun or fail is due to poorly defined requirements, lack of customer engagement, scope creep, and developers being forced to spend hours on trivial things just to get the customer to sign off.

 We should also remember that developers are also usually very bright individuals. They don’t take kindly to constantly being interrupted and bugged by Project Managers asking and moaning for things. Particularly when what they are being asked for is completely unachievable to start with, and was never actually something they agreed to.

How many times have you been given a project plan that already has a milestone dates on it before you’ve have any real involvement?

Surely it’s not possible to know when something will be finished before you’ve been asked how much work will be needed from your team or when you might be able to schedule this in?

 

So why is scrum different?

Scrum is different because

•      Fixed time and cost for projects

•      No Project Manager – therefore no micro management (Team is responsible for themselves and customer (product owner) also has responsibilities)

•      Meetings are rare and TIME BOXED! (they can’t overrun)

•      Requirements are clear and prioritised – if they’re not it’s for someone else to deal with (product owner)

•      Focus on one thing for a set period of time – (a sprint) if you’re being distracted, it’s for someone else (Scrum master) to sort out

•      People are forced to really think about what they want and why they want it

•      The whole process is visible - I’ll show the value of this later

 

Ultimately Scrum provides some certainty – we know that we are going to work on one product for a fixed length of time (a sprint) and at the end of that period, we will deliver something.

 We don’t even think about starting work until we have all the requirements laid out, and commitment that the customer will be there if we need to ask questions or demonstrate new features.

 If not everything is delivered in the first sprint, then it is either written off as no longer important, or another sprint is scheduled in the future.

 

Next section:   Focus and the minimal shippable product