Skip to Main Content

A Realistic Approach of Pragmatic Agility


In the 14th Annual Report of the ‘Evolution of the Agile Approach’, 95% of respondents mentioned that they were using Agile as a software development method in their organizations.

On a global scale, there is no doubt that this approach is now dominant. However, whether your business belongs in the remaining 5% or the first 95%, it is important to consider a more pragmatic, more accessible and above all, less dogmatic approach often referred to as the ‘Pragmatic Agility’. Hopefully you’ll see that it is not a question of revolutionizing the approach, but simply of adapting it efficiently.

Benefits of Pragmatic Agility

To fully understand the benefits of Pragmatic Agility, it is important to understand the principles of the Agile approach. If you require a refresher, we have illustrated the foundations of this approach here: Agile Fundamentals.

Agile has obviously evolved since it’s introduction – and after some mutations and adaptations, several camps have developed, and one of them is called Disciplined Agile (DA). One of the 7 principles of this approach is Pragmatism.

Pragmatism was introduced to avoid falling into the rigidity that some followers of the Agile model have demonstrated in recent years. We could write a full article on these rigidity issues, but let us instead concentrate on the question “Why Disciplined Agile?”

This statement clearly indicates that the Agile approach goes beyond IT. There is a real tendency to apply this approach across the whole organization. However, while reducing bureaucracy is an admirable goal, the abandonment of structures without vision often leads to chaos.

The Team

There is also another principle within the Agile model which requires pragmatism in its approach. In order to have more freedom and less structure, we must find competent, autonomous, responsible, mobilized and accountable people. In other words, you need a great team.

In Agile teams, employees are given the opportunity to organize their tasks, be versatile and become good communicators, because if there is less documentation, there will inevitably be more questions.

No matter which Agile approach is selected, it is not always easy to have teams with all these qualities. More realistically, we will have people who will continue to have more specific roles, so that they can focus on areas where they excel and people to ensure that they stay focused on the scope, the timeline, and the budget.

Critical questions that you must ask yourself:

1. Is your choice for the Agile approach based on the right reasons?

Why Choose Agile?

For managers with little knowledge of IT, the Agile approach is a response to their annual grievances sent to the CIO. “We will be able to develop faster, with more quality and at the same time, and save costs.”

However, you should not see the Agile approach to save money, because this is not the case. Of course, by delivering features by iteration, it’s easier to identify whether what’s being delivered matches what’s expected and make quick adjustments, as required.

Nevertheless, since Agile projects are more likely to succeed, according to the Standish Group‘s Chaos Report (2020), it can be assumed that the overall costs of projects without results will be lower.

The same logic may apply in terms of speed of delivery. The “Fail Fast, Learn Faster” expression is often used in the Agile world. Indeed, with this approach, we can deliver faster and at the same time quickly make corrections, if the needs have been misunderstood. In fact, it’s not the code that you develop faster in Agile, but rather value!

For the 40,000 or so respondents to the 14the Annual State of Agile Report, here are the reasons cited for adopting the Agile approach.

It is obviously interesting to bring value quickly to a project, but one caveat is: There will be no quick value without effective design. A quick start in the development phase, without a global vision, could look like this perfectly equilateral triangle, but that will never stand, if it rests on one of its peaks.

2. Is your organization ready for such a change?

Statistics do not lie, Agile is the “new normal”, but it must be recognized that is not Agile who wants!! It is easy to imagine that in more traditional public organizations or in larger companies, there will be significantly more effort required to manage changes for Agile projects to be delivered successfully.  Everyone jumps on the Agile train, but how do you make sure you get to the right destination?

The McKinsey Group’s article “The Five Trademarks of Agile Organizations” identifies five key characteristics for a successful transition to the Agile approach.

  1. Strategy: A polarized vision across the organization

See and seize opportunities, have flexibility for resource allocation

  1. Structure: A network of autonomous and accountable teams

A clear structure without too much hierarchy, a team with control over the governance of the project

  1. Process: Quick decisions and learning

Transparency in communication, an action-oriented decision-making process

  1. People: Dynamic and passionate people

Close-knit, versatile, and dedicated teams to the project

  1. Technology: State-of-the-art tools

The right management tools and the right development tools

Of course, one can say from reading this criteria, that no matter the method of development, one should always aim to put these characteristics in place.  In Agile development cycles, by Sprints of 2 to 4 weeks, these criteria are unavoidable.

Before prioritizing the Agile approach in your organization, we suggest two important points for a successful transition:

  1. If you are in your first steps and you have no one in your organization with Agile experience, have Agile coaches to accompany you before you start your project.
  2. Choose the right project, and the right team! This last point may seem obvious, but it is just as important as the first one.

3. Does the choice of Agile mean that you must abandon the traditional method for all your projects?

Although Agile is an excellent approach to developing projects, when scope and needs are rapidly changing, the traditional cascading method should always be considered and retained in some cases.

For example, where needs are clearly defined and clear specification documents are to be available, in specific and well-regulated areas, the traditional approach has its advantages.

  • Project planning is more easily predictable.
  • The production team focuses on the development of the solution, without being regularly reviewing needs.
  • The result of the delivery is easier to predict.

It is also important to understand that the introduction of the Agile approach into heritage systems or systems with multiple integrations is not always obvious, or even applicable.

