In today’s business environment, high-speed implementation is a must. This applies to all products and services. Suppose you were using an application and got stuck because of a bug: after reporting the bug, you expect the team to fix it as soon as possible. If not, your next move is probably going to be switching to another service.

Software companies want teams working together providing quick and on point solutions to save time and resources, which can only be accomplished by the involvement of all of the teams working on a project. That’s why companies are opting for testing with Agile teams, since it allows for a greater collaboration across teams on a project. 

Agile allows a key collaboration between testing teams and developers which can’t always be accomplished with traditional approaches. It enables testers to share their perspective from the start of the sprint planning; this leads to less bugs during testing and creates a better possibility for sprint delivery dates to be met on time.

Let’s dig a little deeper to understand what this means.

The objective of Agile/sprints/scrum 

Agile methodologies were born as an alternative to traditional software development approaches, like waterfall methodology. 

The following images show the big difference between agile and waterfall methodologies. (Source)

On one hand we can see that the traditional approach (Waterfall) aims to understand user needs and develop a product. After development, testers test the product and report bugs before deployment. The development team then works on them and fixes any errors using the best possible solution. This is progress through phases, one starts only when the previous one ends; this does not create an opportunity for proper feedback or collaboration between testing, developers and users teams.

On the other hand, Agile is mainly focused on performing constant, small deliveries of the product in order for the customer to be able to see how the product advances through the lifecycle. This gives the opportunity for testing to take on a bigger role and to get involved at an early stage of product development and throughout all the lifecycle of the product.

Agile has four important values:

1. The focus should be more on individuals and interactions instead of processes and tools

2. Working software is more important than comprehensive documentation

3. Customer collaboration is more vital than contract negotiation

4. The process should respond to change rather than follow a plan

Testing in sprint planning: The goal of sprint planning

During sprint planning, the team discusses which stories they will focus on in the upcoming sprint based on aspects like priorities, time frame, feasibility, etc.

The whole team involved in the development of the product should be involved, and if additional expertise on specific backlog tasks is required, then stakeholders can also be part of it.

Sometimes, during this meeting, the testing team can take a secondary role since the main focus tends to be on the development of the stories; this is understandable since it will set the start of the sprint. However, the testing team's' perspective can lead to some serious benefits for developers.

Why testing should be involved

One flaw of working in traditional testing (i.e. Waterfall methodology) is that during the test case design phase, although testers receive the requirements, most of the time they don't get access to the software they will test until it is time to begin the test execution phase.  It is well known that there is usually a big gap between what a requirement specifies and the actual software developed. 

This leads to a huge time investment on the testing side to reach out to both developers and users to define how the product works and how it should work in order to define the correct test scenarios and test cases.

Agile methodologies give testers the opportunity to be involved in the development of the product from the get-go. Testers can be involved in the design of the software by working closely with developers to assess and advise on testability aspects.

An Agile tester should understand the relevance of technical skills. A tester is always prepared to contribute to the technical discussions of the team. Their contribution may extend up to code reviews, user stories grooming, and understanding requirements. The Agile Software Tester gets to work with the developers when they are performing unit testing and share the perspective of testing from a tester's point of view instead of a developer's. The tester can work collaboratively and productively with the product owner and the customer to form acceptance criteria from the sprint planning itself. 

Before any user story is sent for development, the tester and other team members can discuss the complete user story with the team members to find out what the customer wants. Having testers collaborate with developers from the very beginning of sprint planning helps to achieve more accurate estimations and to ensure that everyone has some testing tasks as part of their responsibilities

Great testing teams know they need to become an extension of the customer and end user. Testers need to understand the customer's needs: an Agile tester should be able to describe the feature as well as the customer.

Drop us a line for expert advice on testing and all things Agile, we'd love to help your teams achieve their true potential.

Project Managers have a wide range of responsibilities when working on a project: they oversee planning the project, create a schedule and timeline, execute each phase, manage budgets, serve as the liaison among all stakeholders, and also troubleshoot and maintenance, plus whatever other tasks that get added to their plate. As such, a Project Manager (PM) must be very organized and detail oriented. They also need to have great people skills because at the end of the day, this person is responsible for leading the team and communicating with all involved parties.

The Project Management Institute describes the role of a project manager as someone who acts as an agent of change. Someone who “makes project goals their own and uses their skills and expertise to inspire a sense of shared purpose within the project team.”

PMs serve as leaders. Aside from ensuring the project is delivered on time and within the agreed-upon budget, they also encourage their teams and inspire their clients. They need to solve problems as they arise with strong critical-thinking capabilities while also possessing strong communication skills to ensure everyone remains informed, motivated, and onboard.

A good PM delivers a final product on time, on budget while meeting or exceeding client expectations. Tracing projects back to business goals is becoming increasingly necessary for project managers.

All brains on deck

The Agile framework focuses on self-organization and team empowerment rather than defining specific roles, which is why there is no need for a Project Manager in the traditional sense; the role is pretty much covered between all the existing roles.

Anyone who's ever taken an Agile class or training has heard of the defined roles of scrum master, product owner, and development team in the scrum framework, which makes no mention of the Project Manager role. Personally, I have taken five Agile classes from different places and never once have heard the word “Project Manager”. So, where does this skill set belong? Is there really no use for a PM in an Agile setting? Is there nothing they can do to add value to an Agile project?

An Agile organization can- and does- function well without a Project Manager. However, there is a huge potential for a PM skill set to add value to an organization, specifically on large projects. I have worked in QA Testing across various complex projects for the past five years, and it is clear to me that a PM can greatly impact both the journey and outcome of the project in regard to budget and risk management, as well as coordination between multiple scrum teams.

In an Agile environment, a Project Manager can add value by managing key aspects of every project, overseeing budgets, risks, etc., especially on large scale projects for enterprise organizations. Having a Project Manager also frees up the Scrum Master to focus solely on his or her core functions. 

Take, for example, the below chart from Ken Rubin and his article “What Happens to the Project Manager when Doing Agile Development with Scrum?”  While the PM role no longer exists in a traditional sense, you can see how the tasks and roles normally assigned to them still exist within the system, but are spread out throughout the team. As a result, the person who would normally act as the PM, can work very well as the Product Owner, the Scrum Master, or on the Development Team, depending on his or her background and specific skillset.

If you are looking to scale Agile principles within your organization, our team at Praecipio Consulting has you covered. Feel free to reach out to us with any questions!