Agile quality assurance is a term which many technology teams have heard. In the following statement, I will be sharing what QA in an agile team looks like, and how you can release at pace with the same software quality.

Firstly, when a team details that they would like to be more agile and deliver updates more frequently, it can scare a QA team. They will envisage that they will need to test a code base that changes daily with no breaks and not enough time for each.

Is it so? Let’s answer this question together.

What about Agile manifesto?

You may have also heard the myth that companies get rid of QA when they are trying to move towards agile. This is incorrect. You will need to focus more on quality if you are adopting agile.

In an agile team, everyone is responsible for quality. The goal is not just finding bugs and defects, but also preventing them during the development cycle.

How can QA meet the agile manifesto?

4 key aspects that I have used to follow QA in an agile form include:

• Add QA documentation where it brings value.
• Always look for automation opportunities.
• Always look into automation tools, thus making your testing more efficient, repeatable, and easier-to-track.
• Understand your customers and ensure that you know the quality level they expect. Also, the double bonus, you will be automating smartly — the right things.

I have touched on automation in the above — automation is key as you have guide rails, so a good opportunity to react quickly to changing priorities and have a constant quality measure.

QA should be involved throughout the whole agile process. They should be a part of the team. The key to this is pairing on a task and discussing how a story should be tested. If we involve QA earlier, why not then shift QA left and have more of a chance to meet the delivery at high-quality considerations?

8 key tips for QA members working in an agile team

1. Join the agile team and work together

• Standup, retros, demos, planning sessions.

2. Focus on the existing methodologies

• Learn how your customer uses the product and prioritise what you test.

3. Automate your key tests

• Black box testing and working with engineering so you pair on automation.

4. Test manually for the right reasons

• Exploratory testing and always asking the ‘What if’ questions.

5. Continually improve

• Build maintainable and non-flaky test suites.

6. You must have excellent product knowledge

• Collaborate with your product team and learn about the product.

7. Shift left

• Test as early as possible and in smaller chunks.

8. Shift right

• Look to monitor, identify, investigate and remediate based on real-world scenarios and conditions.

The QA team is not the gatekeeper of the quality of a software product. The whole TEAM is responsible.

The agile QA process: 9 steps

QA should be involved in all of the above and think of ways to implement them with more automated processes or faster feedback loops.

Summary

What is important? To reflect, refine, improve, and progress with enhancing processes. Following agile is never easy, though, my advice is — by adding more value with, let’s say, automation it will make a massive difference.

Why do today’s eCommerce apps need to be extremely fast and efficient?

Obviously, consumers don’t like waiting. Like they say in the song, “I want it all, I want it all, I want it all, and I want it now.” To win their trust, it’s vital to provide them with a high-quality and reliable IT product.

But how to achieve this and at the same time make the testing process more effective and transparent? One of the proven options is to implement Agile and DevOps, which is not always that easy.

In the article I will show you how Agile and DevOps help reimagine eCommerce software, and what advantages companies receive from their implementation.

Flexibility and speed: supercharging eCommerce apps

According to the 15th State of Agile Report, the overall number of organizations practicing Agile methodology is 94% while the State of DevOps Report 2021 shows that 83% of companies implement DevOps.

But what about eCommerce: Is it enough for businesses to apply classical QA approaches for endless but essential software changes? Definitely, not.

Being flexible as never, Agile and DevOps help create a close-knit team where developers, QA engineers, product owners, and other members interact constantly to meet the common business goals. With a high focus on end users’ needs, of course.

When the pandemic struck, the demand for online shopping increased dramatically and the rate of online purchases surged to 16.1% from 11.8%. Not that much but still that impacted a lot the behavior and buying habits of consumers. Thus, close cooperation between the specialists helps respond quickly to changing customers’ requirements, prevent delays in the product launch, enhance its quality, and reduce business risks by constantly receiving the feedback.

People rate their favorite apps, giving 5 stars on Play Market and App Store, etc., recommend them to friends, become brand advocates, and keep up with all the new products of the brand. A perfect scenario.

3 “yes!” to say to Agile in eCommerce

To get positive results from implementing Agile, it’s essential to clearly understand how it works and what you want to obtain in detail. The 15_^th State of Agile Report shows that the main reasons for adopting Agile include managing constantly changing priorities, accelerating software delivery, increasing team productivity, enhancing IT product quality, and reducing project risks. Please, have a look at the picture below.

15^th State of Agile Report 

Though the pool of Agile strong points is ample, I think it’s necessary to mention some more key benefits that are indispensable in reaching the desired business outcomes:

