Agile Coach - What to put on Schedule?

[Lockhouse]

I'm currently appealing a blanket SDS determination.

There's some talk of me being rehired as an Agile Coach. There's no D&C or MOO. How could I word the schedule to make it as IR35-friendly as possible? I'd be working across multiple projects etc.

Any suggestions gratefully received.

[northernladuk]

Should be pretty easy. It's all about specific deliverables and targets you will achieve in the timescales of the contract.

You obviously know the role but I found this article.

What is an agile coach? A valuable role for organizational change | CIO

You could quite easily take a whole host of deliverables straight out of that and list them. Obviously tailor them to what you know about the role but that article gives more than enough goals to be achieved to make up a good statement of work IMO.

I'd use three columns. First with a high level statement of aim, second with some bullets detailing how or what you will deliver and the last one empty. You'll fill the last one in with results that the client will sign to agree deliverables have been met.

Just scanning that article one example could be..

Knowledge and tools

Analyse as is knowledge and tools
Create knowledge plan to achieve agreed outcomes
Implement knowledge within agreed timescales
Source and deliver tools to achieve agreed outcomes
Provide consultancy to ensure tools knowledge continue to meet client requirements

In the last box you will detail the training and tools delivered and to who at the end of the period and the client will sign agreeing you met the agreed deliverables.

That make sense?

I don't know what agile coaching but I'd say 5 or 6 high level entries with associated bullets would do.

[Lockhouse]

No-one else need reply to this thread. That's a nailed-on answer. I really appreciate it.

[LordAsriel]

As a fellow agile coach, I'll add a little more specificity in the type of things I intend to be including in the deliverables section of SOW's I work under going forwards;

- Completion of an Agile maturity assessment
- Delivery of an agile maturity roadmap
- Delivery of X number of agile training workshops as per agreed schedule
- Consultancy / delivery of of X role (E.g. Scrum Master) as per agreed schedule

I'd be looking to include payment milestones upon completion of the first few deliverables in particular as these will be documents. Milestones linked to completion of X number of training sessions

I'd also be looking for relief events to be included for the scenarios wherein I'm unable to complete a deliverable due to omission or inaction on behalf of the client. E.g delivery of X number of training sessions is dependent on client ensuring staff attend these sessions.

I'd price this up based on an assessment of requirements following consultation with the client and have %'s of the total price based on payment milestones.

Just my thoughts..

[DigitalUser]

As a fellow agile coach, I'll add a little more specificity in the type of things I intend to be including in the deliverables section of SOW's I work under going forwards;

- Completion of an Agile maturity assessment
- Delivery of an agile maturity roadmap
- Delivery of X number of agile training workshops as per agreed schedule
- Consultancy / delivery of of X role (E.g. Scrum Master) as per agreed schedule

I'd be looking to include payment milestones upon completion of the first few deliverables in particular as these will be documents. Milestones linked to completion of X number of training sessions

I'd also be looking for relief events to be included for the scenarios wherein I'm unable to complete a deliverable due to omission or inaction on behalf of the client. E.g delivery of X number of training sessions is dependent on client ensuring staff attend these sessions.

I'd price this up based on an assessment of requirements following consultation with the client and have %'s of the total price based on payment milestones.

Just my thoughts..

I'd put some concrete outcomes in place as well - the deliverables are merely outputs, in itself they don't do anything to benefit the client.

