Groundwork For A Successful Agile Journey: How to Choose the Right Method, Tools and the Techniques

By Vijay

By Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.
Updated March 5, 2024

In this article, we will see in detail how to choose the right method, tools and the techniques for a successful Agile journey. However, before you begin, please read part 1 and part 2 here.

You understandably have retained your interest in Agile implementation because you have assessed your feasibility well and are now looking to start your endeavor for successful agile implementation.

As a beginner, every process engineer reviews the literature when assigned the huge mission of defining a compatible Agile process for the organization.

How to Choose the Right Method, Tools and Techniques

Agile Journey

Although the conception of Agile is limited to philosophy and principles, providing greater flexibility for practices and tools, the practitioners have transformed their experiences into pretty graphics and wording to make it look more appealing.

Their proposed framework contains well-defined roles, iterations, and procedures and has been as simplified as in Figure 1.

Agile Process

AGILE JOURNEY 1

Figure 1

But we don’t live in an ideal world. It is certainly not possible to have all the elements of your desired process put in the right order from day one. In fact, you don’t even know much about your desired process at the beginning. Your process has to evolve. You cannot replicate or inherit the process from any other organization, not even from another autonomous unit.

So, the key is to know the starting point. You should know your priorities so that you focus on the right element at the right time.

Agile undermines the need for a thorough plan during software development and relies more on responding to change. Interestingly, it follows the same approach for its implementation if we take it as a parallel project. So, the consequences of one step will decide your next step.

In this article, I will just highlight the milestones to achieve in order to start delivering the products usefully the Agile way. The reason I have used “start delivering” phrase is that there is no end to it. Agile implementation, like other software development processes, is an ongoing journey of continuous improvement. You are never done.

As long as you are improving the process, your role as an Agile practitioner is extremely viable. Most Agile adopters try to implement all the recommended practices in Agile right from the word go and get frustrated early on if they are not able to establish an ideal process.

Although I was also excited when I took up the challenge, I soon realized that being over ambitious would only complicate things. So, I decided to connect the dots gradually to turn it into a perfect loop or a repeatable process.

The following are the most fundamental initiatives you have to take in order to ascertain that you have enough to continue the never-ending voyage of Agile adoption:

  1. Choose the right method
  2. Apply the most appropriate tools
  3. Adopt recommended techniques

#1. Choose the right method

All the discussion in this article series is about the implementation of Agile which is not a method in its own right. It’s a philosophy, an approach, a mindset, a set of principles or a framework. But it is all abstract and you need the right Agile method to implement it.

You need to find or construct a method to materialize Agile in your context. There are various Agile methods that exist today, each with its own benefits and shortcomings.

The easiest thing you can do is to pick one of the popular Agile methods, start execution and customize it according to the results. The next modest thing to do is to combine more than one Agile method to construct your method.

A lot of organizations these days are making full use of the best practices of various agile methods in order to create their own. However, you need to ascertain that these practices are neither redundant nor incompatible.

Finally, the most creative approach you can take is to design your own Agile method from scratch following Agile manifesto and principles considering your current process and organizational culture. This comes with larger risks as the practices might not be well-tested within the industry.

But as a general principle, high risk comes with a high return of having a more accurate method if it comes off.

In our case, we decided to go with the traditional SCRUM, which is the most widely used Agile method currently.

Agile Methods

Dev and qa processes used

According to a survey (Figure 2), 52% of the Agile organizations use SCRUM with 14% using hybrid of SCRUM and Extreme programming. The other reason for choosing SCRUM without hesitation was support from our partners Microsoft for SCRUM specific tools and also our CEO’s inspiration from the way Microsoft works.

So, make sure that you choose the method that is acceptable to all the stakeholders including management, development teams, and the clients.

#2. Apply the most appropriate tools

Conventionally, the application lifecycle management software that supports Agile processes is termed as Agile tools. However, some Agile tools are function specific such as project management tools, bug management tools or requirement management tools which support Agile.

There are so many tools available for every Agile method with very useful user reviews and guidelines. But after going through various recommended tools, your first ambiguity will be which of them to leave rather than which of them to adopt.

I would advise to just avoid three types of tools: undue, complex and over-constrained.

“When you have a hammer, every problem looks like a nail”.

Remember that the toolset, as suggested by the experts and practitioners, contains the tools for all possible problems you can face during Agile development. And they are all useful but in a particular context. However, not each of them might be hurting you considerably.

Identify your problems to be addressed in order of their priority and then select the most applicable tools. Do not use the tools “just” because they come with the toolset and others had a good experience with it.

As you can see in Figure 3, companies have identified few tools that they do not need although they are being used by the others successfully. Similarly, they regard some tools as “Nice to have”. You should thoroughly go through the various tools available for Agile but should not use them or plan to use all of them.

Software Testing Tools Usage: (click on image for an enlarged view)

Agile tools

I rate our process at a fairly mature stage now but still, we do not use some commonly used tools because we believe that we are doing well without them. For example, we have not used a continuous integration tool so far. However, we might need them after our release management process and automation scripts have become reasonably stable.

