1

Context: I am talking about a new program from Microsoft for Microsoft Teams based app development called "SLATE". This program requires 6 weeks fixed timeline for the "Build" phase and 2 weeks fixed timeline for "Envision" phase. Microsoft development partners who are involved in these phases, need to provide detailed documents (eg: Detailed SOW before starting Build phase) to Microsoft, to the engagement with the partner and Microsoft customer to be approved. On successful delivery after the 6 weeks of build phase - Microsoft pays the money to the partner. Technically the Microsoft customer get the software for free. Microsoft gets Azure, O365 costs from the customer, since the software was developed to use such technologies. Cost of the Build phase is around USD 25000, which will be paid to the partner who develops the solution and the Microsoft partner is entitled to get support from Microsoft product development teams.

Problem: Our team tried to do this in agile methodology which is consist of 2 week sprint - but realized that after 2 week sprint demo, we started receiving changes from the Microsoft customer to whom we are building this solution. But Microsoft is saying that the SOW is fixed and can not be changed.

Considering the 6 weeks fixed timeline and the SOW cannot be changed, can we say: we can only use "waterfall" methodology for such projects engagement?

Improve this question
5
  • I seems so and it makes a sense. Agile methodologies are good for early feedback and changes, but you can't define what will be delivered, when and for how much beyond one sprint. It can be used for development of product and internal software, but there is no place for any agility in your case, when everything has to be approved in advance.
    – Michal Krasny
    Mar 31, 2021 at 7:32
  • 1
    Who determines if the project was a success and that payment will be made? Is that Microsoft based on ticking off the original SOW, or the Customer based on how satisfied they are with the product?
    – Bart van Ingen Schenau
    Mar 31, 2021 at 7:32
  • @BartvanIngenSchenau customer needs to inform Microsoft that the project was a success. This exactly is the tricky part here. According to Microsoft guideline, the solution must only be based on the SOW, other things are out of scope. SOW was prepared upon customer agreement. But after the first demo in 2 weeks, customer wants a few changes need to be entertained. I assume, the blame is on our team since we mistakenly used agile in a wrong concept. But I just want to know, if it is correct that agile is not totally not applicable here and if the waterfall is the only way fitting for this.
    – i_hate_microsoft_slate_program
    Mar 31, 2021 at 7:45
  • @MichalKrasny Microsoft didn't give any recommendations on the methodology, but since the management of the organization felt that they are too strong in Agile (perhaps a confirmation bias) the project was carried out in the agile methodology. But apparently Microsoft requires SOW (which can't be changed) and have a fixed timeline for each phases. So this automatically makes "waterfall" the only way out to build such product.
    – i_hate_microsoft_slate_program
    Mar 31, 2021 at 7:47
  • You need to ask the customer what they are planning: if they will report to Microsoft that the project was a sucess when the solution follows the SOW in a 1:1 manner, even if that means to ignore their change requests, of if they would prefer to get their change requests fulfilled to give a positve report.
    – Doc Brown
    Mar 31, 2021 at 9:55

2 Answers 2

Reset to default
1

Formally, this is a fixed-scope, fixed-time project, which is not where agile development methods are best suited for. But it is the kind of project that contracting houses like, because they can build something, deliver it at the deadline and wait for the inevitable change-requests. Those will then be charged at a premium.

I am saying that it is formally fixed-scope, because the party awarding the contract based on a fixed SOW is not the same as the party wanting the final product, the latter decides if the SOW is fulfilled and you are actually also in contact with them. This means you can actually be more flexible in handling the scope, as long as you make sure you meet the deadlines.

So, you can work in an agile fashion, as long as any change requested by the customer can be negotiated that an equivalent amount of work gets taken out of the original SOW, so you can still keep the same number of sprints. And they should agree that they give an honest report to Microsoft about the success of the project and not just tick off the original SOW without consideration for the requested scope changes.

Improve this answer
0

First, understand that whatever else “waterfall” is. It’s not evil.

It’s also not agile. The biggest difference between them is how they react to changing requirements. Agile is wonderful at reacting to changing requirements because it keeps the feedback loop tight.

Waterfall is wonderful at discouraging requirements change because it focuses on the documented requirements of the past. Not requirements based on what might be desired today. When this is understood it encourages getting the requirements right the first time.

Agile embraces change but that isn’t free. Every 2 week sprint is another set of pay checks. But agile can have 1 week sprints and get you more feedback in the same time box.

Having a fixed time box isn’t what makes the difference here. Both work on a budget. Waterfall shines when nothing surprising happens. Sprint shines when we’re all learning something new.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.