Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member183045
Contributor
0 Kudos

Things are changing faster and faster - you can hear this nowadays. Companies have to adapt continuously to the market and the customer needs which implicates that also the Software has to adapt on this environment.

Do the traditional approaches of Software development fit still into this environment? My opinion is mostly not, especially on Software projects which are related to the companies and market processes like ERP systems.

So what does this "Agile" thing can be helpful here. I try to give a list of some benefits.

Benefit 1: Decrease of project risk.

Especially in big projects it is between hard and impossible to ensure that the project goals are reached until there is a continous risk and status management.

Agile methods focus on continuously delivering entire features to a running system where all stakeholders can review them.

I traditional software engineering methods there is a specification phase, a design phase and approximately in the middle of the project duration the customer gets the first draft version to test. With this approach risk is high that till the middle of the project duration you do not notice that you are working into a wrong direction or that you are behind the schedule.

As the following picture demonstrates in a funny way the views of the different stakeholders of a project differ often a lot and there is no better way to bring the views togehter than showing the already implemented parts as fast as possible to the customer.

The different project views at the beginning of a project:

Source: ProjectCartoon.com

Benefit 2: Project duration is better manageable

In the traditional approach of project management there is a fix scope. But Projects do not run like initially planned, so you normally have the possibility to change the Cost domain, for example by additional developers or extra hours or the schedule by moving the project finish date.


The agile approach leaves cost and schedule fixed. That's of course desired by management (in budget and in time is mostly their primary focus). So if two of the three domains stay fixed the scope needs to be variable.


That means for example descoping the non essential features or to focus first only on the critical elements of the agreed use cases. (of course the skipped part have to be delivered afterwards).


The project management triangle - traditional and agile approach

But also if a project stays in time and in budget the possibility to change the scope has a lot of advantages. As a developer you can decide to bring in new ideas. Customer and supplier can much easier replace a feature in the scope because from the start of the project the fact that scope will change is considered. In agile approaches this is known as "change for free", which means that a change of a feature has not that much of additional cost like in traditional approaches as the functionality is not already fully specified and probably a lot of specification effort for features which are finally not needed is avoided.


Benefit 3: Immediate Feedback increases efficieny and effectivity

Nothing worse for a developer than you develop something and nobody evaluates it. First its not good for the motivation, second its not efficient. Its obviously much harder to fix a bug from something you developed three months ago than from last week. Agile methods are focused on delivering entire features fast to the customer, this also ensures that the customer is able to give you the necessary feedback to know if the things developed match the customer requirements.

Noticing that something is going into the wrong direction as early as possible is one of the crucial things in project management in my opinion. And in this aspect agile methods can contribute a lot.


Benefit 4: Avoiding water melon reporting

Nobody wants to be the first to say, that project is behind schedule. So especially in hierarchical structures everybody gives a slightly better view of the current project status.


Developer reports to the project manager: "The standard case is mostly working, but we haven't yet started with error handling"

Project manager reports to department manager: "The standard case is done, error handling will be next"

Department manager reports to general manager: "The standard cases are done"


Thus, often it happens that the project status is red in the perspective of the project members in the center of the project and green outside the project. Like a water melon.


Agile methods avoid this by creating facts by delivering only entire ready functionalities in small iterations (a view weeks). So if it is planned that to the middle of the project duration the customer has available 40% of the negotiated features and only 20% were delivered,  the project is behind - without a lot of possibilites to sugarcoat.

To summarize if done right agile methods have a lot of benefits not only for the developer but for the whole team.


What do you think? I am courious about your thoughts and experiences.


Labels in this area