6 ms·

We run an Agile process where the client is involved as Product Owner in the team. The client can add stories at any stage, and set the priority in the backlog

by 13hours 14y ago

We run an Agile process where the client is involved as Product Owner in the team. The client can add stories at any stage, and set the priority in the backlog at any time. They just can't change the current sprint's stories and priorities. That way they can make as many changes as they want, and the impact of those changes are always visible. Why limit the client to an arbitrary number of changes (like 2 in this example?) The whole idea of Agile development is that we cannot know everything in the beginning, so we spec as much as we can in the beginning, and leave room to change our minds at a later stage. Of course, we explain this way of working up front as well, and we make the benefits clear to the client. They have to buy into this before we start with anything. It works very well when they do buy in though.

gk1 14y ago
I assume you're not charging a flat fee, then? The approach described by OP provides much more certainty in terms of scope and budget, which a lot of clients prefer and allows for easier planning of resources for the managers. How do you deal with resource planning and also billing?
- 13hours 14y ago
  We don't do flat fee no. We convince clients it's not a good idea for them to do flat fee, because it takes longer, and we build in a margin to cover our risk, so they usually pay more with flat fee. By making every step of the process visible to them, and charging them for what we do as we go along, we can save them money and time.
rmrfrmrf 14y ago
I like to feel the sense of completion of a project. When you let clients run amok adding requirements as they see fit, it lowers my morale as the project completion time drags on longer and longer.
- 13hours 14y ago
  We've (almost) never had the feeling of "running amok". Communication is key, and constant feedback from the client helps us to make small adjustments often. That usually keeps them from making large changes at late stages, because we are evolving the project with them. Changes are usually an evolution, not a revolution, if that makes sense. The times where the changes were big and late, it was usually down to bad communication at an earlier stage.
jpadilla_ 14y ago
Do you use this process for all the client projects you take in? We use an Agile process for internal projects which usually don't have an ending date. When we take in freelance work from clients we end up with a certain ending date, for a certain amount of work and iterations stated before starting the project. Before using this kind of process, projects would end up being longer, we'd end up loosing money, and time for other projects.
- 13hours 14y ago
  Yes we do. We charge per sprint, not a flat fee for the total project. Once we've convinced them that our way is faster and cheaper in the long run, they usually buy into it. As specially if they've been bitten by flat fee projects in the past, where it becomes an arms race for the developers to do as little as possible, and the client to demand as much as possible. Then tend to then understand that trusting us and working with us is a much better way.
nahname 14y ago
Explaining how you get buy in would be a much more interesting blog post. The person footing the bill usually wants some plan for reassurance sake. Something along the lines of, "Aha! Gotcha! You didn't do X! I'm not paying!"
- 13hours 14y ago
  I'll try to make the time to write up something. It's really a matter of explaining to them why our way of working ends up being faster and less expensive than the flat fee way. With our way of working, there's an assumption of trust, and we keep that trust through visibility of our progress. That way we share risk, and if we can share risk with the client, we can charge less, because we don't have to build in such a big margin in the price to cover our risks.
  - nahname 14y ago
    Couple pain points from experience: Estimates in $$$ desired before start -> Leads into defining a complete feature set -> Desire for all estimates in time for all work (BS number, always) Guarantees on what will be delivered -> Getting the client on board with paying for time vs. paying for features -> Offer minimal feature set + what we can do? -> Dealing with scope creep Require clients time -> Feedback -> Showcases -> Many A) or B) given B) is 10 times more expensive
- mseebach 14y ago
  Clients who think like that will find a way anyway, process or no process. They are toxic and are to be avoided at all cost.
  - nahname 14y ago
    Try this one then, "Hey, we love what you are doing, but saw this new feature and think it is really cool. We are not saying you have to add it, but it would really make our day if you did..."
    - 14y ago

by 13hours 14y ago

gk1 14y ago

I assume you're not charging a flat fee, then? The approach described by OP provides much more certainty in terms of scope and budget, which a lot of clients prefer and allows for easier planning of resources for the managers. How do you deal with resource planning and also billing?

13hours 14y ago
We don't do flat fee no. We convince clients it's not a good idea for them to do flat fee, because it takes longer, and we build in a margin to cover our risk, so they usually pay more with flat fee. By making every step of the process visible to them, and charging them for what we do as we go along, we can save them money and time.

rmrfrmrf 14y ago

I like to feel the sense of completion of a project. When you let clients run amok adding requirements as they see fit, it lowers my morale as the project completion time drags on longer and longer.

13hours 14y ago
We've (almost) never had the feeling of "running amok". Communication is key, and constant feedback from the client helps us to make small adjustments often. That usually keeps them from making large changes at late stages, because we are evolving the project with them. Changes are usually an evolution, not a revolution, if that makes sense. The times where the changes were big and late, it was usually down to bad communication at an earlier stage.

jpadilla_ 14y ago

Do you use this process for all the client projects you take in? We use an Agile process for internal projects which usually don't have an ending date. When we take in freelance work from clients we end up with a certain ending date, for a certain amount of work and iterations stated before starting the project. Before using this kind of process, projects would end up being longer, we'd end up loosing money, and time for other projects.

13hours 14y ago
Yes we do. We charge per sprint, not a flat fee for the total project. Once we've convinced them that our way is faster and cheaper in the long run, they usually buy into it. As specially if they've been bitten by flat fee projects in the past, where it becomes an arms race for the developers to do as little as possible, and the client to demand as much as possible. Then tend to then understand that trusting us and working with us is a much better way.

nahname 14y ago

Explaining how you get buy in would be a much more interesting blog post. The person footing the bill usually wants some plan for reassurance sake. Something along the lines of, "Aha! Gotcha! You didn't do X! I'm not paying!"

13hours 14y ago
I'll try to make the time to write up something. It's really a matter of explaining to them why our way of working ends up being faster and less expensive than the flat fee way. With our way of working, there's an assumption of trust, and we keep that trust through visibility of our progress. That way we share risk, and if we can share risk with the client, we can charge less, because we don't have to build in such a big margin in the price to cover our risks.
- nahname 14y ago
  Couple pain points from experience: Estimates in $$$ desired before start -> Leads into defining a complete feature set -> Desire for all estimates in time for all work (BS number, always) Guarantees on what will be delivered -> Getting the client on board with paying for time vs. paying for features -> Offer minimal feature set + what we can do? -> Dealing with scope creep Require clients time -> Feedback -> Showcases -> Many A) or B) given B) is 10 times more expensive
mseebach 14y ago
Clients who think like that will find a way anyway, process or no process. They are toxic and are to be avoided at all cost.
- nahname 14y ago
  Try this one then, "Hey, we love what you are doing, but saw this new feature and think it is really cool. We are not saying you have to add it, but it would really make our day if you did..."
  - 14y ago