Fwd: Agile ideas and options with service/product company.

[Mark Levison]

I'm working with a client that has a product - effectively an API that they sell and then a services group that build custom products on top of their API.

The product team can operate in a fairly classical Agile/Scrum ish flavor. That's easy enough.

The services group is will struggle with stable teams. They currently work with a fairly classic model. They get client money or budget to fund the work. Then they staff the work. Some of their challenges are that their clients will ask them to go fast to meet a dependency. They deliver and the client goes dark for a while. As a result they interleave work from one "project" in another. The work is made more complicated because they're doing work in regulated environments for customers who have specific hardware constraints. They understand the pain that interleaving is causing them (task-switching costs, quality issues, etc), they don't see what their options are.

I've pointed them to Johanna Rothmann - Manage your Project Portfolio - as it turns the problem on its ear.

They feel that if they tried Scrum/XP etc with a Product Backlog and stable teams that for much of the work they wouldn't gain the core value because they're not working towards a common goal. Also the fee for work model would make it difficult because if they only get paid to give 2 people work on something, it's hard to explain six people working on the item.

--

They understand not copy and paste another companies approach. Instead they're looking for inspiration

What examples have you seen in term of service companies using some flavor of agile?

My suggestions thus far have been to look into:

- Menlo Innovations - Joy Inc - the book describes enough of the model that it seems like an idea

- Companies doing "Digital Agency" work (i.e. building small websites for other companies)

What other companies or models have you seen for service oriented businesses?

Thanks

Mark

--

Mark Levison | 1 (877) 248-8277 | Twitter | LinkedIn | Facebook Certified ScrumMaster Training: Vancouver | Edmonton | Ottawa | Montreal | Toronto Certified Product Owner & Private Training also available ~ Our Training Schedule Agile Pain Relief Consulting | Notes from a Tool User Proud Sponsor of Agile Tour Gatineau Ottawa and Agile Coach Camp Canada

[Glenn Waters]

Funny, when I first started reading this my reaction was portfolio management, as you said.

What about keep team together, bring work to team, let them figure out how to get it done. Then the team, those closest to the work, figure out the right ordering for the work depending on complexity (2 people needed vs 6 people, etc) and knowing when client goes "dark" and they can deal with a different piece of work.

The team needs to understand how to work in this environment. Teamwork skills.

There needs to be good visibility around the work so that people know when the team has too much or too little.

Frankly, I don't see this situation as much different than many other teams I work with. The team is presented with work from multiple streams and must figure out the right way to get the right stuff done. Sometimes with the help of a PO. Sometimes not. Sometimes with light touch by management/product people.

Finally, start somewhere. I like starting simple and then iterate and improve.

Glenn

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CA%2BUdPQ8cvwFF-gQu4Ygm5dOWLOXzvKhPJHomTYKbXeXNPokfkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Ottinger]

It's a shame that they're billing for people's time rather than charging for the work products. That makes it funky.

To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CA%2BT6n9hMruj7A6cL7JC2mA92tJLVpm%2B3BFinOOPRBPhMk%3DWPfA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Tim Ottinger, Anzeneer, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileotter.blogspot.com/

[Jon Kern]

So, it sounds like it may not be architected to support the business model.

Maybe they need a better way to wield the API on a per-client basis...

Jon Kern

linkedIn: https://www.linkedin.com/in/jonkern/

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CAN2NStkiTmoRMjPJpbxe69SE7OSSTKKWgmHq5%2BDFxHcTA%3D0s0A%40mail.gmail.com.

[Mark Levison]

Glenn - thanks for taking the time to reply

On Mon, Jul 15, 2019 at 11:23 AM Glenn Waters <gwwa...@gmail.com> wrote:

Funny, when I first started reading this my reaction was portfolio management, as you said.

What about keep team together, bring work to team, let them figure out how to get it done. Then the team, those closest to the work, figure out the right ordering for the work depending on complexity (2 people needed vs 6 people, etc) and knowing when client goes "dark" and they can deal with a different piece of work.

The team needs to understand how to work in this environment. Teamwork skills.

There needs to be good visibility around the work so that people know when the team has too much or too little.

Frankly, I don't see this situation as much different than many other teams I work with. The team is presented with work from multiple streams and must figure out the right way to get the right stuff done. Sometimes with the help of a PO. Sometimes not. Sometimes with light touch by management/product people.

Finally, start somewhere. I like starting simple and then iterate and improve.

As usual - you provide wise, sober second thought. Perhaps we should have you appointed to the Senate. Seriously, they could use you.

Cheers

Mark

[Mark Levison]

Tim - thanks

On Mon, Jul 15, 2019 at 2:22 PM Tim Ottinger <tott...@gmail.com> wrote:

It's a shame that they're billing for people's time rather than charging for the work products. That makes it funky.

