Following results of recent Version One survey regarding Agile importation in the world companies we would like to return to a question that many ask themselves even right now. What’s all this fuss around Agile about? Is Waterfall a wrong approach? How to understand, which methodology to choose or to stick to? .

Ok. Let’s start tackling the questions one by one.

Is Waterfall a wrong methodology to approach a project? No. It is not wrong by the fundamentals. Perhaps there something from where it originates. It is not an IT specific methodology. Rather an adaptation of particular approach to the process of product delivery taken from the other industries. Like in a traditional product, gathering requirements and designing takes place before the manufacturing, here, coding.

The main challenge that could be seen from the beginning was the singularity and sequentiality and risks it bears. Talking specifics - a long time it takes to deliver ready product to the client and problems related to the potential for general failure. What do I mean by it? Because it is not uncommon for customers to know 100% accurately what exactly they need, to every dot, it can turn out they will receive a product that is in best way not matching given requirements or scope. It can just create a project that is a failure. Why let’s go to the first argument, long delivery time. It comes from the fact that all the project phases are coming sequentially one after another. Each takes time to proceed and deliver a result. Conception. Analysis. Design. Planning. Coding. Testing. Secondly, with the timing comes risks. One of 3 problems can appear on our path to success.

  • A) The poor visibility of the outcome. Usually, no sooner than when the project hits the coding part, someone realizes that the requirements or expected results are not clearly defined, and there's a problem about how they are stated. Maybe they are too fluffy. Maybe there are contradicting requirements. Sometimes, it is just the factor, which there is no way to see flaws in the design until the project entered coding phase or later. Time to precise the requirements have to be short and fit at least within the budgeting year if not shorter. Based on the researches and post-implementation surveys the main reason for the failure of IT projects are wrongly specified requirements and the fact of deciding upon them “on the way” while building the product. The reason has not changed since last 40 years!
  • B) The risk of low quality. When project budget and dedicated time is running dry, it is usually in the last - Testing phase. Hence, to deliver on time, tests have to be cut off, and quality suffers.
  • C) No maneuverability. In other words, the problem to adjust to change. Either following voice of a client who just now realized what he really needs or by encountering a complicated problem, with the lack of resources. Both like to appear in the last phases of the project where to deliver remaining 20% of solution eats 80% of resources and time. It comes from the fact that by the end of development, all new features, changes or updates come with much higher costs and takes more time to rebuild or modify the source code when it is already well integrated and advanced.

That being said, still, there are projects and systems that just cannot be run using Agile. These are Safety Critical Systems. These are systems operating in banking, automotive, aviation, healthcare and so on. Here every piece of the system must be able to be specified and be able to be audited. For such projects code that is not finished or low quality could result in potential serious damages, harms or losses. Those companies cannot afford such risks, even if the product will be developed and delivered slower.

Waterfall also has its advantages. It is well structured and described so for most of the time clients know (or should know) exactly what they will receive (at least by their requirements). Each step is well documented and described by analytics, designers, developers. Thanks to detailed analysis and documentation, the project is safe from employee turnover. Moreover, many clients find its detailed record of activities and documentation reassuring. When client and contractor focus on the outcome, and speed is not a primary factor, Waterfall may be a better approach. The singularity of the development process is also much simpler to present and understood by the business (non-developer) roles in the organization.

Agility - what started in 2001.

Agile evolved out of many various lightweight software philosophies that take roots in the 90s as a counterpoint to a heavyweight waterfall. The Manifesto for Agile software development, written in 2001, shows the emphasis on value delivered to users, communication, and feedback to progressively create a product.

Agile-vs-Waterfall.jpg

How is Agile different? It takes sequences as a core implementing incremental, iterative approach to product development. Each step consists of all the product phases - Analyze. Design. Code. Test. Instead of planning and designing all the product up front, it concentrates on creating and producing minimum viable products delivered in short time periods. Every iteration brings progressive improvements to the products or new functionalities. The project is executed by cross-functional teams that are primarily self-organising. Apart from designers, analysts, planners, developers, they include "project manager" roles and supportive functions, as well as business representative - the product owner. Each MVP will be demonstrated to stakeholders, and their feedback is incorporated into the next or future iterations.

agile-waterfall-old.png

