Agile has been booming over the last 10 years, particularly among IT professionals and more recently also in other (mostly creative) sectors such as product development, innovation and some research sectors. If you do not yet know what Agile is, first read the link for an introduction.

Agile (or one of the currents within it, such as XP, Scrum, Chrystal Clear, etc.) could be called one of the few actual ‘innovations’ that took place within the field of project management in the past 10 years. The ‘old’ project management had its roots in engineering thinking, which in turn had roots in scientific management. Scientific management originated during the great industrialization at the beginning of the last century. The essence was that all the work could be divided into simple specialized tasks where you then measured how long each (sub-) task lasted, so that management and planning went so much better and productivity increased.

Agile and Scrum originated in the ‘creative industries’ and offers a solution for how to deal with fast and often changing activities, goals and tasks in a project. It offers a method to organize creative (thinking) work without an omniscient authoritarian project leader (who of course often does not know how to do it).

Applying the old principles to work that is determined (fixed result, fixed way of working), Agile and Scrum seems to work well with changeable work (thinking work!). That is why you will encounter even more ‘old’ project management in more traditional sectors such as construction or ‘old’ industry. For sectors where a lot of thinking takes place, such as with programmers and product developers, Agile is (usually) more appropriate.

The advantages of Agile

The supporters of agile promise an improved working method, among other things: reduced costs in (interim) changing project goals and / or project results, less stress and more job satisfaction with the project team (less overtime, less struggle, more ‘flow’), better schedules and decision-making, mobilizing more knowledge in teams, faster results by building and delivering directly, less overhead due to less documentation and other advantages compared to the traditional project management approach. It seems to be quite something. But how well do the promises work out in practice? After a period of more than 10 years in which Agile and in particular Scrum have found their way into many organizations is it time for an evaluation perhaps?

The disadvantages of Agile

Without the pretension of being able to have a full discussion here about the advantages and disadvantages of Agile, I would like to discuss an issue of Agile that we have often encountered at organizations we worked with:

The first characteristic of Agile is to cut the work into small iterations: timeboxes or ‘sprints’ (scrum designation). In such a timebox of usually one to three weeks, part of the project result must be delivered, for example a working database or a prototype of a new robot. Including the testing and assessment by the customer of the delivered goods. The big advantage of this would be that you detect errors faster and that you can make changes more easily. In the traditional project management model you first make an (extensive) design and you only test at the end of the project whether that which was in the original design document has actually been realised (more explanation can be read here).

The graphs of the costs that can be found in (almost all) books about Agile or Scrum look something like this:

What you see in this graph is that the cost of a change in a project increases as the project’s time passes. Logically, if you build a house and you decide in the phase of delivery that you want a garage under your new house, it is possible, but it is considerably more expensive than if you had thought of it beforehand.

Because Agile works with short iterations (after which everyone thinks again what would be the most sensible next step), the damage of a wrong choice is smaller. The chart from the Agile and Scrum booklets looks like this:

There are costs involved in making a change, but because everything grows incrementally, you (in theory) do not throw away so much work. Maybe only 1 sprint (iteration) is lost, but that is all. Because you test and deliver much earlier, errors and wrong decisions are also noticed earlier (in theory).

Although we agree that it is (usually), easier (cheaper) to change, we have also encounter situations in which a scrum team did not think (far enough) ahead. In one case it turned out after about 7 iterations that the architecture that was gradually developed in the Agile project did not meet the desired expansion of the Agile project in its entirety.

A salient detail was that these functionalities were already known at the start of the project and communicated to the group. However, it was decided not to think too long about a future-proof structure of the software and under the guise of ‘we do not do design, because we are Agile’, the project became completely stuck after 7 iterations (6 months of work!). The change that was needed at the time was just as costly or perhaps even more expensive than a change in the ‘old style’ project management methods. The graph that I could draw to illustrate this, which you won’t see in Agile manuals, would look like this:

Comments on agile

The above case is just one of a number of concerns that we have with Agile / Scrum. Without wishing to trash the method the method (in fact we are very enthusiastic, otherwise we would not give trainings in Agile and Scrum) there are quite a lot of reservations, objections and questions. For example:

• What about scaling up Agile projects? Despite initiatives such as SAFE, LeSS, Agility Path.DAD and ScrumPLOP to use agile for larger projects, the definitive answer remains how this should be done. The many scaled Agile methods still seem to be in a development phase and Agile seems to be more suitable for not too large project teams.
• What about combining agile teams with less ‘Agile’ workers as interface designers, content producers, followers (writing manuals), marketers, etc.?
• How is it that in the Agile teams we visit, the method is almost always only partly applied?
• If Agile is such a good method for teamwork, how is it that many Agile teams seem more like a group of individuals than cohesive cooperating teams?
• Why such a strong resistance to thinking ahead or making (sub-) designs?
• Why do you not have to make documentation for the software to be developed?
• What does a Scrum master do all day when he only needs to coach his Agile team and why is it a full MT position (according to the official Scrum guidelines)?
• What argument is there to process (parts of) the project in a process-based manner?

Agile = religion

I will repeat again that I am enthusiastic about agile, otherwise it may seem that this is not the case because of the critical tone of this piece. Extreme programming, Scrum and Agile in general have arisen as a response to many abuses in ICT projects in particular. It is also really thought up by programmers themselves. Abuses that every project worker knows: a planning must be forced “because it has to be done before a certain date”, project managers who can not write or read a line of code and of which it is not at all clear what their added value is to the project, have to work overtime to to find out that elsewhere in the chain the project will come to a standstill for months, customers who do not know what they want and / or do not dare to take decisions, specifications that are constantly expanding and changing (‘can you then also … “), To do too many projects at the same time (” because it all has to be done “) and finally often: sales has sold something that the technicians can not make at all (or at least not within the promised timeframe). It is not without reason that the automation guide found in a survey that 44% of the (IT) project staff had signs of chronic exhaustion.

Shifted power

Agile certainly has an answer to some of the typical project problems, but it also has a number of drawbacks (or at least question marks). The conversation about that or the research into it that is being carried out within organizations is difficult. After all (goes the prevailing wisdom), the Agile principles are wonderful, so what can you do to improve them? One of the objections could be that Agile can also justify non-commitment. Under the guise of “we are Agile” we come across employees who no longer plan, or record or test or budget. Or worse: organizations that apply Agile to projects that really do not lend themselves to an Agile approach such as the market introduction of a new product. Because ‘Agile is better’ (hipper, more social, more modern, more innovative, more fun, … you can fill in more adjectives yourself).

It is clear that by creating Agile teams, more power will be placed among technicians and programmers compared to traditional project management. In a well organized Agile team, it may even be possible that no project manager is needed. Newly obtained power is difficult to give up and the fear of this makes an open discussion about the (dis)functioning of the Agile methodology in practice sometimes difficult.

Click here for more information about our Agile / Scrum training.

 

Author: Wouter Baars