It's been long since I first went into University, for studying Computer Engineering and things have changed a lot over time, but not always for the good, I guess.
During the first years, we were taught general sciences, programming, problem solving... And slightly after that, the classic project lifecycle. We didn´t come into project management, but we knew the classic lifecylce phases and project structure. Viability documents, analysis, requirements, technical design... The waterfall approach at its best.
You are taught that every stage is like a blackbox, sandboxed and has well-defined interfaces that link the phases together. Everything is clear and tidy; nothing can go wrong, right?
We you start working with this approach, you'll sooner or later realize that it's far from being perfect. Some times it's even unusable and some of the premises are not even true!. For this method to work, every participant in the project (including clients and suppliers) must be exactly in the same page and know the whole system, so nothing can come after a phase is closed. So, when taking to the real world, it just doesn't fit.
Most of the times, the picture is much like this one:
After suffering this incoherency, some clever people came up with new approaches that are widely used nowadays, under the common name of agile methodologies. I myself am certified SCRUM Manager and it's been of great help during the last years.
However, I've found an alarming amount of engineers that are "agile extremists" and don't see the risk of completely eliminating traditional methods. This sums up to the overwhelming amount of new startups, born from the ideas of non-technical people that want immediate results in order to try to rise money. MVP (Minimum Viable Product) is a key word in the startup world and the fastest way to get to them is thru fast prototyping.
I've work in both a methodology strict company, which complied and applied a big bunch of methodologies like Prince, ISO 9001 and 27001, CMMI3 and ITIL and in a company with no methodology at all. This last one could be a extreme example of Lean and how it shouldn't be. Even though I've never been a friend of documentation, I have to admit the first one worked better. However, it started to work at its best when we re-defined the traditional waterfall stages as a cycle, with the introduction of SCRUM.
The major risk is, in my opinion, when you try to manage your company in an "agile" way. You have to be quick, you have to be nimble and you have to be agile, but before it all, you need to know where you stand. It's a common error I'm seeing very often, when a startup with non-technical founders, want to have a MVP as soon as possible and, for doing so, they look for developers, so the product is done ASAP.
It doesn't matter how senior a developer is, the first thing a technology-related startup needs is an architect. Someone with a wide and long-term view to set the basis. It doesn't matter much how you implement it, whether it's JAVA or PHP, Rest or SOA; after all, most likely you'll have to re-engineer your project in a 10-year timeframe, but your product has to be thought before it's done.
Every company need a backbone and a structure and a manager cannot be improvising because the company lacks a method. So my humble advise is to take agility with a grain of salt and use it when it's effective: in the production cycle. Be agile, but don't be extreme.
However, I've found an alarming amount of engineers that are "agile extremists" and don't see the risk of completely eliminating traditional methods. This sums up to the overwhelming amount of new startups, born from the ideas of non-technical people that want immediate results in order to try to rise money. MVP (Minimum Viable Product) is a key word in the startup world and the fastest way to get to them is thru fast prototyping.
I've work in both a methodology strict company, which complied and applied a big bunch of methodologies like Prince, ISO 9001 and 27001, CMMI3 and ITIL and in a company with no methodology at all. This last one could be a extreme example of Lean and how it shouldn't be. Even though I've never been a friend of documentation, I have to admit the first one worked better. However, it started to work at its best when we re-defined the traditional waterfall stages as a cycle, with the introduction of SCRUM.
The major risk is, in my opinion, when you try to manage your company in an "agile" way. You have to be quick, you have to be nimble and you have to be agile, but before it all, you need to know where you stand. It's a common error I'm seeing very often, when a startup with non-technical founders, want to have a MVP as soon as possible and, for doing so, they look for developers, so the product is done ASAP.
It doesn't matter how senior a developer is, the first thing a technology-related startup needs is an architect. Someone with a wide and long-term view to set the basis. It doesn't matter much how you implement it, whether it's JAVA or PHP, Rest or SOA; after all, most likely you'll have to re-engineer your project in a 10-year timeframe, but your product has to be thought before it's done.
Every company need a backbone and a structure and a manager cannot be improvising because the company lacks a method. So my humble advise is to take agility with a grain of salt and use it when it's effective: in the production cycle. Be agile, but don't be extreme.