Flexible Contracts might be of use in this instance. I'd also break the engagement to do some initial work to establish what's needed (otherwise you're rocking up on site without knowing what the 'right' deliverables are).

[LordAsriel]

I'd put some concrete outcomes in place as well - the deliverables are merely outputs, in itself they don't do anything to benefit the client.

Flexible Contracts might be of use in this instance. I'd also break the engagement to do some initial work to establish what's needed (otherwise you're rocking up on site without knowing what the 'right' deliverables are).

Valid point. It may be that you do a level of 'Discovery' up front, with this SOW engagement completing upon completion of investigations around the as-is and production of a maturity assessment / roadmap for further maturity.

With this knowledge, you may then be able to enter a delivery focused phase under a new SOW with concrete deliverables around what you've discovered within the initial phase.

[northernladuk]

I'd put some concrete outcomes in place as well - the deliverables are merely outputs, in itself they don't do anything to benefit the client.

Flexible Contracts might be of use in this instance. I'd also break the engagement to do some initial work to establish what's needed (otherwise you're rocking up on site without knowing what the 'right' deliverables are).

I wouldn't. Concrete outcomes usually are dependent on a lot of things you have no control over. Once you start putting those in you have to work on contingencies if you can't deliver. Technically if you are paid upon delivery of that outcome and it doesn't happen you don't get paid. I do think that's probably one step too far for contractors to swallow. I'd stick to agreed deliverables. Clear enough for direction but woolly enough to be flexible if it goes wrong.

It's going wrong on mine already only three weeks in and we can't meet the main one due in two months. If that had been concrete then the whole relationship could go south for no reason. Instead we'll just to business with an eye on the deliverables as guidance. We will then re-align the deliverables for the next piece of three month work.

Establishing what is needed is absolutely key in a schedule. It's impossible to write a decent roadmap without some fact finding. I'd be seriously worried if I was given a difficult schedule with no chance to investigate what we have before piling in and changing it. It's also a very nice consulting term so defining an As-Is view always looks good as well as being essential. It's 101 stuff when you are going in delivering change.

[Lance]

I wouldn't. Concrete outcomes usually are dependent on a lot of things you have no control over. Once you start putting those in you have to work on contingencies if you can't deliver. Technically if you are paid upon delivery of that outcome and it doesn't happen you don't get paid. I do think that's probably one step too far for contractors to swallow. I'd stick to agreed deliverables. Clear enough for direction but woolly enough to be flexible if it goes wrong.

It's going wrong on mine already only three weeks in and we can't meet the main one due in two months. If that had been concrete then the whole relationship could go south for no reason. Instead we'll just to business with an eye on the deliverables as guidance. We will then re-align the deliverables for the next piece of three month work.

Establishing what is needed is absolutely key in a schedule. It's impossible to write a decent roadmap without some fact finding. I'd be seriously worried if I was given a difficult schedule with no chance to investigate what we have before piling in and changing it. It's also a very nice consulting term so defining an As-Is view always looks good as well as being essential. It's 101 stuff when you are going in delivering change.

Bang on... Outcomes are out of the control of those who actually deliver.
Always get paid based on delivery, or T&M. Never on something so vague as an outcome (unless you're the boss who decides what the outcome was).

[DigitalUser]

I wouldn't. Concrete outcomes usually are dependent on a lot of things you have no control over. Once you start putting those in you have to work on contingencies if you can't deliver. Technically if you are paid upon delivery of that outcome and it doesn't happen you don't get paid. I do think that's probably one step too far for contractors to swallow. I'd stick to agreed deliverables. Clear enough for direction but woolly enough to be flexible if it goes wrong.

It's going wrong on mine already only three weeks in and we can't meet the main one due in two months. If that had been concrete then the whole relationship could go south for no reason. Instead we'll just to business with an eye on the deliverables as guidance. We will then re-align the deliverables for the next piece of three month work.

Establishing what is needed is absolutely key in a schedule. It's impossible to write a decent roadmap without some fact finding. I'd be seriously worried if I was given a difficult schedule with no chance to investigate what we have before piling in and changing it. It's also a very nice consulting term so defining an As-Is view always looks good as well as being essential. It's 101 stuff when you are going in delivering change.

It's a fair point - what I would say is that the guiding principle here is that the risk is shared with the client. If the client doesn't play ball (and this is evidenced along the way) then you still get paid. I'd also break down the SoW into smaller work packages which roll up to the overall deliverables + outcomes. YMMV with all of this type of work, of course.