Initially the project was planned to release after the full development of the product. But, at the UAT phase, we decided to go with Agile (incremental release). At the UAT phase, it was identified that the features are in a good & quantifiable shape to be delivered.
Is this a standard across other companies, to change the pattern mid-way through? Just wanted to find how other companies operates / how other program mangers react to it. Saving Changes...
Are you talking about adding new scope incrementally, or breaking what was just tested into chunks and introducing the chunks incrementally? If the features that just went through UAT "are in a good & quantifiable shape to be delivered," what would be the reason to not release them all at once? Maybe I misunderstand, but that sounds more cautious than agile.
There may be a good reason for it, it's just not clear from what you have shared about it. Saving Changes...
Let me rephrase.
The UAT was done / is being done in incremental chunks. As the UAT gets completed for every chunk, the business would like to release it. Saving Changes...
It might not fit the strict definition of a standard methodology or framework, but if the increments are usable and stable (and assuming adequate regression and integration testing), projects have been successfully broken into chunks longer than Agile has been a buzzword. If what is delivered works and provides business value, it's a good argument to continue. Weigh the pros and cons. Saving Changes...
This feels less like an agile approach as the bulk of the work effort has already been expended and rather just a phased approach to completing user test activities and releasing functionality.
Not very common, but I've seen it occasionally.
I'd see this as more incremental than agile.
Kiron Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Agree with where Kiron is going. Seems to be of an incremental release approach than anything else. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I have to do that recentrly in a hugh project because the product was to fullfil goverment regulations and the country situation "explode" then you have to activiate the use of Agile practices at UAT. Take into account I am saying Agile practices, not agile based method/framework. Then we use things like incremental-iterative life cycle for UAT, items backlog, kanban board as visualization method, burn down charts. It works well. The important thing is to stay clear about what agile is: a way of thinking and behave with focus on client, value and quality. With that on hand you can use the tool/practice that best fit for your current situation. And that´s not mean you have to change the culture or things like that. At the end, is a matter of "survival". Saving Changes...
Testing and fixing defects is inherently an iterative and continuous activity. There is no substitute for getting users' feedback. So your team surely did the right thing. The question worth considering is why they didn't adopt that approach earlier in the project. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Would not call it agile either and I am not sure if it even is incremental (you are not going back to requirements I assume).
I have seen this happen several times, and it was due to have an initial scope of 100% and at some time (say during testing) you find out there is a problem with cost, milestones and/or quality. So you strip off some of the 100% and a agree in a release 1,2,3 or so. Saving Changes...
John SpitzerProject Manager| Stanford UniversitySan Jose, Ca, United States
Not every project has a "big bang" release at the end. Many times it is phased, especially if you have a program where work may be coming into the program from different projects. I have found it not uncommon for large, longer project/programs, to have multiple release/deployment cycles that are dependent on major completed functionality. This might also align, for example, with various classes of users, where work is completed for that class of user and released only to that class of users. This might be done before the final release of the product.
I have to agree with Thomas and others, do not call it agile. It is the buzz word that many sponsors want to use for anything that is not traditional waterfall. The second word is iterative. But there is little understanding on how it applies in context to Agile/Scrum, etc. methodology. If you call it Agile today, moving to a more pure Agile method later just becomes that much harder.
Also, I have not seen a project that was not iterative, even waterfall. Even in the waterfall methodology, there is elaboration and iteration throughout the project. The biggest driver is to provide value to your customer. Incremental releases after something has been UATed, is just delivering value, maybe a little earlier, to your customer. Where I would be a little cautious, is how to handle support or new requests that come in from the user base as it is enlarged (e.g. after new functionality is released to the general user base). Setting up and agreeing to those boundaries/policies with your sponsor is key. For example, it is added as new scope, it is work for the support team, it is added to the existing project or delayed until all of the initial scope is completed, lower priority items are descoped and these are slotted in, etc. If you are running waterfall, it is critical that everyone on the team understands this otherwise someone may get "bent out of shape". For example, the development team might feel that they are being "piled on" additional work, especially if there is no recognition or accommodation for the additional work. Saving Changes...
Community Champion
