Systematix

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.

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

2. 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

3. Process: Quick decisions and learning

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

4. People: Dynamic and passionate people

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

5. 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.

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.

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.

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.