Some of the organizations do not use a complete ALM tool. Rather, they use different tools for different practices. We often complement TFS with Excel and SmartWord4TFS (our home-built tool). In Figure 3, you can find the categories of Agile tools with their usage across the industry.

Another important consideration is to find the right balance between simplicity and power of the tools we use. The most powerful Agile tools are used at the cost of simplicity, which is the essence of Agile.

If we try to impose the practices or the use of specific applications early on or make them produce certain artifacts, they are likely to feel burned out in the pressure situations. Remember that their focus is always on meeting the deadlines first, unlike you, whose major focus is to ensure a flawless process.

So, start with the simplest necessary tools that do not distract them from their tasks. Allow them to get used to it and gradually introduce more powerful tools according to the sequence of problems you face. The worst thing you can do is to get over-ambitious and attempt to use the complex tools initially.

This will help your team re-think why you moved to Agile at all. Regarding the ALM tool, I evaluated a few of them, each with its own strengths and limitations but TFS provided us with the desired balance in my case. However, Figure 4 shows the list of specific brands of Agile products (or general purpose products used in Agile) and their usage in the industry.

Tools Used in Agile Processes

AGILE JOURNEY 4

#3. Adopt recommended techniques

Agile techniques are the recommended practices or set of practices designed specifically to execute your software development the Agile way. The case of technique selection is a bit different from choosing a method or the tools.

Each agile method consists of a set of recommended practices each addressing a different problem. They combine to form a closed loop that completes the process.

If you do not use a technique that is part of your specific Agile method, you are likely to miss it during execution in the form of some unanswered questions.

Therefore, to mitigate the risks of missing links in your end to end process of Agile development and delivery, I suggest adopting all the techniques of your method unless you have an insurmountable constraint.

The most critical decisions you have to make about these techniques are about their priorities, order and the form.

While evolving to Agile, it is neither possible nor advisable to adopt the techniques all at once. So, you should make a list of techniques and prioritize them. Obviously, the techniques that resolve the larger or more fundamental issues should have a higher priority.

For example, my most prior techniques were:

  • Daily standup (addressing team coordination issues),
  • Iteration planning (replacing the work breakdown structure),
  • Story mapping (to manage requirements) and
  • Retrospective (to customize the process according to organizational needs).

Your priorities might be different based on how you assess your problems. The list of most widely used Agile techniques in Figure 5 can be used as a guideline but not as is because it contains the techniques of all Agile methods combined.

Agile techniques: (click on image for an enlarged view)

Agile techniques

The order in which these techniques should be adopted depends upon the priority that we just discussed, the feedback from a team from retrospectives and the ease of adopting them. We already know that agile adoption is evolutionary and reactive. We should react to the issues and suggestions of the team.

Retrospectives are the best way to collaborate with them. But informal communication mediums can also be used to make the team members contribute individually and collectively. For this, Agile practitioners have to be very open in their leadership style.

Moreover, some techniques might be on high priority as well as suggested by the teams also but can be way too difficult to implement at a particular stage due to constraints and dependencies.

So, we have to identify the right time to adopt a particular technique. For example, we adopted the Burndown charts rather late in the process because it was difficult for us to make all the team members regularly update their tasks in TFS. So, the burndown charts were not very meaningful although it is one of the most widely used techniques of SCRUM.

Similarly, we cannot use every technique in its raw or standard form. We have to mold these techniques to be compatible with our environment, needs, culture, tools and other techniques being used. The way we do the daily standup is quite different from what you will find in the books.

Apart from the individual statuses from the team members, it includes discussing the odd issue or a requirement, answering a question related to process or announcing an important event coming up etc. Likewise, we have a buffer of the day for winding up the sprint tasks, which is not standard practice.

Our daily standups are longer than standard and sprint planning meetings are shorter than the standard duration because some stakeholders have to attend multiple sprint planning meetings in a day.

The point is “Adopt the techniques like metal, melt them and shape them according to your mold them according to your frame.”

Summing it up

So far, we have discussed choosing the right method, the tools and the techniques to adopt agile.

Although the process definition is not limited to these steps, these are the most fundamental phases of the end-to-end Agile adoption process which will determine the fate of Agile success in your organization.

If you can start with a solid foundation by going through these phases smartly, the chances of success are extremely bright as Agile implicitly has been a success story in our industry.

None of these accomplishments are artless. But I have made every effort to dilute the topic enough to be digested easily.

By the time you digest it, I’ll publish another article soon continuing this topic i.e. end to end process of Agile adoption. The next article will cover some relatively advanced phases like how to cultivate Agile in your organization (that are no less important at all) after you are done with the basic initiatives.

You can post your doubts, queries and feedback in the comments section below. We would love to hear from you. 

Was this helpful?

Thanks for your feedback!

Recommended Reading

3 thoughts on “Groundwork For A Successful Agile Journey: How to Choose the Right Method, Tools and the Techniques”

Leave a Comment