Increased velocity and flexibility

I beleive that agile probably stands out among other methodologies as it helps release the app faster and more frequently by close and strong collaboration between business, management, and engineering teams that help react on constant changes and manage the quality faster.

Given today’s fast-paced IT landscape and high end-user expectations, it allows gathering consumers’ feedback after the product launch and gradually modify the eCommerce software. To make it so, continuous testing wins out, ensuring high speed of flowing processes while gaining more accurate results and timely fixing bugs.

Business analysis, in its turn, assists QA teams in understanding end-user needs implemented in the new-feature requirements. Moreover, specialists exchange essential updates on regular sync-ups to ensure transparent vision on project’s status and directions.

Enhanced market interest

Guided by their needs, consumers are subconsciously looking for software that meets their requirements and provides a wide range of options. All-in-one. Let’s admit it’s pretty much easier to have everything there — from making online transactions via multiple payment methods to selecting different colors and sizes as well as tracking products’ availability at all stores.

Let’s look at Amazon and eBay — their apps instantly process all incoming requests and provide the customers with all the information and products at lightning speed. And they succeed.

How? Performance testing, for instance, helps evaluate whether the IT solution withstands heavy loads and will not crash on New Year’s sales or Black Friday due to a large influx of customers, so end users continue e-shopping instead of getting error message on their displays.

Being aware of the expected number of users and the desired software capacity, QA teams organize the correct systems performance by detecting the actual performance indicators in advance and comparing them with desirable ones. Close cooperation helps QA experts pass all the details as well as improvements areas to the development team. The result of such interaction is the reduced implementation time and improved system’s capabilities.

Mitigated business risks

The flexible approach, divided into several sprints, brings project transparency by passing all processes step-by-step while forecasting possible hazards and gradually addressing them. It also improves project management processes, handles unwanted risks, and provides greater flexibility, allowing companies to deliver high-quality IT products faster and more frequently.

In case you want to reduce business risks even more while bearing in mind the number of cyber incidents is increasing each day, introducing cybersecurity testing may be of help with that. With software being extremely sophisticated, the hackers have more opportunities to penetrate it, so rigorous testing allows find the pain points and timely prevent the leakage of sensitive users’ data.

DevOps in eCommerce: yes or no?

The 15^th State of Agile Repost highlights that 75% of respondents find this methodology essential for their organizations.

While Agile focuses on ongoing changes, DevOps aims at constantly testing and delivering IT products to the market while enhancing the quality and reducing the number of bugs.

Primarily concentrating on ongoing communication, improved performance, and better cooperation, DevOps methodology leverages fast deployment while closely complying with clients’ requirements.

To get all the benefits that DevOps provides, why not leverage eCommerce processes via introducing several up-to-date practices:

Smart automation

When implementing DevOps methodology with test automation, companies make the testing process more effective. The right automation tools and a wise automated solution contribute not only to speeding up the process by reducing test cycle time but also to improving software quality, maximizing ROI, increasing release velocity through CI/CD approach. It’s easy to integrate test automation with the development activities, so the Dev team performs checks when needed by triggering automated tests build.

Continuous innovations

With Waterfall, the defects are possible to fix after releasing the product. No agility, no mobility. DevOps helps address it with confidence by providing improvements within small iterations, ability to perform changes following retrospective and audience feedback.

For instance, one of the pressing problems of modern apps is the poor UI. According to the latest World Quality Report, 46% of respondents put an emphasis on CX validation and usability testing.

By performing UI testing, it’s possible to verify multiple components, like UI workflows, calculations, buttons, etc. As a result, all app’s functions operate smoothly and correctly while ensuring comfortable users’ experience.

Summarizing

Within today’s IT market, retail companies adopt flexible approaches that assist them in delivering upscale apps, satisfying end users’ needs.

Agile and DevOps are pioneering among other methodologies as they bring enough flexibility, provide constant team members collaboration that help release software faster and more frequently, getting the leading positions in the IT market and enhancing IT products’ quality.

Feel free to reach out to a1qa’s experts to get QA support on implementing testing in your Agile and DevOps business strategy.

Within the evolving IT market, the demand for high-quality software is boosting day by day, with companies improving their products continuously. By adding new functionality and upgrading the developed one, their intentions are around to meet the end-user expectations.

This is where the need to ramp up the team, a QA group being no exception, is growing by leaps and bounds to help them stay ahead of the competitors.

Researchers from the University of California at Berkeley and Stanford found that 90% of young businesses fail because of premature expansion, and this is where it becomes clear that a prepared scaling plan doesn’t necessarily mean organizations attain planned outcomes.

