If you surf the internet for ‘agile project methodology”, you may get lots of web pages explaining a similar set of activities which are /should be followed in Agile projects. Unless you have working experience in an agile project environment, you may imagine what a well-defined and smooth process the agile projects have!!
What if you have really worked on an agile project, would you have the same perspective? Especially if you are a Business Analyst or an Iteration Manager…. ? Those BA’s and IM’s… I know what your answer is and the long explanation about your agile project experience is.. I can imagine even your annoyed faces …
But the Business Analysts who have not worked in Agile projects in your career life before, let me give a brief explanation on how the agile practice varies from organization to organization and from project to project even within the same organization.
I am not going to explain the agile project methodology in this article as I assume you have already read at least few of the hundreds of articles available on the internet (what is the point of writing the same thing over and over again?) Having that assumption.. Here I go explaining two different agile projects I have worked in two different organizations.
You may wonder why only two projects? The reason is I find these two projects have lots of differences in terms of the business stakeholder engagement, nature/ complexity of the business domain, project team size and etc. hence, I find these two projects have customised the “Defined Agile Practice” significantly comparing to the other agile projects which I have worked in.
The objectives of the series of articles are to
• Provide a high-level understanding about the nature of real world agile projects to whom have not worked in Agile projects before ( I mainly focus on Business Analysts and Iteration Managers as those project roles expose to these changes more than the development and Testing team members do)
• Explain some insights which can be inputted when you want to adjust/ customize the Agile project methodology based on the nature of the project that you have to work on.
Enough of Introduction and Vision..Here I go... (Second time!)
Company A – Project A
The business need of the Project A in Company A is to implement three web-based applications, to replace the existing old-fashioned three systems -one for company’s staff, one for company’s existing clients and the other one for the potential clients. The Sponsor has given the full privileges to the Product owner to decide what is needed in which business priority so the end users’ input was light-touched.
Business Domain and the complexity – Sales and Real Estate. I would say the complexity is fairly simple.
Team size – Less than 15 team members consisting of Solution Architect, Technical Lead, Business Analyst (It was me), UX/UI Expert, Development team and Testing Team
Agile practice
Rather than comparing the agile practice in the project with the “written-in-book” agile practice, let me explain how the agile methodology had been used in that project.
As preparing for the upcoming sprint, Product Owner (PO) works with the BA to prioritize the backlog items. As part of this, the left out stories from the last sprints are considered and new items are added to the backlog as Epics, which would be discussed and detailed out later.
Then PO, Solution Architect, Technical Lead, UX/UI expert and BA have the pre-grooming session where the above-mentioned Epics are discussed in detail and a high-level solution is explained by the Solution Architect. With the details came out from the meeting, BA breaks downs the Epics to stories with high-level requirements.
And the Grooming session is held with the development and testing teams along with the above-mentioned participants. BA walks the team through the stories and explains the requirements and UX/UI Expert demonstrates the relevant UI mock-ups. Here come all sorts of questions and suggestions from the development and testing team and even from the other participants by which the 98% of the time, Product Owner changes his mind on the already discussed business requirements hence UX/UI Expert has to change the UI mock-ups and BA has to change the written requirements. It is AGILE!!!!
This grooming session iterates multiple times until everybody is happy / seems to be happy and clear about the requirements and the solution.
Then BA facilitates the Story Estimation session with development and Testing team members. The stories are estimated in T-shirt sizes. The team members individually provide their estimations for each story card and adjustments are made from further discussion to get a shared understanding -> So at the end of the Story Estimation session, we get the T-shirt sizes of each prioritized backlog item (I.e. Potential stories for the next sprint) which everyone agreed.
BA updates the user stories with the story points and PO does the story prioritization for the next sprint.
So.. What is the sprint capacity? Where is the cut-off point of the prioritized list of stories by PO?
Initially, the project was following Kanban approach. The team works on the stories one by one and when there is a set of stories ready to be released to production, the Release happens. -> No commitment of deadlines. However, due to various business decisions, the team was moved from Kanban to Scrum approach. But again … what is the sprint capacity? Don’t know. !!! By looking at the list of prioritized, estimated stories, Technical Lead agrees to deliver a certain set of stories. And the Sprint is started …..
During the sprint, both development and testing team do their respective jobs as usual and daily- stand-ups are held.
At the end of the sprint, Test lead does the Showcase to PO and to BA in which PO point out some changes required and BA notes down the same for future sprints.
And the Sprint Retrospective is held among the team members and action items are assigned to the members if any.
Dear readers.. While I was working on that project as the only BA, I realized so many areas/ activities which could have been improved. I realized the same more and more when I started working in the next company, which I am going to explain you next. Now, Please don’t ask me why I could not change the way the above project was executed because I cannot write those reasons here.. Maybe you can ask the improvements that I seek doing.. again.. it is a different topic and I may write those in a future article. So for the time being, let’s move to the second company/ project.
Please read the Part 2 of this article series.
Author: Dhanu Gunathissa, CBAP