More
CALL To Film
To Know
-
Getting the show on the road!
Where do Analysts fit in an Agile world?
CALL To Film
—
Sep 2018
In the past year, Celfocus has witnessed a change in delivery methodologies as more and more clients demand Agile.
This change of mindset has risen questions about whether or not traditional company roles would still be present once the Agile methodology is applied across Celfocus projects.
The Agile team is comprised by three major roles: Development, Scrum Master and Product Owner. Depending on the project’s complexity a few more roles might be added to the team such as architect and tester. 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 the 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, in order to ensure that the right product is built.
Traditionally, analysts act as the link between Business and IT. They specify the requirements, help 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 the analyst 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, the analyst 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 the analysts can have 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 take on the “Value Owner” role, a figure that supports the Product Owner in the definition, writing and grooming of User Stories, but also has the knowledge to, with the support of the development team, perform the technical assessment and estimations of the user stories and break them down into smaller pieces such as tasks.
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 is one of the major achievements of agile methodology thus, allowing break down barriers between business and other teams.
Another big difference between Agile and Waterfall methodologies relies on the documentation deliverables. In Agile, we no longer have 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.
With a need of constant change and with the demand of delivering fast-paced, customer-oriented and cost-efficient solutions, documentation 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 have to 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 to describe 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 an interaction between all parties.
To guarantee the success of an Agile project, and to ensure a seamless onboarding by the analysts in these projects, here are some of the recommended best practices:
References:
In the past year, Celfocus has witnessed a change in delivery methodologies as more and more clients demand Agile.
This change of mindset has risen questions about whether or not traditional company roles would still be present once the Agile methodology is applied across Celfocus projects.
The Agile team is comprised by three major roles: Development, Scrum Master and Product Owner. Depending on the project’s complexity a few more roles might be added to the team such as architect and tester. 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 the 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, in order to ensure that the right product is built.
Traditionally, analysts act as the link between Business and IT. They specify the requirements, help 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 the analyst 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, the analyst 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 the analysts can have 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 take on the “Value Owner” role, a figure that supports the Product Owner in the definition, writing and grooming of User Stories, but also has the knowledge to, with the support of the development team, perform the technical assessment and estimations of the user stories and break them down into smaller pieces such as tasks.
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 is one of the major achievements of agile methodology thus, allowing break down barriers between business and other teams.
Another big difference between Agile and Waterfall methodologies relies on the documentation deliverables. In Agile, we no longer have 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.
With a need of constant change and with the demand of delivering fast-paced, customer-oriented and cost-efficient solutions, documentation 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 have to 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 to describe 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 an interaction between all parties.
To guarantee the success of an Agile project, and to ensure a seamless onboarding by the analysts in these projects, here are some of the recommended best practices:
References:
In the past year, Celfocus has witnessed a change in delivery methodologies as more and more clients demand Agile.
This change of mindset has risen questions about whether or not traditional company roles would still be present once the Agile methodology is applied across Celfocus projects.
The Agile team is comprised by three major roles: Development, Scrum Master and Product Owner. Depending on the project’s complexity a few more roles might be added to the team such as architect and tester. 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 the 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, in order to ensure that the right product is built.
Traditionally, analysts act as the link between Business and IT. They specify the requirements, help 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 the analyst 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, the analyst 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 the analysts can have 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 take on the “Value Owner” role, a figure that supports the Product Owner in the definition, writing and grooming of User Stories, but also has the knowledge to, with the support of the development team, perform the technical assessment and estimations of the user stories and break them down into smaller pieces such as tasks.
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 is one of the major achievements of agile methodology thus, allowing break down barriers between business and other teams.
Another big difference between Agile and Waterfall methodologies relies on the documentation deliverables. In Agile, we no longer have 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.
With a need of constant change and with the demand of delivering fast-paced, customer-oriented and cost-efficient solutions, documentation 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 have to 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 to describe 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 an interaction between all parties.
To guarantee the success of an Agile project, and to ensure a seamless onboarding by the analysts in these projects, here are some of the recommended best practices:
References:
.png)