By leveraging smart scalability based on agile methodologies and scaling up and down on request, businesses are more likely to derive desired results. The World Quality Report 2019-2020 indicates 95% of respondents use agile to some extent.

The Agile approach is more typical for small teams. But what if the promptly changing market and the need to offer truly high-quality IT solutions force to accelerate delivery time and enlarge the project? In the article, we discuss how to effectively scale a QA team and be confident in releasing top-notch apps meeting tight deadlines.

Reasons for scaling QA team

Global digitalization has become a clue for transforming internal processes. The unstable situation also paved the way for the rapid transition to a new norm, when people massively migrated to the online space within moving limits.

In such conditions, companies have tested their strength and how deeply their business operations were shocked. However, most of them were not prepared for this and faced a number of hindrances: decreased customer satisfaction, fallen market share, reduced revenue, and much more.

To bolster their competitiveness, organizations need to speed up time to market. How to do this in unprecedented circumstances? Salvage the situation with Agile. Here are the top 4 reasons for implementing it.

When it is not enough to be ahead of the competitors, adapting not only at the team level but also within the entire organization can be a way out. Based on smart scaling, SAFe is designed to conduct large transformational programs being about the equality of team members and the timely exchange of information between numerous participants using agile. Therefore, every employee understands the business goals and knows how to achieve them.

Smart scalability addresses the challenge

Applying for a sage extension, companies can change the number of project participants on request at short notice. Hinging on the business goals, the team might be scaled up and down.

The mounting process also involves the division into small groups, where effective communication is a silver bullet. Due to the desire to reach planned outcomes laying at the heart of the approach, employees re-image the mindset and work cohesively with each other.

Having united all the departments and teams with one management system, productivity increases. Project participants know their responsibilities, roles, and whom to contact in case of an emergency. They do understand their tasks and project objectives better, which means reducing downtime.

Moreover, employees’ accountability and independence in decision-making are evolving. There is no more need to regularly contact managers with uncomplicated issues that allow specialists to use their knowledge and experience and unleash their potential.

How to expand a QA team successfully?

Here’s what a1qa’s experts recommend to increase the number of team members effectively.

Compose a plan

A plan should be designed at the very start when recruiting employees. As the team grows, it is necessary to continuously develop the right strategy that will suit the current state. The scaling plan covers all activities on the project, from the technical aspects (tools and infrastructure) to the teams and resource management.

If you have a range of urgent and high-priority tasks to focus on, you can onboard a QA consultant who is up to analyze the current situation on the project and make a reliable plan for the transition to new practices supporting you in achieving your business outcomes.

Prioritize

Defined business goals streamline attracting specialists with an adequate skillset, as expertise and technical knowledge for productive work have already been specified. It is better to set several ultimate goals to be sure tasks are prioritized, and activities are consistent with the plan. An example to consider is: if the project’s aim is to accelerate time to market, you need to onboard test automation specialists to optimize routine checks, reducing the iteration time.

Onboard specialists with right skills

The software quality and success largely depend on the team. It is crucial to recruit QA talents with the appropriate skills not only at the start of the project but also when an expansion is necessary.

It is a common situation when the internal crew is not enough to scale, and organizations turn to outsourcing. It happened when the customer, a global provider of telecom IT solutions, entrusted the a1qa’s team with testing three large software packages. The scope of the project was regularly changing that caused the QA group ramp-up.

Considering the workload size, a1qa attracted additional QA specialists and also reduced the QA squad upon request.

Thanks to the timely knowledge transfer and task monitoring, the QA expansion was effective.

Monitor progress and results

By tracking all the parameters, including success metrics, you get a birds-eye view of the team’s structure, its productivity, and growth in the future. Otherwise, it is more likely to miss the scaling time or which area needs it.

Moreover, controlling progress on the level of an employee is an essential point. KPIs allow specialists to develop themselves and have a better understanding of business aspirations.

Care and interest in the progress of all project participants can ensure productive scaling, continuous interaction, and working as a single system.

All things considered

Highly competitive IT space forces companies to briskly scale project members, including those assuring quality.

But how to expand physical horizons and maintain high productivity? Smart team scalability is a way out. Based on agile methodologies, the approach contributes to faster time to market and adaptability within the entire organization.

Bringing on the right skillset and a clear strategy at the start, task prioritization, and setting KPIs can fuel the growth meeting all desired outcomes.

Need support in scaling your QA team? Reach out to us to get help from a1qa’s experts.

