Project Scope, bloat and Agile methods

I feel I have been learning a great deal week in week out at my current job, the setup is totally different to what I have been in previously and to be honest is much closer to what I want out of a workplace environment. One of the big things I feel I have been learning is better project management and how Agile really helps keep projects in check and to be frank it is pretty great. I feel most people have the same problem you come up with a great idea setup the project and environment with a somewhat nebulas goal, often one that is far too lofty, as a result you will start get a few commits in and probably lose sight of the point of the project and give up and move onto something new. Now, abandoning projects for legitimate reasons can be perfectly fine, maybe you have learnt all you need from it and can walk away before getting stuck too far into something that is no longer providing a strong opportunity to grow and learn. Now I am sure we imagine we are all in the category however in reality few projects we do do fit here and generally we give up on projects because a) something else caught our eye like a sparrow with the next shiny thing, or b) we got bored of the idea and this is where the Agile idea I feel fits in fantastically. Agile is at the end of the day an unopinionated framework for getting work done, one of the big ideas behind Agile is to work for the minimum viable product, this is a great goal because once we get the skeleton assembled it becomes easier to add new pieces to it and we have a product that is actually doing something and gives us much more satisfaction. Another great reason to shoot for the minimum viable product is that provides a quick natural endpoint, maybe all you require is the minimum for this project, maybe you only want to add in a little extra, or you can easily expand it out and really build it out into something huge, either way Agile helps break up this huge task into small sections. I noticed on one of my current projects, working with graphQL how one of the API endpoints I was mapping was a bit more complex than the others and required quite a bit of additional logic, I dived in and to be honest found a fairly fine solution to how to work with it, however looking at it now as I was just prototyping that function it may work best to implement just a basic version of that endpoint initially for speed and after when everything is mapped and running I can start to handle that better, or even at a slightly later date. This roadblock did somewhat derail my progress and I feel this is exactly the point at which we start to lose motivation when we hit a bump in the road that requires quite a few steps to implement a suitable solution which somewhat takes you outside of the scope of the initial project, especially when you realise some packages have not been setup correctly and requires quite a lot of additional adding and updated package.json. Now it is of course fine to drive right in and come up with the functions and solution, it may only take a few additional days, however you are now trying to solve a different problem to what you expected to do with your project and for me I felt the motivation drop when I found that I had to setup my test runs correctly, rejig some dependancies and install additional dependancies just to test this function adequately, as implementing Test Driven Development is something I am also looking into expanding upon, it is pretty great in all honesty and it is really something that I am starting to like more. So I was thinking the Agile approach is probably, how bigger barrier is this? and Do we need the additional functionality now? Normally with issues like this you can see the tip of the iceberg but in reality they often require a decent amount of time spent to get them tidied up and sorted well, additionally I can move around this problem by just giving conditional requests initially and then automate the refresh later as it doesn't really break the overall. For me I feel the agile methodology is pretty great and the more I consider it I feel the more productive I can be as a result.

Last edited: Jan. 14, 2019, 2:43 p.m.