The Agile approach definitely brings many advantages but it’s not without weaknesses.

  • The client (Product Owner) must be involved in the project.
  • Documentation is not a predetermined deliverable in the Agile approach.
  • A relationship of trust must be built between all team members, which is not always easy.
  • You should expect to redo functions already delivered with evolving needs.

To reiterate an music industry example used previously, Spotify, a world leader in audio streaming, have adapted the Agile model and developed their own model for scalability, with squads, tribes, chapters, and other concepts.

All these concepts were always based on the team’s autonomy. However, while many have praised Spotify’s approach (because of the company’s success), it seems that the approach has been fraught with many challenges. In this interesting article by Jeremiah Lee, focusing on the underside of this approach, we can better understand the issues that the Spotify teams had to go through. There are several passages in this analysis to make you think, specifically these two comments:

  • There is no autonomy without direction and accountability;
  • Collaboration does not guarantee competence.

4. Does it also mean we will abandon documentation and replace it with a functional software?

Agile manifesto

As one of the four core values of the Agile Manifesto, which advocates delivery before “comprehensive” documentation, many may feel that the documentation of Agile projects is deficient. Moreover, as developers are usually not much focused on writing and that they are heavily involved in product specifications with business lines, the question is legitimate.

It is wrong to claim that the Agile approach is against documentation. There are 4 rules, often used for Agile documentation, that ensure an adequate level of documentation:

  1. Have the minimum necessary (Just Barely Good Enough – JDBG);
  2. Write at the right time (Just In Time – JIT);
  3. Centralize all documentation;
  4. Produce it collaboratively, with all team members.

To picture the rules above, Agile projects aim to “travel light” for the documentation component.

Agile documentation is regularly presented as User Stories .  These ‘Stories’ look like: As “who”, I want “what”, in order to “why”. In more complex cases, we call it a “User Epic”, that can be defined as a group of user stories.

As in any project, Agile or Waterfall, there will be other documents needing execution. These will range from a project charter to user guides. To be clear: Agile has not removed the need for reference documents.

Again, the key importance when leveraging the premise of ‘Pragmatic Agility’, is to adapt the Agile approach to your ways of doing things to ensure everyone’s buy-in.

5. Do you want to retain the role of Project Management (PM)?

Agile approach

When looking at the documentation of the Agile approach, for small teams (10-15), there are regularly three roles:

  • Product Owner
    • Sets product features (Product Backlog);
    • Decides and prioritizes the content of sprints;
    • Adjusts features with each iteration;
    • Accepts or rejects the features performed;
    • Manages communications with stakeholders.
  • Scrum Master
    • Helps the product owner manage the features value;
    • Ensures the team is operational and productive;
    • Build collaboration among team members;
    • Remove obstacles;
    • Tracks the Agile process.
  • Development team
    • Assists the Product Owner in writing user stories and acceptance tests;
      • We are referring here to roles such as the business analyst.
    • Makes and tests the features of the product;
      • We are referring here to roles such as developers and QA analysts.
    • Presents the results to the Product Owner;
    • Keep the specifications up to date;
    • Manages versions and deployments.

In the image above, we do not see any project managers.  Additionally, we see that the management of the sprint is carried out by the team.  Some readers will probably observe that budget monitoring is totally absent from the responsibilities of all roles. On the other hand, nothing prevents a PM in a small or even a medium-sized Agile project from playing the role of Scrum Master while managing the budget.

Although the above model works very well for smaller teams, for larger projects, and for organizations that have done a total immersion in the Agile model, the SAFe (Scaled Agile Framework) approach is the most popular.  In this case, project management will reappear, once again.

When you look at the diagram above, you can sense some heaviness and a possible lack of flexibility, which is against the basic principles of Agile.  Again, the important thing to remember is that there is no silver bullet.  Agile methodologies need to be adapted to the context of your organization.

Be Pragmatic When Adopting Agile

Talking with some Agile evangelists, one can get the impression of a rather dogmatic approach to using Agile. This obviously is not always the case. While there are pages and pages of documentation on the Agile model, including its virtues and how to implement it, you will need to do so with hindsight and forethought, adapting a pragmatic approach to your organization’s capability, now and in the future. Dogmatic and rigid adherence to any one practice or methodology is always fraught with challenges. There is simply no ‘one size fits all’ approach to how your business should be doing things.

A Hybrid Agile approach is often referred to as a transition to manage change more appropriately. There is also an interesting expression in the Disciplined Agile approach that refers to choosing the WoW (Way of Working). You should find your WoW, and leverage the best options for your projects.

No matter what approach you choose, for effective management of your IT project portfolio:

  • You have to choose the projects that will bring the most value to the organization;
  • You have to evaluate the interdependencies between your projects;
  • Key players must be freed from business lines;
  • We need to communicate effectively with all stakeholders.

As in any project, regardless of the field, the key lies in the Team that is being put in place. The right player in the right chair will always be a guarantee of success. Remember to look at the whole forest before focusing on one tree.

Headshot - Pierre Kergoat

About the Author

Pierre Kergoat

Mr. Kergoat has over 30 years of experience in information technology, including more than 15 years in Project management and Delivery Coordination. He oversees the STX Studio in Montreal, where he is responsible of the solutions developed within the Studio and a key contributor to the Systematix Centers of Excellence.

Cette page est également disponible en Français (French)