The Transition to Agile
The Transition To Agile
Three years ago I went for Scrum master training and the lady conducting the training was really furious, saying Agile will be dead in few years’ time because majority of teams do not really understand Agile; yet they claim to be following it. This, she said, is bringing bad reputation to the framework itself. It is only with time that I understand her concern about making the transition to Agile.
Agile is about Change.
While using Agile at enterprise level is complex, this should not be confused with Agile in general. We all know that Agile is about change but there’s always one critical function that is overlooked. Infrastructure and Development are always changing their ways – better coding, better technology, better environment infrastructure and more. Somehow, the testing group is “forgotten” when things change. This is the fundamental reason why organizations fail to truly transition to agile. So, how can we help organizations make the transition to be successful and include QA? The initial step before making any transition from traditional testing to agile testing is to realize that development teams are always in transition, searching for ways to not only improve development but to increase the pace of releases, creating new software systems and to be better. When this happens, testing lags behind.
Why Testing Lags Behind
As much of a proponent for testing as firms like Awesome QA are, the challenge lies in the testing focus not evolving. Organizations need to help the testing team evolve from the more traditional approach to agile testing. But it isn’t easy. IT leaders need to not only adopt Agile to accept their change for business but to help all teams make that transition.
In recent observations and discussions amongst various conferences regarding testing, it is becoming more and more known that so many testing groups want to make the change but don’t know how. Part of this comes from the lack of agile knowledge in the testing leadership but that can be resolved. Agile is just like traditional testing but with a different mindset. The testing skills don’t change – the mindset of the testing process and how to make agile testing successful needs to change.
One report, published in January 2017 by Christina Cardoza, outlined the statistic that seventy percent of the companies that responded to a survey clearly made the transition to agile, only 30% utilized automation as a testing principle. Other types of problems occur when automated testing is not utilized effectively, testing time increases due to change in requirements, lack of requirements, and not enough response time to allow testing to be effective. These, of course, are just a few of the typical situations that occur in organizations.
Testing needs to become an Agent of Change! The mindset is the first step in making this evolution; but there are other important steps as well. These steps sound realistic and they are full proof for organizations to consider after the change in mindset regarding traditional testing.
So much discussion has taken place regarding automation and the need for systems to be stable, automation is better if done at the end of traditional testing only, and so forth. These are ILLUSIONS! They work but in today’s changing technology, the need to deliver faster and better, it just won’t work. Test Automation, if done correctly, will better equip the agile developers with what they need to develop at the expected quick pace. Traditional manual testers must embrace test automation. But even though not all test automation is applicable and efficient, API testing is essentially the key. This method is part of the evolution of testing.
2. Prioritize the Testing
As discussed above, the leverage of automation is essential. But, when does testing occur? What is tested? Prioritizing the testing is fundamental to the process. If the testing team can leverage the API testing, for example, as soon as the first layer is available, manual testers can move in with other testing within the same time frame. Test leadership should know how to prioritize the testing to make this successful.
3. Communication and Leadership
This is the really the last step of the evolution process in making the transition to agile for the testing team. The right test leader, also known as the manager, can influence the testers to change. These testers, in turn, will then communicate and work effectively with Development. For example, no longer will defects be “thrown over the wall” to the developers and wait for a fix. Instead, the team is working together, discussing the defect the minute it is discovered and sometimes, a fix can be available that same day. It has happened. It works! The manager needs to empower the test team to embrace the change and become agents of change to make this transition.
What are some Agile misconceptions?
This brings us back to the story of understanding how teams are bringing bad reputation to the Agile framework. We have previously identified 6 signs why your team is not agile; below we elaborate on some common misconceptions about agile as to attest to the scrum master’s conclusion:
“Prototyping!” Agile is not about prototyping but about delivering working software in small iterations.
“Requirements are described from the technical needs”. Sorry! It is from the perspective of User that you describe Agile requirements. User story can refer to another system, an API consumer, another process, etc.
“Use Spread sheets to plan” Agile provides more planning opportunities. You have story boarding or project inception involving more people and a cohesive team actually building the system, weekly backlog refinement, sprint planning, tech huddles, etc.
“Agile is about demos”. A demo is just to present to stakeholders what you achieved in the last sprint/iteration. This gives them the opportunity to see it in real, raise questions or even change their mind.
“Any requirements that are not clear or do not fit a sprint should be rejected by the sprint team.” This is not part of Agile manifesto, but part of an internal problem of a team. Each team tends to have a set of guidelines that ensure they work consistently to the best of their effort and capabilities. The reason retrospectives are part of an Agile process is so that a team can review these guidelines, refine them and improve continuously.
“Make it simple. split it up and come back next week”. This is surely not an Agile team because a self-organizing Agile team will rather say “none of us seem to understand this bit, lets take the parts we understand and can deliver in one story or give ourselves time to redefine the requirements so we build the right thing.” You cannot and should not build what you don’t understand.
“Let us estimate work and time efforts”. Reality is estimates never work well. What takes one developer 20 hours may take another one 5 or 30 hours. Where do you draw the line? Product use simple tools to visualise story points in effort (hours) and cost (USD); these conversions are based on past performances and not what someone thinks, says or feels.
“There is no need for architecture”. Well, knowledge of the big picture within a team becomes poor when we focus on smaller bits. So having no architecture is not really Agile but an internal team problem, which needs to be addressed. All complex Agile have architects orchestrating the overall system and ensuring things stick together and usually when we demos are presented to stakeholders, affected parties that have not been thought of earlier become apparent.
The Agile Challenge – Continuous Testing
The biggest challenge for organizations to make this transition to agile is really to focus on continuous testing. It’s not just continuous development, but testing as well. The agile process needs to start with engaging the customer and flowing through to the testing team. Each member of the team needs to be fully vested in the transition as well as be an agent of the change! One wrong slip and the agile transition can diverge from the path to success. Organizations needs to ensure that all groups are involved and encouraged by this change to make it work. With these basic steps to help with the testing evolution, organizations will be successful.
In our previous blog post, we have discussed Agile software testing approach; if development team is willing to transition to agile, they need to change their processes to be better, and testing team must do the same. Organizations needs to adopt not just agile but the ONE TEAM concept to be successful and profitable, this we term a team Combined For Agility.