Agile as a bottleneck

Unavoidably, every company needs to have a process in place for a successful software development lifecycle. It seems that the majority generally acknowledges that Agile Development could be very efficient. However, only the minority seems to acknowledge that their environment might not be suitable for applying the agile process. Environments are not all the same and when you start treating them in such a way, then you eventually hit a bottleneck of inefficiency. Different teams inside the same environment behave and function in their own unique way and that’s a fact. Teams are formed by individuals with diverse experiences, habits, opinions and skills and ideally all together should come in harmony. Only then, you could talk about real productivity and efficiency. Imagine now when on top of an already very complex task (e.g. build team’s chemistry), you try to apply a model called agile, the wrong way. Disaster!

The question that logically arises now is what does the wrong way mean in every occasion. Obviously, there is no definite answer to that question and it simply depends. There are so many unique factors for each occasion, that would be at least naive to generalize the answer. Nevertheless, there are common mistakes made while applying agile, which as a result lead to the misusage of a model that was only meant to help and simplify. It is at this point that someone should reconsider the truth behind the “quote” about theory and practice, as it becomes priceless:

1. Unnecessary tools & Processes

As the manifesto states, agile is supposed to favour personal interaction against tools and processes. Most of the companies invest in very expensive tools that are heavily used daily. A very time consuming process that has no real benefits (only capturing context), and it extremely slows down development. Serious side-effects of the usage of such tools: days or even weeks of continuous planning for reviewing the captured context, several hours spend for keeping context up-to-date, multiple tools for the same purpose and so on …

2. Lack of architecture

Avoiding to document in thousand of pages every single detail of the product’s architecture is desired. It completely aligns with the agile manifesto, which it instead proposes working software. However, the manifesto does not state: neglect documentation! A properly structured document for capturing clearly the product design and all the architectural requirements is a fundamental ingredient if you want to build any complex system that is scalable, extendable, testable, easy-to-understand and offers maximum levels of quality. Otherwise, you are just looking at pieces of code that were forced to co-operate successfully.

3. Defined roles & Hierarchies

Although agile sets the principles of customer collaboration and responding to changes, wisely avoids to explicitly define the roles and the hierarchies, which will be required to achieve these two goals. Someone could argue that the process has already a defined structure for roles and hierarchies, such as small scrum teams, scrums-masters and tech-leads, but that is at best inaccurate. These are just suggestions for achieving certain goals and if they are proved that they are indeed working on your environment, then you probably should adopt them. If not, you need to define your own successful model of roles and hierarchies, which will allow you to use agile as a concept, rather as a strict process that you have to blindly follow. Using the suggested roles, hierarchies, tools and processes for being agile, does not make you agile. You need to respect the agile manifesto and find your way into it.

4. The illusion of control

There is the perception that applying the agile model gives better control over other software development processes and makes things easier to manage. That is only partially true, as it assumes that agile process is not broken or misused. Therefore, most of the time it gives the illusion of a fine grained control, which only adds an incredible overhead on the development lifecycle, with no meaningful value. Certainly you get all those nice to have, but no product life threatening control metrics. At this stage someone should really wonder, if the Fibonacci numbers for sizing, the burn down charts, the special templates for the definition of done, the time consuming planning sessions and having 8 different states for a defect, are the mechanisms for controlling better the development. I doubt!

5. Decision making & Consequences

Agile manifesto does not mandate any specific approach for decision making. Nevertheless, the responding to changes principle, requires someone to continuously determine the priorities and the absolute necessities for the product. If someone is desperately changing the decisions based on the customer’s input, third party dependencies and commitments for new feature enhancements, it is likely to fail. Allowing a certain level of flexibility is desired, but it should be always inside the feasible boundaries of the team’s capacity and what it can be delivered without accepting any significant trade-offs that they risk to harm the final product. Therefore, someone should have the authority to simply say no to changes when needed, while weighting all the potential consequences. A product delivered on-time, fully working, feature complete (initial commitments is the metric) is much better, than a product overloaded, delayed, with a higher risk for lower quality.