18

Really good question. Really hard to answer. Here is my two cents contribution. Agile showed up as a response to the practices of the late nineties for building software, practices that assumed you could define everything upfront in such detail and plan them out such that it was then just a matter of following that plan to reach a successful outcome. But ...


14

TL;DR Trying to "future proof" your data is done by making your tools, processes, and data structures flexible, not by fixing them for eternity. You do this by embracing test-first database design, ensuring your data is normalized and extensible, and that your tools and processes support change. You do not accomplish this by treating your data or ...


10

The agile approach does not necessarily imply shortsightedness. Depending on the problem domain, you may have a very complete understanding (in your example, the industry exists for quite some time, has best practices, etc.) or a very limited understanding (such as a novel idea for a social network). Very complete understanding It would be foolish to throw ...


8

How should a PM reconcile the wish to deliver something quickly, which may require extensive rework to add functionality in the future, versus doing extensive design up front then being able to develop all of the functionality quickly thereafter, with minimal rework? This is the question at the heart of agile. You could rephrase the question as: Is the ...


4

The safest answer for any software development work is to start and continue incrementally (doesn't have to be Scrum though). There are some bigger questions implied by what you have said. It's frequently said that "rewriting" an application is one of the things you should never, ever do. Don't start with an assumption that you should have a new ...


2

I don't have a ton of experience with reimplementing/rewriting an existing application from scratch, but the experience that I do have tells me that you probably don't know 80% of the requirements and use cases. Maybe you know 80% of what the existing system does, but there are still plenty of unknowns. Maybe the existing application has defects or ...


2

Many similarly-structured projects – where legal contracts hold sway, adopt one or the other of two strategies: (1) Formal Change Orders: The parties must expressly negotiate each change to the contract. (2) Formal Burn-Limits: The parties may informally bargain within the scope of the contract so long as the total amount of money spent doing so does not ...


2

As per the wording in your question: And I got a feedback that solution design is approved but under one condition!! That to add 3 points from the last document I did analysis for. So it sounds like they have recognised that that their request is bigger than the original scope, and yet they want it for no additional cost. This should be seen as an ...


2

If you have a change process defined, and your customer is sidestepping the process to squeeze scope in without paying for the impacts, then you say no. You're a party to the contract and you get to say no if you think the contract is being violated. It's the job of the PM. EDIT to address comments: They are right to say the change is needed...if indeed it ...


2

Why do you want to reject what the customer is asking? If your contract or your way of working obliges you to turn away work that the customer wants and is presumably willing to pay for then perhaps your business model is broken and that is not the customer's fault. The second thing to think about is that on any project (I'm assuming software development) ...


2

You are building an entirely new application. The fact that you have access to an existing application which serves the same purposes using different technology will benefit you only to the extent that it illustrates the problem that is being addressed. "Desktop" applications use an entirely different architectural approach than "web" ...


2

TL;DR Keep in mind that no framework or process can guarantee success. However, an agile framework will allow you to adapt more rapidly, and to "fail fast" if the project is not going to succeed as initially conceived. It will also provide more flexibility in determining how to implement the desired system behavior on a new stack, which is ...


1

Rewriting and re-designing a desktop application into a new Web Based application with new technology ==> That probably means not only coding, but also setting up your infrastructure, development stack, user roles, etc. Learn how to work agile. You can partially do that as you go, but you have to have your entire company aligned on the method from the ...


1

The Project Management Institute uses the terms predictive and adaptive for project life cycles. A predictive life cycle is all about long term predictability and controlling change whereas an adaptive life cycle emphasises responding rapidly to change. Iterations are almost inevitable for any kind of software development life cycle whatever you call it, but ...


1

I'm not sure about a formal definition, however I would tend to use the term "Waterfall with multiple phases" for the model you are discussing. My experience of these is that you plan in more detail and with greater accuracy for the first phase than any subsequent phases, and refine the plans for the subsequent phases as time goes on. In terms of a ...


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