Scrum has proven to be a powerful tool for rolling out software products involving up to nine assets comprising the product owner’s performance. Seemingly, nine high-end and wisely motivated professionals are capable of anything, what could go wrong? However, in real world, things are rarely that simple.

When software development needs are expanding by leaps and bounds, the number of teams is increasing pro rata. Communication between them and synchronization of group work are jeopardized especially if considering geographically dispersed specialists.

LeSS Huge envisaged by Scrum is applicable for projects with >8 teams only. Otherwise, I recommend cherry-picking SAFe framework.

Founded on the principles declared in the Agile Manifesto, it allows syncing up the work performed by up to 150 specialists. SAFe takes communication to the next level and introduces Program Increment (PI) Planning to promote direct communication between the attendees: software developers, testers, business owners, and program stakeholders. PI Planning is the synchronization point of the Agile Release Train (ART).

Why PI? During the planning session, the teams create the plans for the upcoming Program Increment, which helps them get things done effectively, release more features in less time, and align on project workflows.

How is PI planning organized?

It’s better to see something once than hear about it a thousand times. With this saying in mind, I’ll share the planning agenda we received attached to the Meeting Request email last month. You’ll find the agenda some paragraphs below, while right now, I enlist some of the crucial points of planning.

Prior to planning, the well-elaborated backlog of functional and architectural features is prepared. The results of the planning shall be the commitment of the teams to an agree-to set of objectives for the next PI. All planning takeaways (teams committed to working on any user story, user stories interconnections) are fixed on the program board.

The planning process itself is very fascinating in SAFe and has many teambuilding features.

Let’s review some of the major differences our QA consultants have come across.

Organizational issues to be ready for

• Duration. Previously, it took us less than four hours to plan up a Scrum sprint. After migrating to SAFe, planning began to last four days almost.
• Participants. While applying Scrum, we planned sprints independently from other teams. In SAFe, it’s all different. Development, QA, business analysts, UX specialists are to participate in planning cooperatively. If someone can’t attend it for some reason, he or she should be available for questions.
• Event agenda. In Scrum, most of the time is devoted to estimating user stories. In SAFe, there are many more stages.

Now have a look at the agenda of the Product Increment planning we had last month.

It all starts with the company’s governing bodies communicating the business context of the upcoming PI to all teams. After that, the product manager specifies how the business context will be implemented in terms of functional solutions. The architecture shares his/her vision on the product’s technical implementation.

When they are done, the floor is yielded to the product owner of every team. He/she briefly presents the scope of requirements for the whole team to be familiar with the features that will be developed by every other team. On that note, the first day of planning is over, and teams say goodbye to each other to meet the following day.

On day two, teams break out to start working on their plans for the upcoming PI. By the end of the day, the draft of the plan should be presented. Managers review those plans and introduce necessary adjustments.

During the third day of planning, teams continue working on their plans to finalize them. Scrum Masters present the plans of their teams and review the risks alongside. The final procedure is a confidence vote. All attendees should confirm their commitment to the final plan objective. Every team conducts a “fist of five” vote. The commitment is accepted if there are three or four fingers on average. If fewer, then plans are reworked.

Noteworthy, any person voting two fingers and fewer should be given a voice to explain their concerns.

Finally, a brief retrospective is conducted to capture what went well and what did not. Following this, the next steps are discussed.

Ways to sync up and visualize the issues

• If you were attentive (and I bet you were), you must have noticed one of the points on the agenda I haven’t specified yet. Scrum of Scrums hourly. It’s an hourly meeting of Scrum Masters that takes place while the teams are estimating the given user stories. The objective here is to sync the teams up.
• The new level of visualization. Working with Scrum, we used JIRA to track bugs, assign issues to the responsible specialists. In SAFe, it became very difficult to discuss arising issues with colleagues who are allocated on other continents. Having tried multiple options, we gave our preference to RealTimeBoard – virtual boards that allow us to work with visual content together with our mates.

Stories estimation differences

• Estimation methods change from those in Scrum. User stories in SAFe are estimated in story points. This is the relative estimation to compare the difficulty of two or more stories.
• Every story is to be estimated in 2-3 minutes. Teams don’t need to get into deep discussions but rather provide a general estimation.
• If the story is estimated in more than 8 points, it should be broken out in smaller pieces to be implemented on time.
• Now in SAFe, we estimate not only our job but also the job of our colleagues from other teams. It gives a better understanding of their contribution and engagement. The question “Why do you need so much time for testing this small feature?” is rarely heard now.

PI planning advantages

