State of the Industry
Whether following a pure Agile or a hybrid methodology, Agile is now being applied in the majority of projects across Australia/New Zealand. According to the 2016 Planit Index, 94% of organisations are now utilising Agile in some portion of their projects as a means to accelerate delivery. The prominence of Agile continues to grow, applied to more than half (55%) of all projects undertaken in 2016 (up 12 percentage points since 2015) and doubling in adoption since 2011 (28%). This is a common trend reflected in the majority of recent IT surveys worldwide, such as How the World Tests 2016 by Zephyr and the World Quality Report 2016-17 by Capgemini, Sogeti and Hewlett Packard Enterprise.
This all sounds like good news, but when you peel back the covers on projects reporting to be Agile, all is not well, or as it seems. In my work conducting Agile Process Optimisation reviews, it is common to see teams doing the ceremonies but consistently not being able to deliver on their commitments for the iteration. Or having endless retrospectives where the same issues come up each time, but improvements do not seem to be made or become habitual. This is a common problem, where someone has told the teams they have to use Agile, and they have read a book on how to perform the ceremonies, but do not understand the true value of benefits for delivery.
Of course, I come across teams that are highly successful, but this does not seem to be across the whole organisation. You would think that companies with superstars would share their great practices across other teams and therefore make them successful, but what works for one team, even for similar work, does not work for all. This is often seen in organisations where they have tried to scale Agile from a few well performing teams without a good transformation programme, which in effect comes down to change management. They often do not factor in that later teams may need different training, support and coaching than the early adopters.
The majority of teams are still using Scrum or forms of it at scale. There are some good reasons for this:
- Promotes cross functional teams
- Improves collaboration
- Eliminates waste (if retro items are implemented successfully)
- Cadence sets some stability, familiarity and framework
- Discipline throughout the Iterations
- Short term planning is often easier and more accurate
However, it is important to understand the benefits that it brings. This includes more structure than other methods/frameworks, particularly for teams coming from a traditional background and shortfalls such as prescriptive day-to-day practices.
Interpretation of Planit Index results
I would like to take a few of the results from the Planit Index, and interpret them with regards to increasing projects and organisations moving to Agile.
Figure 1: Reported benefits of increasing testing investment
According to the 2016 Planit Index, the 2nd most reported benefit of increasing investment in testing over the last ten years has been reduced maintenance cost after project implementation. This was reported by 59% of Agile practitioners, in comparison to just 29% of traditional methodology users (30 percentage points difference). The key benefits of Agile have been touted by industry professionals for many years, including improved responsiveness to change, speed of delivery, realisation of business value, team collaboration and overall project success, however we have uncovered another advantage. I believe that there are a few reasons for this: the Agile team is also responsible for the production support of what they have produced; focus of developing the simplest code possible to satisfy the requirements and the closer alignment with Operations teams through DevOps.
Figure 2: Project outcomes: Agile vs Traditional methodologies
In 2016, for the first year on record, Agile matched traditional methodologies in terms of project failures, as organisations continued their increasing adoption of Agile. I see this as a key positive, with teams now embracing “safe to fail” mentalities. They are experimenting more to try projects that may have been thought “off limits” in previous years or looking at new products more frequently. Due to the frameworks within Agile, for example in Scrum, teams look to build and release code on a fortnightly basis so they get customer feedback much more quickly. This gives Business valuable knowledge on decisions to make, for example, whether to discontinue a project when all features or functionality may not have been delivered fully. Rather than project failures, I see these postponements or stopping of projects as a cost saving; reducing the amount of software that is un-used which is waste (around 60% of all software is little or not used) and responding more quickly to client wants and needs.
Figure 3: Project Conditions
38% of respondents using Agile methodologies perceived user involvement to have a positive impact on project conditions, in comparison to just 26% of organisations following traditional methods. This is one of the core values of Agile so this is not surprising, in fact the first principle states “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Another core value is “Business people and developers must work together daily throughout the project.” In fact, I expected that the difference would have been greater. Adobe’s ‘The State of Content: Expectations on the Rise’ study found ”39% of people will stop engaging with a website if content/layout is unattractive or if images won’t load”. Arguably, for mobile device users this figure is even higher, with users deleting downloaded apps if they do not work as expected within ten seconds of first use. How can we, as IT professionals, exclude user involvement if we expect to sell our products and services?
42% of Agile practitioners responded more positively than 22% of traditional methodology users in regards to small/regular project milestones (an expected result as the cornerstone of the Agile methodology). Again, this is a cornerstone of Agile methods. This seems like common sense, although it’s not always so common! If we have regular smaller milestones, this allows us to check in, correct and adapt to ensure we are delivering what the customer wants. From a team perspective, this reduces the frustration of spending time on things that nobody is going to use, therefore positively impacting team morale. Who doesn't want to deliver products that people want and need? Smaller milestones are also easier to estimate, predict and plan, leading to success by delivering on what a team has committed to.
Figure 4: Test automation utilisation in Agile vs Traditional projects
42% of Agile practitioners utilise automation as a key part of the SDLC, compared to 14% of traditional methodology users. Whilst it is to be expected that automation is used more extensively within Agile projects, I was surprised by the large difference between the two. Automation is fundamental to Agile projects, particularly for continuous testing, which is common in DevOps. People often think automation is primarily needed due to the large volumes of regression testing, but this is not necessarily the case, and we need to be SMART about our regression testing. Automation needs to be used for more than this and has a much larger scope. It should be used where it adds the best value for unit tests and API testing as per the Automation Pyramid.
Having given some insights into where I think we are now and what the Planit Index is telling us, I thought it would be worth giving you some of my predictions for the year ahead. These predictions come in two distinct parts: one for those doing Agile rather than true agility, and those that are ready for the next experiment.
According to the World Quality report for 2016/17, research shows that challenges with quality and testing in Agile projects are increasing. The most notable difficulties are in identifying the right areas on which to test, the availability of flexible and reliable test environments and test data, and the realisation of benefits from automation. I have already discussed which is mandatory, but here I want to focus on the first of the challenges above. Whilst the fundamental testing activities do not change the way they are practiced, there is no doubt an Agile testing skills gap, which is a fantastic opportunity for test professionals to take ownership of their career. There are plenty of online courses focussed on obtaining practical skills, such as the iSQI Certified Agile Tester qualification. Get some coaching; attend conferences and webinars; read blogs or participate in meetup groups, which are all great ways to share and step outside your comfort zone to learn. It is important that you create yourself a path to professional learning which moves you from novice to expert.
In Agile teams, the testers take on multiple roles; the most important of which is that testers need to have an Agile mindset to understand that they are NOT the gatekeepers of quality, but their focus needs to be on coaching for whole team ownership of quality and testing. They become the quality champion rather than being seen as the negative blocker to product delivery, as an enabler. Testers need to enhance their soft skills to become more collaborative, but still maintain a certain level of independence to provide a different viewpoint for delivery of the team goals. Testers also play a critical role in test-driven development, where tests are created first and code is developed to pass the test. Testers also have the opportunity to pair with developers in testing as the code is being developed, therefore technical skills are taking on more importance.
Process development and outcomes
I see a larger experimentation with combinations of methodologies and frameworks. I suggest that you take what works for you and add your individualisation. A word of caution however in that you need to understand what benefits you are going to get, as well as things you may be missing out on without implementing a process/practice fully. Telling people just to “do it” does not work. They need to understand why they are doing it and feel empowered to own and adapt it. Focus on outcomes, not the practice, so they can build a path from novice knowledge to expert. I have been advocating for years, the collection of a “tool kit” for each individual which they add to and bring the best practice/technique to the activity and/or environment in which they are working. Use what is best at the time and not be constrained by the defined process/practice. Pragmatism is a critical technique for the way that I deliver success.
Agile and company culture
At the organisational level, one of the trends I see is a focus on ensuring that the company culture is supportive of Agile. This is one of the key criteria for setting up an environment for success. They need to install a culture of continuous improvement and have business and IT on the same page from the beginning. They should create very flat organisational structures and foster a culture of collaboration, innovation, and empowerment. Agile culture is also about accepting failure, but making sure you fail-fast and move on.
For those that are in high performing teams, here are some things that you may want to think about experimenting with:
- Predictive analysis as one of your automation techniques
- Automatic and self-learning analysis and decision making technologies
- Failing often and fast
DevOps is another trend that testers can't ignore and must contribute to. DevOps principles are based on breaking down barriers between development, testing, pre-production and operations, in order to get software into users' hands as quickly as possible, and to find faults and fix them in real time. In DevOps, testers' primary responsibility is ensuring the quality process.
What an exciting year we have ahead! Stay tuned as I will be exploring some of these points and others in future posts.
Follow Leanne on Social Media
LinkedIn: Leanne Howard