Grey Areas in Agile (Scrum)

I am flabbergasted by Udemy. Udacity as well. (Khan Academy too!) I am just going ahead and taking up every small little course which is/was someway related to my work. I was missing those well organised professional course materials for a long time after I moved out from one of the employers who gave us a good learning opportunity. At some point I had accepted the fact that I am never going to get that kind of learning experience back. But years later, I found Udemy, Udacity and Khan Academy. And I am loving it.

Last two days, I went back and took some courses on Agile. Agile, I had picked up on my own around five years back and my first experience with Scrum was with implementing it for our own company which was into services projects. When I found courses on Agile on Udemy, I thought, I should quickly do some courses on Scrum and Kanban to see whether there were things I would have missed out or could have done better those days. From those very basic courses I did, I realised that my implementation wasn’t that bad and from a delivery point of view, our firm was a well managed one. (Not from a budget point of view)

However, when I look back, these are the questions that I am still not able to answer when it comes to agile methodology. Even today I have not found answers to them. Listing few of them here so that if there are any experts among my friends who would be reading this, would like to hear their thoughts on these.

  1. Agile was introduced to ensure that the changes in the requirements can be accommodated even at a later stage in the project. Considering that fact, how do we control the “never ending projects” scenario happening with scope creeps in the name of “implied requirements” and better user experiences? Assuming that it is a fixed price project, how do we ensure that the budget of the project is not exceeded under such a scenario? (Is making your developers slog the only solution?) Adding a low cost resource could be a solution, however, considering his/her induction into the project, how do we ensure that timeline does not slip?
  2. Agile was supposed to empower developers as well. With the daily scrums, we usually see shouting matches happening between the clients, scrum master and development teams. What is the secret behind managing the clients (who is the sponsor of the project & is paying us!) who sometimes hijacks the whole process of breaking the project into sprints.
  3. It is also not uncommon to find clients who comes up with last minute changes in the over all flow of the software which can introduce several regression bugs?
  4. In cases like the above, many a times, we will see the end users not allowing developers to do the estimation. They would say, I need this “today”. How do we handle this?

I understand. My questions are not about the issues with Scrum (except for point 1 & 3), it is about the clients who are not patient enough to go through a software development process. But, isn’t that the case with the SMBs in almost every case or is it just the case with very small firms like ours? (I have seen this happening in bigger companies as well. Ofcourse, these are not concerns in the case of corporates where they mostly operate on billing/time and material model)

Would love to hear some thoughts from my friends who have executed services based projects on a fixed price model using agile methodology.

Edit: 5th Sept, 2017

Found an answer here:

Thanks to @Premith who asked me to read Mr. Fowler to find answers to my concerns.

“ We’ll collaborate together to come up with the best set of features to go live.” — That is the answer that I was looking for. I think it depends on the skill of your sales person to convince the client on this.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.