With visible changes becoming commonplace, the SAFe framework is one of the means for deriving faster time-to-benefits while increasing productivity, quality, and customer engagement.

PI planning in SAFe is an essential technique for providing better alignment between teams through improved process transparency and well-organized face-to-face communication.

Development on cadence, being the heartbeat of ART, is observed while the future becomes more definite as we are aware of the teams’ plans several sprints ahead. Besides, we’ve gained a better understanding of our mission and the value we add to the product.

To cut a long story short

Our fast-changing world complicated by COVID-19 pandemic requires novel, well-balanced strategies to adapt at the necessary pace. SAFe is precisely one of them.

Wisely configured and applied, it can turn the tide to help you achieve any goal – from shifting new markets with products tailored to face a global challenge to embarking on a digital transformation journey.

All you have to do is just start. a1qa will help you begin and proceed with confidence.

In the current conditions of uncertainty and panic, it is important to focus on enhancing the effectiveness of your teams.

Applying the best practices for optimizing project management for the long term, QA managers and team leads should ask themselves the following questions in order to help businesses bring the planned outcomes:

• How should I keep the project on track?
• How can I timely monitor and respond to external and internal amendments like the client’s business goals, market situation, atmosphere within the team?
• Are there any hidden problems that can “destroy” all the made progress?

In this article, a1qa experts are sharing their experience on the QA retrospective use and are shedding light on how it helps emphasize typical challenges as well as solve most of them.

Tackling often-observed issues

The retrospective is a system of regular “flashbacks” that can enhance crew performance and increase the transparency of the project processes for the QA manager by involving the whole team in the internal culture of excellence.

Let us define three types of retrospectives depending on the objectives and the arisen challenges:

1. General
2. Project
3. Internal

A general meeting involves each and every project team member to take part in the problem-related discussions and make robust decisions. Everybody from testers, developers, business analysts to designers meet together to stop thinking about doing work tasks and focus on drawing a picture on the main challenges within the team as an entity. We call it a “psychotherapeutic” retrospective helping find process drawbacks and make a plan of action.

A project retrospective is carried out within the framework of a specific team or the testing crew separately from the development and other units. It can prepare participants for a general retrospective or it can be an isolated event to improve processes and solve specific problems.

The manager can also conduct the retrospective for himself or herself after finishing some of the work. It helps analyze and structure gained experience without delay to record successful management practices for future use.

The frequency of the retrospective can vary from weekly meetings to one rally at the end of the project and depends on the size of the team and the number of tasks. The most effective format is believed to be a regular meeting held every two or three weeks after the end of the iteration.

The retrospective may be conducted:

• At the end of a certain phase of the project
• After each iteration (for Agile programs)
• Upon completion of the project
• At any time when problems arise.

Even arranging retrospectives at the needed time and with the required objectives is not a way to effective meetings. Hence, one is to configure this process properly to get the maximum results. Read on to find out how to do it right.

Retrospective: 5 steps of a well-build process

As a rule, the retrospective starts with the “opening” phase, which helps commit a team for the working mood. Each participant can calmly and constructively express his or her opinion to find the optimal solutions together with other team members. Since gamification has a positive effect on the retrospective results, warm-up techniques and game elements are often used.

At the phase of gathering opinions, each participant is invited to recall the past period (iteration, release) and answer three questions:

• Which tasks did the team cope with successfully?
• Which tasks execution was not effective?
• Which issues can be tackled?

This is the most common option, but there are others. For example, the Starfish approach suggests dividing all activities into five categories and communicating on each one: what you should start doing, stop doing, keep doing, do more of, and less of something.

The overall picture becomes transparent after collecting and processing feedback from all team participants. The stage of gathering opinions helps identify the strengths and weaknesses of the processes, determine true team values, and evaluate the socio-psychological climate.

The 3rd step is the longest one, as it implies discussing each problem and generating ideas for solving them. However, before proceeding directly to the search of the perfect solutions, it is worth focusing on the most important project difficulties and discarding the minor ones.

Throughout this stage, we often apply for voting practices to define core issues. Each participant chooses from one to three points that he or she finds the most important on the project. The number of votes depends on the size of the team and the amount of the information collected at the previous steps.

The problems with a large number of votes are recognized to be high-priority. Then, the team focuses on their discussion and tries to find the most profitable solutions, normally in the brainstorm format.

After the discussion, the moderator of the process draws up an action plan where each problem with priority has an appropriate set of specific steps to solve it. It is important to determine the responsible person for each item in the plan and set a deadline for each step.

