Agile was not working well in my current project, due to the requirements gap and short in resources. Is it be safe to go back to SDLC waterfal model to continue the project.
My answer is you use scrum process to get aanswer for your question.
Conduct a "Retrospective" with the team to understand
What went well?
What went Wrong?
What needs improvement?
Then you will have answer weather you need to go back to "Waterfall" which will change all wrong to right? or you need to take some actions so that you can still continue with Agile.
Hello Madhava
Great question. and two good answers so far.
I would add that it sounds like things are working great for you!
One of the things that most agile approaches try to achieve is to make the invisible, visible. and often that means making the ugly truths about our organizaitons out there for everyone to see.
these problems in our system were always there it is just that now they are visible and you can do something about it. If no one wants to do anything about it, then you have found the real problem. ;-)
Hello Madhava
Great question. and two good answers so far.
I would add that it sounds like things are working great for you!
One of the things that most agile approaches try to achieve is to make the invisible, visible. and often that means making the ugly truths about our organizaitons out there for everyone to see.
these problems in our system were always there it is just that now they are visible and you can do something about it. If no one wants to do anything about it, then you have found the real problem. ;-)
In my opinion it’s always easy to go back to the conventional SDLC methods. If your project has not progressed much and you feel the requirements cannot be granulized and prioritized then you can safely go back to SDLC.
But it would be good if you try to explore more possibility within agile like Create long iterations (duration) and follow waterfall in each iteration. This will give you flexibility of agile and comfort of Waterfall.
My first question is this: What business reason prompted you to consider agile? Is that business reason still valid? If it is, you want to consider debugging your project.
What is not working? Are iterations not working? Why?
Are requirements as user stories not working? I would determine how to make them user stories or smaller to make them work.
Is the cultural change not working? Ah, that's a problem. In that case, I would use a kanban board. Maybe even kanban inside iteraitons.
Are you doing retrospectives? If not, you need to. You need to understand what is going on and how things got this way.
I could go on, but I'll stop.
You have many choices for lifecycles other than waterfall or agile. You have iterative, incremental, or iterative and incremental. Agile is one form of iterative and incremental. Waterfall is one form of a serial lifecycle.
If you return to the business reason that prompted you to think of why you wanted to leave waterfall and transition to agile, maybe you will have an answer.
Of course you can go back. Maybe you want to go forward, differently.
My first question is this: What business reason prompted you to consider agile? Is that business reason still valid? If it is, you want to consider debugging your project.
What is not working? Are iterations not working? Why?
Are requirements as user stories not working? I would determine how to make them user stories or smaller to make them work.
Is the cultural change not working? Ah, that's a problem. In that case, I would use a kanban board. Maybe even kanban inside iteraitons.
Are you doing retrospectives? If not, you need to. You need to understand what is going on and how things got this way.
I could go on, but I'll stop.
You have many choices for lifecycles other than waterfall or agile. You have iterative, incremental, or iterative and incremental. Agile is one form of iterative and incremental. Waterfall is one form of a serial lifecycle.
If you return to the business reason that prompted you to think of why you wanted to leave waterfall and transition to agile, maybe you will have an answer.
Of course you can go back. Maybe you want to go forward, differently.
In my opinion it’s always easy to go back to the conventional SDLC methods. If your project has not progressed much and you feel the requirements cannot be granulized and prioritized then you can safely go back to SDLC.
But it would be good if you try to explore more possibility within agile like Create long iterations (duration) and follow waterfall in each iteration. This will give you flexibility of agile and comfort of Waterfall.
Hello Madhava
Great question. and two good answers so far.
I would add that it sounds like things are working great for you!
One of the things that most agile approaches try to achieve is to make the invisible, visible. and often that means making the ugly truths about our organizaitons out there for everyone to see.
these problems in our system were always there it is just that now they are visible and you can do something about it. If no one wants to do anything about it, then you have found the real problem. ;-)
Hello Madhava
Great question. and two good answers so far.
I would add that it sounds like things are working great for you!
One of the things that most agile approaches try to achieve is to make the invisible, visible. and often that means making the ugly truths about our organizaitons out there for everyone to see.
these problems in our system were always there it is just that now they are visible and you can do something about it. If no one wants to do anything about it, then you have found the real problem. ;-)
My answer is you use scrum process to get aanswer for your question.
Conduct a "Retrospective" with the team to understand
What went well?
What went Wrong?
What needs improvement?
Then you will have answer weather you need to go back to "Waterfall" which will change all wrong to right? or you need to take some actions so that you can still continue with Agile.