Tips for Properly Scaling Agile
Some ways to properly scale agile to meet your development, testing, and QA requirements in order to be successful.
Join the DZone community and get the full member experience.Join For Free
After working under one approach for a number of years, developers and quality assurance teams must now transcend to agile operations, which require a completely different mindset than what these individuals are used to. Because of the major disparity between these two methods, it can be tricky to get agile just right, and may even fail due to continued reliance on old processes. Agile requires a complete change, and this shift must be facilitated and guided appropriately in order to be successful.
Once agile is a priority for QA management, teams then must consider how to fit these values with their goals and development needs. Scaling is no easy task, as too little could inadequately provision staff, while too much results in overspending. In order to get it just right, let's take a look at some tips for properly scaling agile to meet your development needs:
Get Management Support
Scaling agile across one team is difficult, but applying that to an entire organization entails significantly more considerations and hesitation. However, having a manager in your corner could be just the thing you need to make your agile practices take effect throughout the business. Industry expert Michael Cote noted in a piece for RedMonk that if a big boss says to do something, people tend to do it. This type of interaction will help reduce personal risk and enable your team to develop as it learns without reaping the harsh consequences of failures.
"Let's face it, the first few iterations of an agile team are rough: so much of agile, initially, is about exposing the weaknesses and poor development practices organizations are doing (mainly: promising too much in each release, also, not fully working as a team around one product) – so there's going to be some failure at first," Cote wrote. "The executive is your blame-game safety net here: a good agile executive knows that the first few cycles of doing agile is all about making people realize they've been doing it wrong by exposing the poor results of their practices…and then learning from that, not punishing them."
Have Automation From the Start
When talking of expanding out agile, automation integration should also be part of the conversation as organizations will need these types of tools to facilitate the scale they require. TechBeacon noted that creating automated tests will involve a significant effort by teams, and should be completed in the early phases of development in order to accommodate any potential changes. Automating from day one will only be possible if teams abandon their lengthy release cycles in favor of the short, but quality-driven ones valued by agile. If a feature spends months in development and is rejected, for example, this wastes a significant amount of time and money that could have gone to other efforts. With the shorter cycles and automation, teams will be able to easily scale their agile initiatives and build in quality for every project.
"Agile stipulates short development cycles," TechBeacon states. "To accomplish those shorter intervals, you need to shift your approach to 'minimal viable product' (MVP) mode. Aim to create the smallest useful, functional product and ship it to customers in short release cycles. You can then monitor customer reactions and tweak the product in subsequent releases."
Use Lean Thinking
In many ways, lean and agile go hand-in-hand – in fact, lean has often been referred to as a subset of agile software development process. By focusing on this area, teams can actively reduce potential waste and ensure that their scaling efforts offer value directly to the business. TechTarget contributor Nari Kannan noted that by using lean thinking to reduce waste and organize work and people appropriately, agile can be adapted to organizations of any size. Lean mindsets understand that teams are responsible and capable of self-organization, allowing managers to focus on other tasks and provide guidance as required. This type of environment also mitigates the time waiting for various deliverables to be approved, enabling them to take action themselves and push the project to market much faster than ever before. Handling teams in this way will help scale agile to meet needs
Leverage a Model That Meets Your Needs
When scaling agile, it's important to use an approach that makes sense for your team and your development needs. In an interview with InfoQ, industry experts Richard Dolman and Steve Spearman discussed using models like Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD) and Scaled Agile Framework (SAFe). Although each of these approaches has helped some businesses to success, decision-makers need to choose one based on their unique requirements.
"One of the challenges we've encountered is trying to find a balance between objective and subjective evaluation criteria," Dolman and Spearman stated. "We've tried to emphasize the objective criteria first, but are also providing some subjective ratings on different criteria."
Agile operations can be a complex pursuit for many organizations, especially if they are unsure how to use it to innovate their operations. However, teams can create a comprehensive plan to ensure that scaling agile will meet development needs and contribute directly to the overall quality and reliability of software development projects. By gaining management support, using the best agile test management software, integrating lean thinking and leveraging automation, organizations can pick a scaling model that will directly fit their goals and guide them to successfully scaling their agile efforts.
Learn more about the three practices that were developed and scaled by Atlassian in order to stay true to agile in their forthcoming session–Balancing Act: Large Scale Strategy vs. Agile Methodologies in Atlassian.
Published at DZone with permission of Chris Wright. See the original article here.
Opinions expressed by DZone contributors are their own.