_Agility. All you need to know about the agile methodology

What actually is agile? How did it all start? What are the principles that characterise this working method, how does it differ from the traditional approach and how to manage projects in an effective (and agile) way? We present a set of information that every person associated with technology in any way should become familiar with. We hope you will find it valuable and recommendable. Feel free to comment or contact us if you have any specific questions

Agile – a new approach to work. Where did it come from?

I think everyone has heard of the “agile” approach to managing projects by now. But is everyone aware of the history behind the formulation of the rules related to this? Probably not – for those people, we will briefly describe how it all came about.

The idea of “agile” was created in 2001 by a group of developers who met at a ski resort in the mountains of Utah. Their goal, in addition to entertaining themselves and having a good time, was to discuss how to change the approach to the software development process. The need arose from the fact that the business had difficulty getting along with specialists tinkering with code; the application creation process was taking too long, changes in technology occurred very quickly, frustration grew and projects often failed or ended up providing a solution that was already outdated compared to competitors’ products. It became necessary to find a way to create software that takes into account many variables and that would allow faster application launch.

The problem was diagnosed as a bad approach to project management itself – it was necessary to introduce changes at the very foundation, i.e. at the stage of work planning. Back then (i.e. until the memorable trip to the mountains), the creation of software would be planned and carried out in the same way as, for example, building a house or putting a new yoghurt on the market. The schedule of work was drawn up, dividing the project into successive stages – without completing one, it was impossible to move to the next; costs were also estimated in advance and a specific budget was allocated; therefore, the customer had to communicate all the requirements beforehand, knowing that additional changes would introduce chaos and would be difficult to implement. Such an approach (the so-called Waterfall model) for projects with many variables, which are difficult to predict, simply did not work out.

February 2001 turned out to be a milestone leading to a change in the way development teams work. After turbulent discussions, 17 developers reached an agreement that resulted in the creation of the Manifesto for Agile Software Development, a list of 12 principles and the description of the general idea of an agile approach to managing programming projects.

Since then, almost 20 years have passed and a lot of content on agile has been created: publications, applications facilitating project management using this methodology, vlogs, podcasts, courses, training, certificates; the idea has been successfully implemented in many companies, facilitating the implementation of projects; its effectiveness and growing popularity are well presented, among others, by the data from the 2019 report:

*Initially, “agile” mainly referred to teams working on software creation and development and with time, the agile methodology was also implemented in other areas of the economy. An interesting example is the development process of the Gripen fighter plane by the Swedish company SAAB, conducted in accordance with agile principles:
https://www.scruminc.com/wp-content/uploads/2015/09/Release-version_Owning-the-Sky-with-Agile.pdf

See also: 6 Common misconceptions about Scrum methodology

New vs. Old. Agile vs. Waterfall

The new approach differs from the “traditional” approach in that it enables work in a scattered operation model – planning and fulfilling requirements are based on complete functionalities and executed by small, relatively independent teams; all in order to be able to put part of the application into use as soon as possible and then systematically test and improve it, as well as expand it with further fragments.  As a result, the time between collecting the requirements and putting the product on the market has been significantly shortened, although it is not equivalent to the completion of the project. Activities are conducted in a non-linear manner, which gives more freedom to development teams – they work within the framework of cycles (sprints) focused on delivering the next fragment of the application; an important change in relation to the waterfall approach is that the owner is able to make decisions on the direction of development on an ongoing basis by observing progress and in accordance with factors that appear or change during the project; planned activities are prioritised, so that the team knows which of them are the most important and first to be implemented.

12 principles of the agile methodology

The creators of the agile concept distinguished 12 main principles that define the basic rules of this way of working. You can find the most important concepts behind each of them along with a short description below:

