For the previous installment go here: What is the Agile Practice in Your Project? (Part 1)
I must say that I thoroughly enjoyed working on that project though the project was a nightmare every single day! (Please don’t misunderstand.. I’m not a ghost)
Company B – Project B
The business need of the Project B in Company B is to implement a new system for it’s clients which would provide more advanced features comparing to the existing system so that the Company B can compete with the market. Even though there was only one Product Owner, there were multiple business stakeholders involved in the project depending on the piece of work to do.
Business Domain and the complexity
Financial – Business Banking. I would say the business domain is quite complex
Team Size
The team consisted of a Project Manager, Iteration Manager, Solution Architect, Business Analysts (I was one of those two BA’s), UX/UI Specialist, Development team and Testing team. Development and Testing team speeded out both in onsite and offshore (Outside Australia). Altogether there were 35-40 team members in the project both onsite and offshore.
Agile Practice
Let’s start with the sprint preparation activities. As there were multiple business stakeholders involved in the project, the situation was intense most of the time as each business stakeholder tried to bring their requirements to the table. However, it was always the Product owner and his Boss decided the priority of the pipeline of requirements. We BAs did not involve in those discussions and we were very much happy about that as long as we were informed the agreed list of business priorities in the pipeline on time. The prioritized and agreed list of business initiatives was always up on the wall for everyone to see what is coming next. Having the pipeline of requirements visible to everyone was very important especially to BA’s, as we could work on multiple initiatives in parallel.
Then, BAs and UI specialist started working on the business initiative and as part of requirement elaboration; we conduct first set of requirement elicitation sessions with the relevant business stakeholder(s) and the product owner to gather enough details to conduct the story estimation with the team.
Note: Even though business has decided their priorities, effort estimates always decided whether the piece of work would be implemented or not. So, before starting anything else about the initiative, high-level story points of the initiative was taken from development and testing team leads.
Along with the story estimation, story mapping was taken place which would explain the end-to-end scenario with the help of the UI mock-ups provided by the UI Specialist. The output of these sessions was the list of user stories and the high-level estimation for those stories. (Story points were on 1,2,3,5,8,13,21 points and so on). Please note that those user story mapping and estimation sessions were not straight forward at most of the time as so many hidden, ill-considered requirements were uncovered during those sessions which caused to revisit the requirements back and forth with the business. However, let’s say that we came up with the list of stories and the total story points. Then we presented that to the business. And there we waited and sent “gentle reminders” multiple times to business to get their Go/ No-Go decision to the MVP requirement set.
Most possible scenario was Business said it was over budget -> BA’s, UX Specialist and the team again revisited the list of stories and tried to come up with the ‘minimal version’ of MVP requirements with alternative solutions and story points -> The same was presented to the Business -> Waited for their answer.
Let’s again say that we got the response from them…
Have they asked to proceed on this? NO -> OK. Just forget about it and move to the next business priority and start the same set of activities again to the new initiative.
Have they asked to proceed on this? Yes -> Phew….
Then, BA’s started further requirement elaboration and started story writing. The good thing about that approach was that BA’s would always work only on the prioritized pieces of work and would not spend time on requirement documentation and grooming of any given work which had a potential to be de-prioritised. (Thanks to the BA Line Managers who always insisted us to follow that approach)
Once the user stories were completed, the same were peer-reviewed and then Story Refinement / Story Time sessions were conducted by BA’s with both onsite and offshore team members. This was an opportunity for the team to walk through and understand the business rules and scenarios, clarify their questions and request more information to be included if there are any missing details in the user stories and to confirm the story points they have given before. User stories would be sent to Business Approval only after all the team members are happy about the content of user stories. That sequence of activities supported us to avoid multiple rounds of business approval/ review of user stories.
Starting from user story mapping and estimation sessions to getting the business approval to the user stories process is called making the user stories “READY”. i.e the user stories are ready with the story points for the coming up sprint. Ideally, user stories must be READY by the Sprint Planning session.
During the sprint planning session, Product owner prioritized the Ready user stories for the next sprint. Each sprint had a Sprint Capacity. So at the end of the sprint planning session, everyone knew what would be delivered at the end of the sprint.
Here started the new sprint….
Daily stand-ups were held as usual. And when there were stories ready for UAT, UAT process took place. UAT defects were supposed to be fixed within the sprint and UAT improvements/ suggestions would be considered for the future sprints. Once the UAT was completed with no defects on those features, then the relevant user story is considered as “DONE”. i.e we are done with the user story and no more work to do based on the original requirement.
At the end of the sprint, Sprint Showcase would take place, where all the relevant business parties and the entire team get an opportunity to see new features and provide their feedback.
And then the Sprint Retrospective -> We as a team did not wait until the Sprint Retro meeting to give our input on what went well, what went wrong and what improvements we suggest.. We have a Retrospective Inbox.. a physical box kept in the project area. Whenever we want to scream about the hell we were going through or the things were going very well, we could write those in small pieces of paper and put into the box. Otherwise, who would remember all those things until the Retro meeting??
So that is pretty much about the agile practice which was followed in that project. My personal feeling is that the agile practice had been well customized based on the nature of the project except that BA’s and Iteration Manager had to struggle a lot to avoid the requirement changes requested by the business just before the start of the sprint. The business has misunderstood the meaning of the word “AGILE” and they thought requirement changes are ALWAYS (always means anytime before the requirement goes into production) accepted in Agile projects. Except for that challenge, I think the agile principles have been well customized and practiced in that project.
I hope the above two examples give you an idea about how different the projects use agile principles based on the nature of the project. And I believe this would give you some tips if want to adjust the existing agile practice in your project too. So, the BA’s who have not worked in agile projects before, now you know how the real world agile projects are….
Further, I would like to hear from you how different your project use agile principles too.
Author: Dhanu Gunathissa, CBAP