theagileprince.com

In the beginning was waterfall, and it was flawed. Then along came iterative approaches, and whilst these delivered many examples of satisfied customers and project success, could the breadth of benefits initially claimed by Agile evangelists have been a case of slight overreach? Was Agile failing to address a growing perception its interface centric approach and focus on rapid delivery chose fancy yet flaky over scalable and resilient? Naturally, product managers were attracted to the speed with which they could excite customers with proofs of concept (PoC) that too often did not get re-factored for production deployment. The days of vaporware were gone as a working demo could be completed in the same time as a marketing PowerPoint. But is what is good for some customers good for the consumer? Many Agile practitioners I know lamented the pressure they were under to productise or deploy the PoC once the product owner had prematurely showcased it to executives or customers and over pr

What is scope creep? Scope creep, also known as requirements or feature creep, is the in-flight addition of requirements, expanded goals, rework or changes post build, to previously agreed deliverables. The lack of control and threat is often due to the fact an impact assessment is not done or the impact does not trigger the formal change control process. So if these types of changes are too minor to require management by formal change processes, how is it they may have such an impact on a project outcome? Of course project delivery is about delivering fit-for-purpose outcomes which often requires going above and beyond the call of duty to achieve customer satisfaction. This flexibility is part of the domain we operate in, so it sounds completely logical to accommodate small or apparently zero impact changes as required. Point one is definitely true, but the second is a value based proposition. In slotting in a minor change by working after standard hours as an act of goodwill,