Impact of Agile on teams’ organization – Analyst role
This change of mindset has risen questions about whether traditional company roles would still be present once the Agile methodology is applied across Celfocus projects. The Agile team is composed of several major roles, including Scrum Master, Product Owner, QA, UX. So, how do Analysts fit in?
In order to work under Agile, Analysts must be adaptable. The multitude of roles that Analysts need to play in Agile demands them to be committed to helping the business solve their problems, meaning that they shall adapt to the business/development process, help in the creation of a process or even adapt to the lack of process.
The focus shall be on the long-term solution because, once the Sprint starts, the development team focuses on the short-term development cycles, but Analysts are already planning and working on the Sprint material ahead. They need to be innovative and challenge whoever needed to define the real business problem behind what is expressed so that the right product is built.
- The “new” role
Traditionally, Analysts act as the link between business and IT. They specify the requirements, help to discover user needs and the solution to address them, as well as support all project activities to guarantee that the agreed solution is delivered.
In Agile, the most conventional idea is that Analysts take on the role of Product Owner. However, this implies that Analysts should represent the product on behalf of the company, making the appropriate product decisions and creating a valid product strategy and roadmap.
On the other hand, in Agile, Analysts can also be perceived as part of the Development team, helping with the grooming of user stories and working closely with the test team to validate the features or components developed.
There are also some cases where Analysts are assigned the role of Scrum Master, using their communication and process improvement skills to manage the team’s work and help them to effectively cooperate.
At Celfocus, Analysts usually play the role of “Value Specialist”, a figure that supports the Product Owner in the definition, writing and grooming of user stories, but also has the knowledge, with the support of the Development team, to perform the technical assessment and break them down into smaller pieces such as tasks.
What really changes? Nothing and a lot.
Nothing because, in Agile, Analysts still facilitate communication between the business and the technical teams and are responsible for the solution assessment, documentation, activities’ planning, etc.
A lot because Analysts need to integrate customer’s perspective more than ever to help define the product roadmap. They also need to capture and apply “real-time” feedback provided by the customer, team, and others. The quick feedback loops among all stakeholders are one of the major achievements of Agile methodology, thus allowing to break down barriers between business and other teams.
Another big difference between Agile and Waterfall methodologies relies on the documentation deliverables. In Agile, the team no longer has the extensive documentation that defines an entire project or work area. The goal in Agile is to find the right balance between documentation and discussion. The process is more customer- and product-oriented than document-oriented, not requiring the formal approval process, typical in Waterfall methodology.
The need for constant change and the demand for delivering fast-paced, customer-oriented and cost-efficient solutions, based on a backlog which is written in the form of user stories that are made available in Jira. User stories are short, simple descriptions of a feature in the perspective of the Product Owner, or the person who desires the new capability.
Analysts must reinvent themselves when writing user stories since the focus is not on the detail of a solution that is already closed and was previously aligned, but on describing the type of user, what they want and why. User stories mirror the Agile philosophy as it strongly forces a shift of focus from writing about features to discussing them, thus promoting interaction between all parties.