1. The most important thing is the satisfaction of the client who is offered rapid implementation of systematically improved software – the agile approach must also be about providing high quality services and fulfilling customer requirements; the change in the approach to project management was aimed at establishing a better understanding, more efficient cooperation and clearer communication with the client, and the ability to quickly show the results of work.
2. Be open to changes, even at a late stage of a project – the technology industry is changing very dynamically, so changes are necessary to remain up-to-date in terms of market requirements; the other issue is that the client is often able to clarify their expectations only after seeing the first effects. The agile methodology was developed in opposition to the rigid waterfall framework.
3. Systematically deliver the subsequent parts of the system; the more often you do it, the better – this allows the client to quickly provide information that will help improve the application and streamline the project.
4. Business and development teams need to work together – and this is not about sporadic contact, but regular, close cooperation thanks to which each party is involved in the project and knows about current activities. Divisions between teams need to be removed as they block creative collaboration between specialists in different fields.
5. Centre projects around motivated individuals, support them, trust them and provide them with what they need to implement the project – every project, especially a long-term and labour-intensive one (and these are the characteristics of development projects), needs a dedicated manager; one that will not “feel good” about the project, may manage it properly but certainly will not make the most of the capabilities and potential of the team.
6. The best way to convey information is to talk face-to-face – it’s hard to disagree with this! E-mails and communicators are very convenient, but direct contact always leaves the best impression and is the most fruitful.
7. Functioning software is the basic measure of work progress – effects are always determined by results, not by the process itself. The agile methodology, although distinguished by its flexible approach, puts as much emphasis on the execution of tasks as the traditional approach.
8. Agile processes support sustainable, durable development. Sponsors, developers and users should work at a steady pace – this principle applies to the teams involved in the project; thanks to iterative action (iteration is one work cycle involving the introduction, testing and improvement of a given part of the program), the team learns very quickly and at an early stage from its mistakes, draws appropriate conclusions and smoothly moves on to the next elements; it is not recommended to change responsibilities of individuals or sub-teams, as it disorganises work and slows down progress.
9. Continuous focus on technical excellence and good design strengthens agility – the agile methodology puts an emphasis on the development of the team working on the project, it requires commitment and willingness to search for new methods of problem solving and software improvement; each iteration is a valuable lesson and effort with a well-functioning end result in mind.
10. Simplicity is the art of minimising the necessary work. The idea is not to complicate solutions and not to overdo things unnecessarily; the functionality is supposed to work – the simpler the solution, the better, faster and more efficiently it can do so.
11. The best solutions come from self-organising teams – this principle draws attention to the method of communication with teams responsible for individual elements; teams are supposed to be involved in their tasks; they are supposed to seek solutions and introduce changes necessary to work more efficiently independently – the project manager supervises the whole project, but does not impose on teams how to work.
12. Thanks to the regularity of work, the team constantly develops, becomes more efficient, adapts to changing requirements; draws conclusions and changes its approach accordingly – development, development, development!

The basics of the agile methodology are not as easy, simple and pleasant as they may seem; despite the simplicity of the principles, their implementation can be challenging. The so-called human factor plays a key role here. Keeping these 12 directives in mind will help not only at the beginning of organising teams and working according to the agile approach, but also every time cooperation becomes tricky.

