At a time when market pressure and the need for increased competitiveness in all economic area are becoming increasingly stringent, IT industry has its own particular place and plays a very important role that can make the difference between the companies which are going to be sustainable and successful in the coming decade, by investing in innovation, research, process efficiency and those which are settling for what they are doing at the moment, thus risking to disappear from the market.
Against this very dynamic context, one in which one certainty is continuous change and adaptation to the new market trends, the challenge for the IT field is to carry out its activities in the most efficient manner, with as fast as possible market deliverables, with the best quality, which would maximize the shareholders" investment.
Obviously, from the point of view of the full life cycle of a software solution delivery, an agile approach may seem the best choice in most situations that aim at the benefits described above. A recent study (by Agile Journal) shows that over 88% of the assessed software companies (many with over 10,000 employees) are already using or intend to use agile practices for the projects they are implementing.
What usually happens in most of the companies is that they begin their agile experience by adopting the Scrum-related practices - which describe a very useful strategy for managing the activity of a development team. Unfortunately, Scrum represents but a small part of the delivery of a final software solution. What happens in most cases is that the teams start looking left and right, sometimes by their own efforts, sometimes with the help of consultancy companies, in order to fill the gaps that Scrums ignores by default, the ideas searched for being mostly connected to the building aspect.
It may happen that the multitude of existing sources and the terminology used create more confusion rather than leading to the expected results. More than that, not even the IT professionals know exactly where to look for advice useful for their situation and which problems should be handled with priority.
For example, Scrum talks about the existence of a Product / Scrum backlog, and how these are handled during a sprint. But nevertheless, the question is: where does this Product backlog come from? Does it come out of the blue in the project? Of course not; it is the result of a session in which the initial requirements are identified, requirements which represent one of the main objectives that we must reach in the initial phase of a project.
The solution we are implementing at Yonder is one focused on an agile approach, disciplined by offering procedures / advice adapted for each client / project in turn. Discipline consists on one hand in a sequential and iterative approach of the project (where one aims at reaching certain objectives throughout the entire lifecycle of the solution delivery) and on the other hand in offering concrete advice for reaching each objective (according to the project context).
This is only possible by adopting a number of Scrum strategies - XP, Agile Modeling, RUP, Lean/Kanban, DevOps in a structured manner and it avoids a prescriptive application of well-known recipes - because there is always the risk that these might not match the project context, and we focus on reaching certain objectives.
The basic idea is pretty simple: we have to deal with an approach based on concrete phases (Inception, Construction, Transition), and within each phase there is a series of well-defined objectives which must be reached. For instance, one of the objectives of the Inception phase is identifying the initial (functional) purpose of the application. The structured approach is based on the description of several aspects or processes which enable the fulfilment of this objective. For instance, in the case above, the aspects / processes that must be considered are the following:
According to the context we are in, we will choose for each process the version that best suits the current needs of the project - if the project is one where we need to provide support as well, we can choose a work item pool as a manner of working requirements management instead of a scrum product backlog.
In order to make sure that these objectives are fulfilled, we introduced milestones all throughout the duration of the project. A real-life example of such a milestone is the ending of the Inception phase, where we check for consensus of all parties regarding the initial purpose of the application.
One of the greatest challenges of this approach is, on the one hand, to make available as many procedures as possible connected to the manner in which certain objectives may be reached, and, on the other hand, to avoid becoming very prescriptive. The existing methodologies at the moment are either very detailed - when it comes to the processes it involves (see for instance the IBM RUP case), or describe in a sketchy manner important activities from the project"s lifecycle (see Scrum for the part of identifying the initial requirements or the installation of the solution into production).
By applying these principles in all the projects we are developing at Yonder, we have managed to increase our clients" satisfaction level, the increased productivity being one of the aspects that made this possible.
This objective-oriented policy increases by a great margin the degree of transparency in our relationship with the clients, expectations being set and monitored accordingly throughout the duration of the project. Through the ongoing validation of the "business case" and of the initial conditions that generated the project - multiple milestones in the Construction phase - we are making sure of its viability and we make available to the decision factors all the information required so that the decisions being made are based first and foremost on real numbers and facts and less on assumptions.
Another important aspect connected to quality increase (which at first sight seems to be a rather subjective component) by adapting the best practices from the agile methodologies (XP, TDD) in order to meet certain objectives and to migrate them towards a measurable area. Given the current trends of working with large teams, geographically distributed, activating in complex fields with technical solutions that are the same, another important aspect is scalability.
Using this objectives-based approach, within which team independency is encouraged, we are maintaining an optimum level of governance. In this case, the aim - beyond the deliverables connected to the software development process - is offering a complete solution in which the needs of the client are addressed according to their specific situation. Thus, we can lay the basis of a model that can scale easily by using the adequate tools, the success methods and practices proven by other projects.
This disciplined and structured approach of Agile projects that we have adopted at Yonder, especially after obtaining the CMMI level 3 certification, has helped us to increase our client numbers, due to positive results and examples, service professionalization and increased predictability by applying and continuously improving this model.
And, in order to prevent those who are interested to go again through a process of re-inventing the wheel and of re-discovering all of these practices empirically, the way it happens most of the times - a very good starting point of the journey towards the implementation of an Agile framework is Scott Ambler and Mark Lines"s book "Disciplined Agile Delivery".