so today we have Anana here a principal consultant and an agile subject matter expert based in Toronto and with a wealth of experience in the field she brings unparalleled insights into agile software methodology and its Dynamic applications in the ever evolving landscape of project management thank you so much for joining us yeah good afternoon once again and thanks for having me amazing so we can just get started so the first question is can you give us a little bit of background about yourself educational wise and how you got to the career Journey you are at
today yeah so educational wise I started my career with a bachelor in computer science and then I did my Master's in uh business administration after that I pretty much started uh you know getting into the it space quite early in my career and I have been working for past uh s 17 years into the IT industry I would say yeah so initially started with one of the Consulting big fours when I a Consulting big fors it was obviously not core Consulting that I was working initially more of the technology delivery I would say and then
slowly my career transitioned into working towards project management getting into you know more of the agile space I would say so having said that I think I Advanced my career towards a lot of agile certifications and and that's how I started moving into agile and today I am you know I've completed a lot of agile certifications and I also trained a a lot of folks on scaled agile as well I'm an SPC career has been towards portfolio management product management and everything agile that's what I would say in the last couple of years yeah that
sounds great and are you able to give us a little bit of a brief overview of the agile methodology for someone who might be new to it yeah for sure so agile child methodology is uh something that has evolved over the last couple of years right like earlier uh any organizations or any projects uh that you could have probably imagined they were more following an waterfall approach where they would start visioning a project and they would go through the normal software development life cycle and anything they would start with the requirements then they would go
with the development then they would go with testing and then they would get customer feedback that was how the C methodology worked initially and after that when agile methodology started you know getting into the market that's how a lot of terms like scrum canman scaled agile came into the picture now agile methodology when I say scrum you know scrum is more focused on small agile teams can ban is more focused on anything that has to do with support teams I would say like you create a ticket and then the ticket gets addressed and then you
have scaled agile which is very famous these days uh it's mostly about scaling organizations where not just one team but multiple teams work together to make sure a project is successful so that's how I would summarize how an adile methodology works today yeah that sounds good given that can you share some examples of Industries or projects where agile has been particularly effective sure so looking at it historically I think one of the example that comes to or maybe everybody could relate to is Toyota which is a typical example of how agile was implemented right they
realized that you know the type of work that they were doing it was not scaling up or they couldn't do what they were supposed to be doing so that's when they kind of mve towards agile and they realized that with lean techniques they would be able to complete their work a lot faster scoping the work into several small chunks as opposed to completing everything in a large batch I think that's how Toyota was one of the examples that uh I can think of on the back of my mind that has been successful and agile and
over the years I think all our it Industries as well have been transitioning to Agile like a lot of the banks these days like I work for Capco so most of our clients are catered to Banking and Financial Industries as well as insurance so the trend that we have also seen in the last few years is all our clients are kind of getting focused towards agile so that they could get more customer feedback ahead of time rather than getting into the phase where you know when the final product is delivered to a customer they realize
that that was not exactly how they envisioned their product to be so that's how I think that agile has been successful in the last couple of years and it's going on at a pretty good space yes for sure it definitely seems like a much more efficient way to run a business and particularly project management so specifically how do these roles differ from the traditional project management roles that you would normally see yeah so in typical project management roles you know you would have a project manager and then you would have multiple team members who work
in a team right but aile is more focused on the team like there shouldn't be a manager who should be directing what needs to be done how it has to be done rather it's the team who kind of you know Drive their work towards success it's one team obviously there's a scrum master who kind of motivates the team in achieving what they would be able to you know kind of achieve at the end of one Sprint but it is more focused on a specific team and the team works together collaboratively to achieve what they want
to do at the end of each is how I would just summarize it there's not a lot of direction from the managers I would say it is more about individual teams working together and then completing the work and ensuring that everything has has been met like if it's a development team you know all your codes are checked out everything has been tested and then at the end of each Sprints you have a demo so typically in core agile team would say you would have a scrum Master you would have the business team who would do
the requirements and then you would have a development team which would consist of the developers the testers and then finally you would have your stakeholders to which you would be demoing what you have developed in one Sprint so yeah that was a great answer I feel like you really covered a lot in detail which was amazing to give us more of a good understanding of things so you actually segue into my next question which is do you explain the concept of Sprints a little bit and how they cont contribute to the actual agile project management
process yeah so historically when we talk about the normal waterfall way of doing work right as I was just mentioning earlier as well like you start from the requirements then you get into coding and then you get into testing there are multiple phases right now these type of projects you know the core waterfall methodologies work for projects which runs through over a very very long period of time however when you have agile you can get work done pretty fast and also you can deliver incremental software to your customers at the end of each Sprint now
when I talk about each Sprint it's like you have a huge task that you have to complete you face them into several small smaller chunks which is called iterations and then those iterations are broken into Sprints which is a Sprint can be two weeks a Sprint can be three weeks it also depends like some of the teams go with two week Sprints some go with three weeks so it's again a working agreement between the teams of how they face their Sprints so what typically happens is say you have to develop a software right like you're
developing a front end uh website or something so what you can do is in one Sprint you focus on the requirements and then once the requirements are done you would have a healthy backlog like a product manager or someone who is interacting with the business they would create a backlog and then from there a scrum master and the product manager together with the teams they would decide what are the stories that they would want to bring in in a specific Sprint so once the development is done they would say okay these are all ready these
are ready to be built right now now it necessarily need not be built at that specific Sprint there can be multiple Sprints and everything can go I would say into a test environment or into a user acceptance environment at one straight go because again I think you might think like how can that happen but then these days the tools and Technologies are so modern that you can keep everything in an offline version and then release them all together at one shot so that the functionality is not impacted on the front end and you can still
continue with your work at the backend end and then finally you can deliver everything after say two or three Sprints when everything has been ready all defects any bugs that has been identified has been addressed so that's how typically Sprints work in agile and iterations work okay yeah that makes sense so it seems like even though you're breaking down all of the parts there's so many people that come into play in different teams right so given that how does agile promote collaboration and communication both Within team and for cross functional teams yeah so within a
team I think agile also has the concept of you know you would have a Sprint planning then you would have daily standups I'll get to each of that uh specifically but I'll just say that there are several ceremonies in agile that the team uh kind of goes through it starts with the daily standup where the teams meet on a day-to-day basis just to make sure what they worked on yesterday what they're going to work on today just to make sure that between the teams everybody knows what each and everyone is working on it's more collaborative
so that's how you have the daily standups then you have a backlog grooming I would say so once the team is kind of in a position where they are able to meet uh most of the stories that has been completed in one Sprint the product owner can see if there's any more additional capacity that the team can work through they can pick up something else that is lying in the backlog and they can typically work on it so that is something which comes out of the backlog groom and then you have a Sprint planning in
a Sprint planning session like typically a Sprint planning would be if you have to work on a core Sprint say Sprint two you would typically start planning for it in Sprint zero right like two sprints behind so that the development team exactly knows what they're working on so that's where the Sprint planning comes into the picture Sprint planning mostly covers the development teams the business teams the product teams as well as any any customer representative I wouldn't say like customer Representatives would be part of Sprint planning but they can also be included if there are
any feedbacks required from them so that's the Sprint planning and after that you have a Sprint demo like once a Sprint is completed you demo it to the customers so the customers can see what has been developed and provide any feedbacks So based on the feedbacks the team can see what's missing and then they can adjust that in the upcoming Sprints so that's the Sprint demo and after that you have a retrospective retrospective is where all the team members collaboratively meet together and then they kind of see what has been achieved what they have to
achieve what went well what did not go well this kind of helps the teams to see what can they improve in the upcoming Cycles I would say so these are the typical you know collaborative ways that the teams work on in a more agile way and obviously it helps with collaboration it helps with communication working as a team yeah makes sense sounds like there's a lot that goes into it but it ends up working out at the end of the day so are there any specific tools or practices that you find particularly effective for fostering
this communication within the teams there are specific agile tools that can be used as well sometimes it all depends on access issues as well right like if you work with different vendors you might not be able to collaborate into Microsoft teams or Zoom or anywhere else because every organization has their own way of messaging and everything so we mostly kind of have tools like jir we have Confluence which are more collaborative tools where jir is mostly used for creating stories tracking any anything like in terms of story Point estimation uh these are the kind of
tools that we have and confluences more of documenting what needs to be done what has been achieved or any other documentation that goes in so these are the common tools that are typically used and other than that I would say teams works as well in order to make sure that there's proper communication between the teams but again that could be challenging like for one of my clients that I work currently we work with five different vendors or five different organizations I would say so teams is always not the best way of communication so which is
why we kind of try to follow anything that needs to go either through a common shareon or most effectively through jira and Confluence I would say yeah since there's so many teams and so many people working on these projects there are bound to have some changes happen I guess unexpectedly so is there any specific examples you could think of of times where a project perhaps didn't really go as planned but the agile method allowed for successful adaptation yeah there could be a lot of examples but if I can just think about something specific typically I
would say sometimes you know when the team start working on it say they were trying to bring everything on cloud but when they tried working on the technology part of it they realized that it was not compliance maybe it could just be a software connectivity or a network connectivity so that's when you start facing issues where you see that you're not able to achieve what you had actually planned that this is what we would be focusing on so those are the kind of challenges that come across this is like a typical example I would say
that comes up when you work with a lot of teams sometimes it might happen that a solution which you had kind of anticipated earlier might not work out or there's a technology change like initially when the project plan or when the you know the architecture was created it was created with the thought that this is how this is going to work out but when the teams actually start working on it they realize that that's no longer feasible and then they have to do the due diligence and then come up with some new solution so that
has always been challenging however with agile it makes it quite simple because you're connected to the teams on a daily basis right so maybe the next Sprint they focus on uh identifying a solution with what can be done to fix this and then in the following Sprint or so they can address those gaps okay great that was a good rundown I'm starting to really understand it a lot more now and of course with project management you're always going to want to strive for continuous Improvement all the time so how does the concept of that apply
to these agile projects yeah so continuous Improvement is something that came from the lean methodologies as well right so these days there are more like you have cicd which is kind of a tool that is used across most of the organizations I would say where you don't have to wait on releasing anything to the customers it need not be on the production environment but it can be done on a test environment so so you can keep deploying you see what is working what is not working and then you try to adjust everything to the change
sometimes it may happen that you deploy something to test environment and then you realize that hey this is what we had thought that this would work this way but this is not working so the teams take that as a feedback immediately they try to cater a simple solution with that and then they try to work through it so that's how I would say the continuous Improvement works you kind of develop you relase and then you kind of test and then you realize what's working and what's not working U so that's how I would say in
the Banking and Financial industry that's how we kind of do it there can be different ways that Kaizen can be defined as well I understand that too yeah for sure that makes sense and are there any specific retrospective techniques or practices that your team finds effective in fostering this Improvement yeah so at the end of each Sprints the teams have an retrospective and it is just not within the teams like when there are multiple teams that have been involved as well right it can be infrastructure it can be a platform it can be the front
end teams the back end teams or anything else that you can think of there has to be communication between all of these teams right so we have something like a scrum of scrums I would say which is where all of these teams meet together and then they kind of do a retrospective of what went well what did not go well and what needs to be improved now when we talk about specific retrospective where you find organizations I think that's more of uh you know when you think about scaled agile right I think that's where you
have a retrospective where large organizations work together in a scaled agile format and then after any of the pi planning they kind of do a retrospective immediately to see what went well in the previous uh pi and what did not go well so that kind of helps yeah that was a great answer so it's interesting to see that there's so many different techniques that can work and how obviously every single project is different right so for these larger organizations how do you approach scaling these methodologies yeah so as I was just talking initially like scrum
and can band these are all agile methodologies that work for smaller teams like scrum typically works for teams which are between five to seven team members but there's also a concept of scaling agile these days which is for large organizations like when the organization is core waterfall then they decide that the entire organization is going to be scaling to Agile right and there's a framework that we kind of follow which is the safe framework where you can scale the organization it's not just scaling up one team it's about the entire organization and again like scaling
up an entire uh organization it often starts with changing the mindset of people right and that could be challenging like you cannot change the mindset of organizations in a day or two like to have that you would obviously have to have the management to adapt to the changes I would say accept it that this is how we were working so far and this is how we have to respond to all of these changes that comes as a great challenge these days I would say adapting to something new right like in in any example that I
can think of when we have to do something new it's a change for any of us so typically for organizations as well adapting to something new is always challenging and that starts from you know from a top to bottom approach I would say so first it's about scaling the organization at the management level then you come to the teams I would say so scaled agile has several ways of doing that firstly you could get your organizations to adopt to it by training them on agile that's a basic standard that we follow that's the leading safe
like where everybody goes through training where they understand how it is for organizations to scale and then you go into several discussions as part of these trainings as how iterations work now agile is just about Sprints and how you're delivering incrementally towards each Sprints and finally the end product but then in scaled agile you have something which is called uh planning iteration which is mostly like four Sprints combined into one iteration which is part of one Pi I know I might be talking a lot here but that's how you know large organizations have to plan
because they just cannot go with Sprint planning or a scrum team they have to look at it at a more broader way or at more holistic way so scaling agile comes with changing the mindset adopting the right methodology and then making the teams resilient to those changes I would say and finally delivering the end results yeah for sure no it was very informative so thank you for that and to wrap things up today just a question that a lot of people might have so if they want to learn more about agile methodologies and just learn
about project management in general do you have any resources or certain books perhaps that you recommend yeah so learning about project management obviously there are a lot of open source of information that is available you know on the web for anyone to start knowing about what project management is but then I think anybody who's starting you know to get into the agile space or who wants to get into this space I would recommend that somebody starts with a scrum Master kind of training I would say and then focus on various other aspects like get into
how a product manager works then get into portfolio and then get into release train Engineers so safe offers that so that's the kind of uh trainings that one could take and again there's a lot of Open Source information that's available on the web as well for anyone to familiarize themsel if they do not want to go through core trainings awesome thank you so much well that was a great session we had today so again thank you so much an for joining us it was really interesting and I'm sure everyone has enjoyed it so far thank
you you Tobe