Agreed that is the underlying challenge. I have recommended that they look at more effective contracting models - even providing a link to the Agile Contracting book by Boris G and co.

Sadly I think that change will be lagging and not leading.

Cheers

Mark

[Mark Levison]

Jon - Danke. The API maybe be poorly shaped, but their challenge is that they have created a library/API that can be used in a large number of products. Their professional services model is then to develop these diverse products for the clients.

Cheers

Mark

[Allen Holub]

Mark, is there some reason why they can't change the payment model to be focused on value delivery rather than hours? It's really a matter of capacity planning, isn't it? The team has a certain capacity, which costs a certain amount. Also, have they considered a more Lean approach? Generally, processes like Kanban work better with this sort of scattershot work than something like Scrum.

-Allen

_______________________

Allen @ Holub .com
@allenholub
+1 (510) 859-3620  (Skype: allenholub)
http://holub.com
http://linkedin.com/in/allenholub

--

[Mark Levison]

Allen - thanks for taking the time to respond.

On Tue, Jul 16, 2019 at 10:57 AM Allen Holub <al...@holub.com> wrote:

Mark, is there some reason why they can't change the payment model to be focused on value delivery rather than hours?

The challenge is that the people I'm helping and the sales people are in separate groups. 

I think we all agree selling value and not hours would be a good move. The question is it an early stage move (ideal) or later stage - because I don't have the influence to get that far.

It's really a matter of capacity planning, isn't it? The team has a certain capacity, which costs a certain amount.

Yes. 

Also, have they considered a more Lean approach? Generally, processes like Kanban work better with this sort of scattershot work than something like Scrum.

To be clear I have told the services team that Scrum isn't a good fit here. I even shared my own item on the Limits of Scrum: https://agilepainrelief.com/notesfromatooluser/2019/01/what-are-the-limits-of-the-scrum-framework.html

Kanban is a possible answer, however its so broad like Scrum, that I was trying to find specific details on what other professional service teams or companies have done well.

Cheers

Mark

[Tim Ottinger]

If wishes were fishes....

It would be so much nicer if they were doing like the cell providers do/did. 

They used to do metered usage (call rating) for years, but then went to a subscription model. In both cases they were managing, supporting, and enhancing a revenue stream instead of selling developer hours.

But that’s just wishful thinking, perhaps. It would be nice if they were product, rather than project focused. It would open up a whole world of options and Lean Startup techniques.

I don’t know what the end of pay-for-features is. Eventually don’t you have to keep coming up with features in order to keep your revenue? Will that lead to stupid features? Will you have to expand dev staff to increase revenue? What happens when its good enough for the users? 

But that’s not the immediate problem. If they are happy with what they’re doing, I guess there’s a reason and we have to trust that they’ve thought through it for themselves well enough for the short term. I wonder what the bigger plan is.

I’ve just realized I’m not being helpful, just wandering around wishing.

So what was the specific problem we wanted to solve again? 

[Mark Levison]

On Tue, Jul 16, 2019 at 11:15 AM Tim Ottinger <tott...@gmail.com> wrote:

If wishes were fishes....

It would be so much nicer if they were doing like the cell providers do/did. 

They used to do metered usage (call rating) for years, but then went to a subscription model. In both cases they were managing, supporting, and enhancing a revenue stream instead of selling developer hours.

But that’s just wishful thinking, perhaps. It would be nice if they were product, rather than project focused. It would open up a whole world of options and Lean Startup techniques.

As much I said to them in person. They feel that they've taken the one core product to the limits of its revenue model and services is where the money is.

Basically they have a datasource and a way of visualizing that data for clients. The clients then pay to get other data sources integrated into the system and visualized with the core datasource that my client has.

I don’t know what the end of pay-for-features is. Eventually don’t you have to keep coming up with features in order to keep your revenue? Will that lead to stupid features? Will you have to expand dev staff to increase revenue? What happens when its good enough for the users? 

Well its the consulting model - most of us on this list do it to varying degrees.

But that’s not the immediate problem. If they are happy with what they’re doing, I guess there’s a reason and we have to trust that they’ve thought through it for themselves well enough for the short term. I wonder what the bigger plan is.

To their credit the company is over 30 yrs old. In recent years it was bought out by 200 yr old company

I’ve just realized I’m not being helpful, just wandering around wishing.

Wandering around with the likes of you is way more fun than the work I had intended to do today.

So what was the specific problem we wanted to solve again? 

Other than Menlo whatever examples or reference models have you seen for companies working in this way.

Cheers

Mark

--

Tim Ottinger, Anzeneer, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileotter.blogspot.com/

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CAN2NStkr-2X9v1PJsZq51_t_0zZNiFkNG%3Dn-Vujv%3DLGdS874mA%40mail.gmail.com.