You understandably have retained your interest in Agile implementation because you have assessed your feasibility well and 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.
Although the conception of Agile is limited to the philosophy and principles, providing greater flexibility for practices and tools, but the practitioners have transformed their experiences into pretty graphics and wordings 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.
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 a right order from the 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 the other 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.
And as long as you are improving the process, your role as an Agile practitioner is extremely viable. Most of the Agile adopters try to implement all the recommended practices of 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 but soon realized that being over ambitious would only complicate the things. So, I decided to connect the dots gradually to turn it into a perfect loop or a repeatable process.
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:
What You Will Learn:
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 a 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 methods 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 the 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 more accurate method if it comes off.
In our case, we decided to go with traditional SCRUM that is the most widely used Agile method currently.
According to a survey (Figure 2), 52% of the Agile organizations use SCRUM with 14% using hybrid of SCRUM and Extreme programming. The other reasons 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.
Conventionally, the application lifecycle management software that supports Agile process is termed as Agile tools. But some Agile tools are function specific such as project management tools, bugs management tools or requirements 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, suggested by the experts and practitioners, contains the tools for all possible problems you can face during Agile development. And they all are useful but in a particular context. However, not each of them might be hurting you considerably.
So, identify your problems to be addressed in the 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”. So, you should thoroughly go through the various tools available for Agile but should not use or plan to use all of them.
Software Testing Tools Usage: (click on image for enlarged view)
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 had not used 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 a right balance between simplicity and power of the tools we use. The most powerful Agile tools are used at a 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 meeting the deadlines first unlike you whose major focus is to ensure the 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.
That’ll make your team re-think why you moved to Agile at all? Regarding the ALM tool, I evaluated few of them, each with its own strengths and limitations but TFS provided us the desired balance in my case. However, Figure 4 shows the list of specific brands of the Agile products (or general purpose products used in Agile) and their usage in the industry.
Tools Used in Agile Process:
Agile techniques are actually the recommended practices or set of practices designed specifically to execute your software development the Agile way. The case of techniques selection is a bit different from choosing a method or the tools.
Every agile method consists of a set of recommended practices each addressing a different problem. And they combine to form a closed loop that completes the process.
So, 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:
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 enlarged view)
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. So, we have to react to the teams’ issues and suggestions.
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, the 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 much 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 standups 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 a day for winding up the sprint tasks, which is not a 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 a metal, melt them and shape them according to your mold them according to your frame.”
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 not less important at all) after you are done with the basic initiatives.