The last stage is about closing the retrospective, thanking all participants for their contribution to the processes improvement, and ensuring that all the results are documented. You can use any convenient tool to record the comments. The main thing is to care about each participant having access to all materials and artifacts of the retrospective.

6 rules for increasing retrospective efficiency

Usually, the retrospective lasts from 1 to 3 hours, depending on the size of the team and the iteration duration. To increase the efficiency of the event, participants should prepare their comments and ideas for improvement in advance.

Make sure the retrospectives do not become a routine, and the team is motivated for a constructive discussion and a joint search of the good problem resolving. For example, you can use such practices as voting to select Captain Sprint, a person who performed best during the Sprint; a discussion based on the Six Hats method; gamification with Lego, and others.

Proper management of the discussion helps participants not to go aside from the goals of retrospective and spend time productively. The ability to defuse the situation and solve conflicts allows everyone to speak freely and stay within the framework of a constructive dialogue.

In addition, the appointment of a responsible person in charge and discussion of the deadlines for all tasks encourages team members to take retrospective arrangements seriously and make more efforts to implement them.

It is also useful to review the agreements and analyze them (whether they are done/not done, worked/did not work). Therefore, the next retrospective often begins with a review of the action plan from the previous meeting and its update.

Remember that focusing on the project participants’ failures and playing the blame game are not going to work well to find the way. Only a QA team remaining cohesive can achieve better results.

The retrospective is not a miracle cure for all the problems on the project. If implemented correctly, it is a useful tool helping make the QA teamwork more transparent, keeping the positive “climate” in the crew, and identifying the pain points before they turn into a disaster.

Need professional help on the QA-related issues? Contact us!

In the last article of the series, we’d like to cover the benefits our QA consultants experienced after moving from Scrum to the Scaled Agile Framework. Based on our experience of testing software in Scrum and, from now on, in SAFe, we’ll compare the processes and point to the priceless advantages.

From Scrum to SAFe: enhanced speed, collaboration, and predictability

At first, SAFe seemed messy, incomprehensible, and extremely challenging. Mystery of life, so to say. Having no other options but to obey, we got down to work. Days of learning, googling, doing 5 years’ worth of reading up, asking (and answering) questions paid off and in the end we took advantage of the numerous benefits of the new framework.

The most obvious benefits turned out to be the following: synchronized work of all teams and faster delivery of the final product. Let’s have a look at how it was achieved.

To avoid shallow explanations, we’ll use the graphic scheme below. It illustrates the work of the three teams testing software on the project. Scrum is above, SAFe is below.

We hope you remember that for four years almost we were applying Scrum to complete our project goals. As it should be, we organized conventional Scrum events: sprint planning, daily Scrum meetings, sprint review and retrospective.

However, as the number of teams increased, we had to review the entire process and adjust it. It was caused by the customer’s representatives’ desire to participate in all regular events. That’s why we had to defer the sprints start for some days.

This adjustment resulted in the additional week for all teams to finalize all the activities planned for four sprints. Besides, we lacked points of synchronization and didn’t manage to complete end-to-end integration testing and assess the product’s quality before all teams are done.

Only having completed all tests planned for four sprints, we set to the final integration tests and verified the quality of the release product. If it was a minor release, it took us about four weeks to complete integration testing. With the major release, final tests took us about two months.

SAFe helped to change the situation for the better

With SAFe, all teams start and finish sprint activities simultaneously. Synchronization is achieved by the introduction of the intermediate points to sync up (system demo).

Thanks to synchronized work, two weeks of the HIP sprint (check out what HIP stands for here) was quite enough to complete final integration tests. Certainly, if we had to assure quality of the major release, we would allow for more time. Let it be four weeks, it was still two times less than required before.

Put it simply, if sprints started and finished on time and there occurred no obstacles to do the job, the delivery of the shippable product got cut by three weeks.

One last thing

Regardless of scaling, Agile is the same. In large organizations it’s just a matter of making the whole enterprise share the same way of thinking and make everyone feel involved.

SAFe is built in such a way that every person feels valued and invested into the common business. We know the business context, we know the vision of the stakeholders, we collaborate with overseas colleagues and… the Big Picture doesn’t seem to be that messy after all.

Over to you

There are always doubts about the effectiveness of something new. At first, we were thinking that large organization and easy-to-use Scrum don’t mix. After a couple of weeks we made it work on all three levels. We’ve evolved our client’s values and his mindset and managed to keep up our cooperation.

If you are expected to adopt new framework, be it SAFe or anything else beyond your expertise, give it a try! If you give up, a more brave and ambitious service provider will take your place in no time.

