9

This question has two levels: actual problem of contracting the work for agile team does it really matter how the work is contracted? It actually doesn't matter how the contract looks Even if you sign fixed scope/price contract with customer you still might be better off using agile/iterative approach. Use it as risk minimizing factor. Nothing stops you ...


9

In a similar instance when we were facing delays- We have clarified client about our organization internal structure. In our organization, resources are taken out from one project and given to another project if billing is not done. We cannot keep hold of resources indefinitely. So resource billing is to be done for the waiting time. Resource work/...


9

Your first course of action should be to secure some legal counsel and get their opinion. Asking a message board for legal advice is only marginally better than doing the same for medical advice... at least in your case you only stand to lose money. That being said, unfortunately this kind of thing is not uncommon. Customers change their minds all the time, ...


7

TL;DR No, because what you describe is not strictly Scrum - you should fix the process instead of inventing a workaround. The PO can change the product backlog, but not the sprint backlog. If the team does not agree with the required change, or cannot implement it without endangering the sprint, PO may cancel the sprint (and incur all associated costs), or ...


5

Agile Projects Generally Work Best When Billed as Time-and-Materials Do software developers operating under some sort of agile development cycle and presenting a series of 'deliverables' to their customer expect—or contract—their clients to make a stage payment per acceptable deliverable? In the world of contracting, anything the parties agree on (...


4

TL;DR Should I add something to "Client Obligations" about code style? You can do this, but you may be measuring the wrong thing. This smells like an X/Y problem: you have a problem to solve with the deliverables hand-off, have decided that coding style is the thing that will fix the problem, and are now trying to solve for "coding style" rather than the ...


4

One of the four values of agile is "Customer Collaboration over Contract Negotiation." The first thing to ask is "what is best for the customer?". Once you've done that, then you ask "is it covered by the contract?" and only then do you delve into the "do we ask for more $". Specifically focusing on your issue the first question I'd ask is who was ...


4

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation. A T&M is perfectly appropriate for this scenario. Insist on it or walk away.


3

You are a party to the contract. This means you have to protect your party's interests in the agreement, which you are NOT doing now. You say your customer does not want to pay for a fully loaded team but wants the benefits of a fully loaded team. All customers would want that. You answer needs to be: pound sand (not literally). Your price for a small ...


3

What you've described exists (in most part), but it's not a FFP contract, it's a "Cost Plus" or "GMP" (Guaranteed Maximum Price) type of contract. In this type of contract, the two parties agree that the Owner will pay the actual costs, plus a fixed price to the Contractor, up to an agreed upon maximum price. This price ceiling is generally the result of the ...


3

Sprint contracts, such as you describe, should not be used, as it defeats the purpose of Scrum/Agile. Instead, do the work up front to ensure the project can be run properly. To do so, the following (at minimum) should happen Ensure the client is properly educated in Scrum before the project starts. Ideally, this begins to happen in the pre-sales/sales ...


3

Lets assume that the consultants are working in good faith and their estimates are correct. Now delays must be caused by the usual things: external task needs to be completed by someone else. extra requirements added during project missing external resources, api, servers, accounts etc Enumerate and record the actual reasons for the delays. "what could we ...


3

Without detailed and fully agreed requirements, you have a load of assumptions. I suggest you document the assumptions as fully as possible, then structure a contract on a time and materials basis with the assumptions clearly stated. Then you can test the assumptions and document them as risks or issues as necessary. As an alternative to this you may prefer ...


3

"Outcomes" Aren't Synonymous with Fully-Fixed Constraints In Scrum, the burn rate of each iteration is (relatively) fixed. The flexible sliders are scope and schedule. So, "outcome-based pricing" is certainly possible so long as you can adjust scope and schedule, but it isn't feasible if you're abusing the term to mean "fixed price for fixed scope." If the ...


3

The best software solutions are built when the software vendor and the customer that ordered that software collaborate to make it happen. "Customer collaboration over contract negotiation" says the Agile Manifesto. Of course, the two parties involved in building the software (vendor and customer) need some legal agreement in place. They need a contract. For ...


2

No, its not a good idea, as it defies one of the core Agile principles: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Cancelling a Sprint: If the changes are so big that it brings the sprint goals in danger tell the Product Owner to break up the sprint and start a new ...


2

I was in the small claims court last month and I can tell you the Judge expects compensation for work completed. So the other party is not in a position to claim it all back. As for contracts, my judge formed his own opinion, even in the face of UK legislation on the table. So a knocked up contract isn't going to be watertight.


2

Tl;dr; Do relative sizing on features. To Elaborate: When you’re looking at a fixed-bid contract, you’re saying “It will take me no more than this much money to do deliver the full scope.” This is problematic in Agile because we recognize that most software projects do not understand their scope until very late in the project. This isn’t the result of ...


2

You don't need to be aggressive, you need to be realist. Your contract wasn't prepared for the current situation, so you guys need to sit together and review the situation. As Dimple mentioned (+1!) you should make sure your client understands how your company work and that there are impacts if there's no contract review / agreement for the end of the ...


2

If you have a good relationship, you may agree with your customer to pay some portion of the work now - about 70% - to cover you expenses. In the mean time, you save and plane with some resources to be able to do the installment in 3 months. During negotiations I would always put emphasis on the good relationship, keeping it, and on being ready on time. I ...


2

TL:DR: Always use agile, change your reporting, not your contracts. It sounds like the root problem here isn't about using agile nor the kind of contract you use, it's about managing Change Management. Regardless of if you use agile or traditional development techniques any project over roughly a week is going to see changes. You need to help your client ...


2

TL;DR At this stage, the project manager's job is to provide a framework for the companies to address scope, and to estimate the budget and resources needed to deliver that scope. That's it! In situations like these, questions of fault (unless of course it's yours) are really outside a project manager's scope of responsibility. Rather than assign blame, or ...


2

Discuss it with them and get their buy-in first. Agile won't work very well if not everyone involved is on-board. Worst-case, you can still try to use Agile internally while working with external customers in a more Waterfall style. Do not try to just foist Agile on them. Inform them about the benefits and let them see why it would be a good idea. If they'...


2

TL;DR Yes. Under your current contract and within your current process, you should pay the vendor for all work completed. Unless you have a fixed-price, fixed-scope contract, all the problems you've described are process issues for which your company (rather than the vendor) is responsible. You are having difficulties because you are treating the offshore ...


2

Sounds like working in a more Agile-structured way would be beneficial. If you require being able to see incremental versions of the software every so often (say, every two weeks), then you will not only be able to provide early feedback, this will also force issues into the open much earlier, as well.


2

FAR Definition of Incentive and Award Fees Scroll down to Section 16.4. These two types of fee structures are essentially the same thing except for the criteria of the fee. The FAR differentiates between the two based on the specificity of the criteria where, for incentive, it is both feasible and effective to arrive at very specific, objective criteria. ...


2

I see two broad approaches to solving this issue. One Agile, one not. The "non-Agile" approach is to hire a lawyer and have your contracts drafted in such a way that the burden of miscommunicated requirements falls on the vendor (freelancer) instead of the customer (you). The downside of this approach is that few experienced freelancers will bother to ...


2

What would be your course of action with the client? Ans : 1) Share the current status with client 2) Revisit the project plan and re-prioritize the scope. 3) Based on the updated scope realign the resources. 4) Motivate the team to work towards minimal rework, maximum productivity. 5) Since your working in T&M anything which is not a part of SOW or MSA ...


2

TL;DR Since there is a distinct discovery phase in most projects, the purpose of which is to determine whether the project is to be abandoned or taken forward, do consultants get paid for recommending that projects be abandoned? Do employers set deadlines for discovery phase? The deliverable for a discovery phase is usually a document, report, or ...


2

One of the factors to consider is whether the client is sufficiently experienced at this kind of engagement. It only makes sense to take this kind of thing on if both parties are prepared to negotiate scope later, otherwise one or both of you is likely to come away dissatisfied. The customer should understand that "fixed" price means they pay a premium for ...


Only top voted, non community-wiki answers of a minimum length are eligible