Can you already see how is Agile approach 'better'? Advantages of Agile.

Firstly, quality of the outcome improves because testing starts simultaneously, not in the last phase of the project. Secondly, visibility of the final outcome improves because you are half way through only when you have built half of the required features. Also, thirdly, thanks to tightening of the feedback loop, the risk is reduced, and what is more, your clients will be happy because they can make changes to the project without paying excessive additional costs. It sums up with the first point allowing to improve the productivity of the Agile teams. By giving flexibility to developers, often, as people coding their way through the user stories, they can solve problems easier and faster. Last, but not least, it offers faster time to market and in the case of change needed, shorter time to adjust to the situation.

agile-reasons.png

These are not only general points. In the VersionOne's report, there is one particularly interesting question "Why did you choose Agile in the first place." Most important - "Accelerate product delivery" as said by 69% of respondents, "Enhance ability to manage changing priorities" - 69% of respondents, "Increase productivity" - over half of respondents (53%). At four place in the rank ad ex aequo - "Improve project visibility" and "Enhance software quality" selected by 42% of people who took part in the suervey. At six point "Reduce project risk" - (as chosen by 37% respondents).

Let me state one thing: Agile is not a silver bullet. It is just an approach, or in other words a tool. If taken by inappropriate hands, say, inexperienced project manager it can slip out of budget control, and turn to pure code sprints. Add unclear understanding what the client expects, and some level of fiasco is easy to foresee.

agile-benefits.png

Disadvantages of Agile

Let’s talk firstly about down sides of Agile. As we mentioned earlier, it required custom involvement. For some clients might be not interested in participation, simply because of lack of their time, or interests. As engagement is great for the project overall, it might also bring some potential problems. It often leads to additional features requests, which adds to the cost of implementation and delivery time.

From system engineering point of view, as experts point out, the iterative development may lead to a frequent code refactoring in case the full scope of the system is not matching its initial design model and architecture. If skipped, product risks lower quality. This problem is more visible in the highly integrated systems or greater implementations. Again, this adds to overall costs. Also, limited time sprints and changes in features priorities can lead to delay in delivery or additional sprints, beyond the planned one.

Agile brings challenges to overcome.

In a traditional approach, required system functionalities can be divided into pieces, and each dev team even the distributed one can start working on their part of the system. It brings us to the central challenge that is quite evident. Developing product piece by piece, with the possibility to change or refactor the code on the way, Agile methodologies requires full team dedication and coordination. However, it is just a matter tool you have to use. Both for communication - like Skype, messengers, Slack, or collaboration on tasks, documents.

Ok, Now we know where we are standing.

To sum up. Faster time to market, shorter reaction span for changing situation (on the market, change of business goals, etc., you name it), clearer outcome and higher quality of end products after all.

Few closing words. Agile is also just a step toward more lean and flexible approach to project management. It is not something that you install from the box, and it just works. From the wide range of methodologies and methods, you pick the one that will work best for your and the project your organization is currently running. Then, it is a process. You excel only when working on it and scaling your operations. Moreover, it requires not only change in approach to a project but often changes in organizational culture, team structure and additional support - of external or internal Agile coaches (experienced practitioners of Agile methodologies), support and sponsorship from Executives, as well as implementing the right common tools among the teams.

Regarding the methodologies, according to the 11th State of Agile, the most popular one (68% of organization) are still Scrum (58%), and Scrum connected with Extreme Programming (XP) (10%). Later down the charts, we see Scrumban (8%), Kanban (5%) and hybrids models (8%).

There is also one methodology leading to more flexible and fruitful team collaboration - DevOps. VersionOne’s report indicates that “71% of respondents stated that they currently have a DevOps initiative (50%) in their organization or are planning one in the next 12 months (21%).”

For more interesting conclusions I invite you also for summary made by Leanintuit team, which took a look at all nine years that the survey is running.

For those of you, who are busy -- TL;DR:

Neither Agile or Waterfall is a magic recipe that will take the client's expectations and deliver a box with the product, solve all problems on the way. Right approach depends o the project, clear definitions of requirements and attention paid to the project throughout its journey.

Share your opinion and on choosing the right approach. What are your thoughts on the project management methodologies? Which one do you find successful in your organization?