Do you have your own tips on how to make SAFe safe, or additions to the article? Please let us know in the comments below.

As we mentioned earlier, SAFe divides the development timeline into a set of five sprints within a Program Increment (PI). However, that is not 100 percent true. There are four full-fledged sprints and a HIP sprint at the tail end of the series.

In this article, we’ll outline the HIP sprint purposes, values, and prospects from the point of view of QA.

What does NOT happen during the HIP sprint?

Ideally, coding and testing should be terminated before the HIP sprint kicks off. So there should be no developing and testing activities during the HIP sprint.

Then what?

The sprint title stands for hardening, innovation, and planning. Each of the components gives us a hint about the purposes of the HIP sprint.

• Hardening: Ensures that all PI objectives are achieved, and technical debt is reduced. Time is given to go through checklists again and demonstrate Potentially Shippable Increment (PSI) to stakeholders.
• Innovation: Provides time for teams to turn up to a hackathon, pitch new ideas, or introduce some innovations.
• Planning: Conducts Retrospective and completes the planning of the next PI.

HIP sprints in QA: no time for innovation. Why?

No doubt, HIP sprints provide great opportunities for creative guys to offer any new ideas and even try to put it in place. However, as for QA, reality is a bit different.

Most often, we use this time to finalize all tests that were left behind in the fourth sprint. The reasons why the tests weren’t complete in time vary: features delivery was halted, the number of defects grew, or there might arise one blocking defect that prevented the team from doing their job.

If the product release is around the corner, the QA team will be busy running final performance and integration tests that couldn’t be conducted before as every team was committed to their own user story.

It goes without saying that developers do enjoy greater opportunities during the HIP sprint.

But nothing is impossible, and we also managed to make time and think about the future. Developing automated scripts with the client’s data is what we were engaged in during the HIP sprint. These tests were launched every time before the service pack was delivered to the production.

Test automation enabled us to save about 30 hours of manual testing every two weeks. Moreover, automated tests help to increase test coverage: now we could apply them for every client, not for the single ones, as we did before.

That’s it! As you see, the HIP sprint is not a myth, but quite a real thing in SAFe. And while there’s no new functionality delivered, it brings great value to the project.

Now it’s your turn to speak up! Have you tried HIP sprints in SAFe? If using Scrum, how do you allow time for hardening and innovation activities? Please share your thoughts in the comments below.

We started talking about Scaled Agile Framework that helps to apply agile methodology across large development teams. SAFe is usually implemented on three levels. 4-Level SAFe is applied when there are hundreds of practitioners involved.

As for us, we’ve been working with 3-Level SAFe and will talk about it.

The 3-Level SAFe is implemented at the following levels: team, program and portfolio. Let’s focus on each of them focusing on what is relevant specifically for QA consulting practice and software testers involved.

Portfolio level

We’ll start with the portfolio level, which is the highest level of concern in SAFe and is the scope of responsibility of the organization’s management staff.

A portfolio is a number of value streams. Value streams budgeting and implementation is discussed at the portfolio level. A Backlog with Business Epics is generated at this level. Software testing and developing teams have nothing to do here so we won’t dwell on it a lot.

Team level

At the team level we deal with traditional agile teams and Scrum processes many of you are aware of. There is a backlog with user stories. When planning a sprint, teams define work and efforts necessary to meet their sprint obligations. Once the two-week sprint is over, the team meets for Sprint Review, or Demo, and demonstrates some scope of functioning software that can be released. Daily meeting also take place.

At the end of every iteration agile teams meet for Iteration Retrospective where they discuss what has been done well, what has not and what ways for improvement can be found. It’s worth mentioning, that developers and QA work side by side to deliver working software of the release quality. As you see, the process is the same as it’s in Scrum. The difference is that the sprint duration is restricted to 2 weeks.

Program level

The program level is where most of the SAFe differences from Scrum lie. First of all, the size of the development team is larger. The whole team is made up of the usual sprint teams that are applied to the ongoing development mission. The whole team in SAFe is called Team of Teams and can be composed of 50-125 specialists.

The goal of the team is to deliver a Potentially Shippable Increment. “Potentially Shippable” is about the quality of the software, not its marketability. It should be free of defects and possess release quality. PSI is delivered during five sprints.

With every next PSI, end product gets more value. Value in SAFe is delivered by Agile Release Trains (ARTs), which is one of the center concepts in SAFe. The more products are delivered at the organization, the more ARTs there will be. In our project there was only one release train.

ARTs: why such a metaphor? Let us make it clear.