(The original principles can be found here: http://agilemanifesto.org/principles.html)

Jira Software or how to run projects with the agile methodology

From the story of the beginnings of the agile methodology, we moved on to the differences between the agile and waterfall methods and to the 12 principles of this approach. Now, it is time to discuss another important issue – how to tame a project carried out in such a (seemingly!!) unstructured way? How to monitor what happens in individual teams working on individual elements of the whole? How to clearly prioritise tasks so that everyone can find themselves in the multitude of activities? Systems dedicated to running projects with the agile methodology are helpful in this respect. One of the most valued is Jira Software,which includes a set of functionalities that allow you to organise agile teams.

*Due to the multitude of approaches to Agile, we will focus on SCRUM compliant with the SCRUM Guide (https://www.scrumguides.org/).

*To a lesser extent, we will also refer to SAFe (Scaled Agile Framework – https://www.scaledagileframework.com/), which was created to address some of SCRUM’s problems (mainly scalability with regard to large organisations), and despite having “agility” in its name, it is considered by many people to be a hybrid methodology.

The most important functionalities include:

Sprints are the main element around which work planning is carried out in SCRUM. Jira allows you to create sprints of a selected length and to assign tasks to them. It is possible to create one sprint per Backlog or multiple parallel sprints using the same backlog, if you need multiple teams working on one set of requirements.

In some organisations, it may be necessary to plan work over a longer period of time (e.g. due to dependence on other areas not working in the Agile methodology), or to better visualise the relationships between tasks. Addressing this need will be further described in this article when discussing add-ons for Jira.

Tasks are an essential element of the Jira system, which is used to organise activities; a Jira task is an element of work to be done of any type or size; it makes it easier to identify and divide the scope of work into specific activities and to reveal their context.

Jira Software allows you to define different types of tasks of any size, which significantly facilitates work management. For example, in a given project, there might be Epic tasks – the most general and biggest tasks. Each Epic will consist of multiple usage scenarios, and these will consist of sub-tasks. Sub-tasks are the smallest elements within the project that can easily be completed by one person. Each type of task may contain a number of fields that will be customised to the user’s requirements and will contain all the information necessary to provide work related to that task.

It is possible, e.g. to assign each task to a responsible person, to associate them with other tasks (e.g. by determining a task’s dependence on another task), to comment or track the history of tasks. The permission to create tasks can be granted to each user or to a selected group only – depending on the project, task type, etc.

Each task can have a specified completion time (in the form of time or Story Points) and users can record how much time they have spent working on them.

You can define an individual workflow for each type of task.
Workflows are sequences of states in which each task can be, from its creation to its closure. A simple workflow looks like this:

In this case, the OPEN and DONE labels and everything in between define the status of the task. Arrows represent possible transitions from one status to the next. Workflows range from very simple to very complicated – they may include conditions, triggers, validators and post functions. This makes it possible not only to adapt each flow to individual needs, but also to automate a large part of repetitive activities. Thanks to this, task management duties that take a lot of time and do not bring much added value can be removed.

Task boards
Jira enables creating screens that allow you to look at situations from different perspectives by displaying tasks filtered by set criteria (such as assigned person, status, planned end date, sprint, component or virtually any other piece of information) and displayed in a specific format (e.g. a Kanban board). This allows for quick access to frequently used views, such as tasks assigned to a given user, a given team etc.

Task View
Each user can view their own dashboard with only their tasks, their team’s dashboard and the entire project’s dashboard, so that they get a quick overview of the work.

Backlog

Each project can have a separate list of tasks to be implemented. Depending on the methodology in which the project is carried out, it can be, for instance, a backlog, a kanban board or another type of task list. Each of the tasks in such a list can be categorised using e.g. labels or personalised fields, assigned to a given implementation, etc.

Knowledge base and documentation

In the world we live in, where the complexity of services, products and the environment continues to grow, good management of accumulated knowledge is essential. Confluence is the best way to capture, organise, manage and communicate knowledge. Confluence allows you to create any number of pages and subpages with information and to group them into a tree structure. Thanks to deep integration, each party can be connected with a Jira task, which enables the execution of tasks with easy access to necessary information.

Confluence allows you to create document templates, collaborate on documents through comments and notifications, track the history of changes, it allows multiple users to edit each page, etc. Thanks to the possibility of uploading graphics, multimedia and various types of files to Confluence pages, a lot of flexibility is provided for creating and editing documentation and knowledge bases. In addition, the combination of Jira and Confluence offers a number of features such as linking Jira Tasks to pages in Confluence or opening Tasks directly from Confluence:

Reports and searches

Being aware of the progress of work and the ability to quickly find and present the necessary information is a necessity in virtually any organisation. Jira makes it possible to address this need in agile environments through functionalities such as:

• Task Finder in large projects, the volume of created tasks often makes it impossible for a single person to track them all and keep control over what is going on. Atlassian addressed this problem, by offering an advanced search system, which enables filtering tasks by each field available in the task, by tasks related to it, by projects in which they are located, etc. The search can be done both using a simplified interface and an advanced search engine using JQL queries.
• Reports 
  Visual presentation of selected metrics is ensured by means of reports dedicated to agile methodologies, such as Velocity chart, Sprint chart, Release Burndown or Burndown chart

Additional features

In addition to Jira’s standard functionalities dedicated to agile methodologies, the Atlassian environment also offers the possibility to further adapt Jira to the needs of the organisation, both in the context of Agile and in the broader terms of product development. This is done thanks to the possibility of installing other systems integrating with Jira and add-ons to Jira, available at the Atlassian Marketplace (we recommend our applications). A couple of particularly interesting options are described below.

Bitbucket – a tool based on Git, i.e. a code repository, integrating with Jira. It facilitates collaboration on code, as well as more effective building, testing and deploying.

BigPicture – an add-on that expands Jira functionalities with project portfolio management, project management in waterfall methodologies and more advanced planning for agile methodologies. In the context of this article, the latter is particularly interesting. BigPicture adds modules that enable work planning according to SAFe (Scaled Agile Framework) to Jira. In a nutshell – from a planning point of view – this means that we can plan not only sprints, but also Program Increments (PIs), which may consist of several less detailed sprints. Additionally, planned tasks can be assigned to a given team based on the availability of resources in a given sprint or PI. Moreover, it is possible to plan and assign tasks on the basis of a set of skills required for their implementation.

Agility (not)  always a good choice

Thanks to clearly defined principles and tools such as Jira Software, the agile methodology has settled into business and is increasingly used to run complex projects of various types.  Nowadays, even the largest and heaviest organisations are making the most of the agile methodology, often modifying and adapting it to their needs and the character of their work. So, is agile better than other ways of running projects? Not always and not for everyone.

Teams working in an agile manner are often dissatisfied with the form their work takes, so it would be wrong to sing the praises of agile knowing that it has its disadvantages. Below I present the most important advantages and problems of agile teams – I would like to emphasise that they relate to working within the Scrum framework (the multitude of forms that agile can take, including hybrid approaches that combine agile and waterfall, is material for separate articles; there are so many of them and they are so different from each other).

Looking at the popularity of agile methodologies, one can get the impression that they are the best possible approach to work. However, let’s try to summarise their pros and cons.

Advantages of running projects using agile methodology:

Blurring divisions between business teams and IT

One of the biggest changes required by agile methodologies is breaking down “silos” in organisations. Divisions into Business, IT, etc. become less pronounced. Instead, self-organising teams are formed, focusing on product development. This approach facilitates project development planning, allows for greater specialisation in terms of the developed product and facilitates communication.

Emphasis on communication

The element already mentioned in the previous point, but so important that it is worth highlighting and discussing in more detail. Agile methodologies take “communication over documentation”. This does not mean that the documentation of the product can be neglected, but the emphasis is on understanding the needs and requirements and on thoroughness in the approach to their implementation (rather than mindless ticking off point after point). This allows problems to be identified more quickly, before they become difficult to fix.
In addition, the frequency of sprints, after which the delivered solution is presented and discussed, enables the team to receive feedback faster, which further reduces the risk of critical problems.

Continuous improvement

SCRUM has built-in mechanisms for learning from completed sprints and implementing changes to improve work efficiency (Retrospective). Compared to many waterfall approaches, in which “lessons learned” are created only at the end of the project (if at all) and then forgotten instead of being used in other projects, this significantly increases the efficiency of work.

Flexibility
Planning in SCRUM takes place from sprint to sprint. Of course, the Product Owner has a vision for long-term product development, however, the decision on which tasks will be carried out next is made during subsequent sprints on the basis of the completed actions and drawn conclusions. This means that a change in the “direction” of development can be made every sprint. Comparing this with waterfall methodologies, in which many changes require re-planning of further work (and often also a series of approvals…), it is clear that SCRUM allows you to react to changes faster.

Commitment
In a SCRUM team, there is no team leader responsible for delivering functionalities – the whole team is responsible. This enables greater involvement of team members, as they do not only execute the will of their supervisors, but have real influence over decisions and the application of the solution and are responsible for their consequences.

Clarifying meetings

SCRUM limits the number of team meetings to a well-defined list. Moreover, the time for each meeting is limited. This prevents specialists from wasting their time on meetings that have no benefits for them or those that “should be done by e-mail”. The repetitiveness of meetings imposed by SCRUM makes it possible for team members to plan their time better.

Disadvantages of the agile methodology:

Being inadequate to certain types of projects

Many agile promoters may disagree, but SCRUM is not always a good choice. There are several factors that may make SCRUM a mismatch for a given project:

• Projects with rigidly defined requirements and a completion date. Examples include projects related to the implementation of legal requirements – both the scope and the “deadline” are rigidly defined by the regulator. SCRUM does not work here, because, first of all, we lose one of the main advantages: flexibility and the ability to change the “direction” of product development (scope is imposed). Secondly, given the scope and the date of completion, we need to determine what resources are necessary to complete the project. This requires planning all work in advance (at least at a high level), as sprint-to-sprint planning does not ensure that we complete the project as required. Of course, you can analyse the whole project first, and then, based on that, create teams and determine the number of sprints, but this would no longer be pure SCRUM.
• Developing a product that is heavily dependent on “non-agile” products or parts of the organisation. Working in teams that have to wait for Release (which takes place, for example, once every 3 months) in another application may worryingly resemble working in the waterfall methodology. In such situations SCRUM loses many of its advantages and it is often a frustrating experience for team members.

Team variability

In order to maintain the effectiveness of the SCRUM team’s work, its relative invariability is important. This is due to the fact that team members who have been in the team for a long time remember the problems the team has been struggling with and actions that have been taken to solve them. With frequent changes of team members, this knowledge fades with time and problems that have at some point been addressed reoccur. What is more, any change in the team affects the team’s “speed”, which makes planning difficult.

Non-compatible team members

Just as increasing responsibility and commitment is listed as one of the advantages – for some personality types it will be a disadvantage. For a scrum team to work effectively, all its members must be involved. However, finding such people may be difficult, as this is not a feature that can easily be verified, e.g. during an interview. Of course, the same can be said about involvement in waterfall methodologies, but in this case, the “chain of command” and the way tasks are allocated make it easier to identify the problem, determine who should solve it and give them tools to do so.

Based on the above description, it can be concluded that Agile has more advantages than disadvantages. It should be kept in mind, however, that you always have to take into consideration the bigger picture, limitations and dependencies that exist in an organisation (including opinions and attitudes of team members – an issue that is often overlooked). Although the above list of disadvantages and limitations is short, these factors can cause serious damage when agile methodologies are steamrolled without much reflection.

If you would like to learn more about running projects using agile methodology in the context of Jira Software and other Atlassian tools, do not hesitate to contact us!