Getting the show on the road!
Where do Analysts fit in an Agile world?
As delivery methodologies change, what changes and what stays the same?
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.
The “new” role
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.
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 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.
Based on our experience so far, what would we recommend?
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:
- User Stories and Analysis phase should start earlier than development sprints so that the team has User Stories available to create a Product Backlog.
- The Client should prioritize the User Stories in the backlog prior to sprint start. The analyst should support this activity.
- User Stories must be groomed and estimated prior to sprint start, and these should be as simple as possible.
- Estimations are performed in Story Points, a measure of the overall effort needed to deliver a User Story. For the estimation process one can use the Fibonacci Sequence, the Poker Technique or the Scrum Time app. The analyst should support the team in this activity.
- If a User Story is too complex break it down into smaller pieces like tasks, or sub-tasks to detail information relevant for the development of the User Story.
- The acceptance criteria in the User Stories must be clear and well detailed.
- User Stories must contain a definition of ‘Done’ (DoD). DoD is used to validate whether all major tasks and all value-added activities have been accomplished and completed during the User Story development. DoD is not static and can change over time.
- For implementations from scratch, the best approach is to develop a POC with the simplest system that can be deployed. The remaining user stories are delivered with incremental developments over the POC.
- Collect and apply the stakeholder, product owner and team’s feedback as soon as possible so that the following sprints can incorporate an increased knowledge.
Who are we?
Receiving feedback after each sprint is very productive, but also having the development team working side-by-side with the business, sharing their concerns, the why’s and the intention behind each goal, brings a whole new sense of fulfilment to both worlds.
But still..., Agile development frameworks are not a one-size-fits-all recipe. For projects with a clearly defined, closed and known scope, the more traditional Waterfall approach is still the king to beat.
Although a bit sceptical at first, Agile has proven to be a key challenge in my journey as an analyst. The constant feedback loop is a great opportunity to grow not only individually, but also collectively, stimulating and improving the communication and commitment of all team members.
The agile process is not about going it alone. It’s an adaptive process where communication and collaboration of all team members is critical for its success. Agile makes it easy to do a retrospective and learn from our mistakes then move on to the next sprint and do better.
An excellent work method that provides greater proximity to the customer, resulting in a delivery that is in accordance with customer expectations.
References:
https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/the-new-tech-talent-you-need-to-succeed-in-digital
When rating films it's about consensus, not quality.