Imagine that you are the customer and you have to get from Prague to Moscow by plane. To reach the final destination, you’ll have to tackle some risks and restrictions. You have to choose between the offered data options and align your timetable. You also have to purchase the flight ticket in advance and book a place on the plane.

A plane is said to be the most convenient means of transportation, but it isn’t free of risks either. The luggage can be lost, the flight can be delayed. Of course, it will take time to overcome any of them. In brief, you can’t be sure that you’ll reach the destination when you’ve planned to. This is exactly what stakeholders feel when the product is developed incrementally.

Now let’s imagine another situation. You travel by metro and have to get from one end station on line to the other. You go underground, buy a ticket and take a train. You don’t have to make any preparations beforehand and you are sure that you’ll get to the required station at the time needed because trains come and go regularly. Having missed one train, you’ll take another one in a couple of minutes.

The latest example describes the ARTs’ work perfectly well.

They deliver value regularly (cycles of 5 sprints). As a result, it becomes easier to explain the stakeholders that features that haven’t been implemented in this sprint, will be implemented in the next one. The development process gets more predictability and the product development lifecycle shrinks. The customer should be calm and satisfied as s/he is aware that the release deadline won’t be missed and the end product will look like it was intended to.

So these are the basics of each level in SAFe viewed by the QA team. Next week we’ll answer the question: what are the key differences in product development in Scrum and in SAFe?

If you have any questions left, drop us a line in comments.

Read how our QA team had to replace Scrum principles with those of SAFe (Scaled Agile Framework) upon the customer’s requests and how we managed to achieve win-win results.

The a1qa acquaintance with SAFe started two years ago. A customer, who has been cooperating with us in QA outsourcing for more than 4 years, confronted us with the fact: “As of today, we start working with SAFe, guys.”

However, we had no other options but to obey. We learned the basics, read numerous hands-on articles and started tuning our processes. Looking ahead, we must admit that we did it quite successfully.

To date, we’ve been working with SAFe for almost two years. And our experience is what we want to share. Hopefully, we’ll foretell some of the difficulties that your QA team may come across.

Let’s start with some basics.

When apply SAFe?

Google displayed us the following big picture:

The core thesis about SAFe is that it contains a number of rules and regulations to ensure smooth agile scaling in a large number of development teams.

• Are there multiple software products developed and roles in the project?
• Do you need dozens of approvals to put in place any new suggestion?
• Are there many development teams who are eager to apply the lean-agile approach?

If the answers are “yes” than SAFe is what can be of help.

What are the levels in SAFe?

SAFe basic structure contains three or four levels depending on the specific needs of the company. They are portfolio, program and team levels. The 4.0 SAFe that has arrived this January has introduced the fourth optional level, called the Value Stream that should be applied in companies with over 120 people working on heavy software systems. In teams of 50-125 people (as it was in our case) the three-level structure is more convenient.

To gain a better understanding of every level, let’s take an example of the project and focus on its levels. It’s important to note that the levels will be analyzed from the QA team’s point of view, not the business one.

Let’s imagine that we have to enhance the e-commerce application aimed at selling books. The current functionality of the app is very simple: the customer uses the search bar to find the book he or she needs and orders it. When the book arrives at the warehouse, manager notifies the customer and he/she collects it from the warehouse. Apparently, the app is too simple to be competitive on the market. We need to strengthen it adding some more features that will make it more attractive.

The portfolio level is the highest level of concern in SAFe. The responsibility of the portfolio level is to discover major initiatives (business epics) that would reflect business priorities. Epics can be functional and architectural by nature.

As for our website, the functional epics shall be the following:

1. Organize delivery across the country with the opportunity to follow order processing in a user’s account.
2. Develop an online communication platform for books amateurs.

Architecture epics should be the following:

1. Integration with GIS (geographic information system).
2. System migration to the cloud.

So far it’s pretty easy, we hope. Now we are going down to the program level.

Program level is where business epics are split into features and development team and other resources work on the implementation of the features. A feature is a part of the product that should give some flow of value to the customer or to business.

Let’s split one of the epics on the team’s level. Online communication platform epic can be subdivided into the following features: user’s account, forum, and private messages.

On the team level, every feature shall be reformulated into clear and short user stories that can be estimated and implemented within a sprint.

For instance, private messages feature can be broken down into the following user stories: send messages and get messages and save chat history options. Architecture epics have to be broken down as well.

In such a manner, with every next level, the tasks get smaller in size and their boarder lines are specified. Estimation also gets more accurate.

In the next article, you’ll learn the workflow specifics on each of the SAFe levels.