00:00:10
Hello everyone, welcome to InApp Podcast. I’m here with my cohost Kiran and today we’ll be talking about Agile project management. Now project management can be a very dry topic to some, it’s mostly a process so it may not be that exciting to many. But it is one of the crucial elements of implementing a successful software development project. So we’ll try and make it as interesting as possible. Now to talk on the topic we have with us the Chief Operating Officer at InApp, Mr. Jayakrishnan. He’s a 20+ year veteran of the IT industry and is responsible for overseeing the operations at the InApp development center. This includes managing software development and project delivery. Now he has been a volunteer of IEEE for a long and is currently the Chair Special Interest Group on Humanitarian Technology at the IEEE Kerala section. So Mr. Jayan, welcome to the podcast, we’re quite excited to have you join us.
00:01:09
Thank you. Thank you Sunuja to give me an opportunity and I don’t know how much of project management that I know, but still alright.
00:01:22
So just a quick note before we start on how this session is going to be. This will be a quick Q&A format and we have a couple of pre-source questions now. I’ll start off with the first question and then Kitten will follow up. Then we’ll wrap up with a few of the questions that I have. So my first question is as IT professionals we have heard the term you know, agile project development, Agile project management, but for those who do not know what it is. Can you explain what Agile is and how is it different from traditional approaches like waterfall?
00:01:56
Yes, Sunuja, that’s maybe a good start I can say. So if I go back, a bit of history on project management, modern project management actually goes back to the early 20th century when a person called. Henry Gantt developed a chart that is for represents the project schedule. And a project as you know has a definite start and an end. So it has a schedule. It has a timeline. So Gantt, Henry Gantt developed a chart which is known by his name Gantt chart, and is still being used. Many people for man for representing the project schedules. So that was the beginning of modern project management and during the second half of the 20th century, we have seen a lot of advancement in project management. There are a lot of new methodologies and new forms of representing projects. All came up. Some of the methods like project evaluation and review technique which is PERT and critical path method which is CPM known as CPM have evolved over time and there were other methods like earned value management etcetera. Then in the same. The several project managers who are managing projects decided. And formed a kind of association which is called the Project Management Institute PMI. And they started to release documents on project management which is basically the collection of best practices or organized collection of best practices which is called Project Management Body of Knowledge PM work. So that was the state of project management till maybe towards the end of the 20th century. You can say. However towards the end of that. That is the 20th century and definitely at the beginning of twenty 21st century, we saw a steep rise in the number of software projects which are. Very much different from traditional manufacturing or construction or any other engineering projects. And during this boom in Silicon Valley, there were a lot of small startups developing ideas into products and most of these startups were. Running against time and they were very agile, dynamic people as well as projects. So slowly we have to see started to see the traditional methods of PERT, CPM, or EVM, or any other work breakdown structures or using Gantt charts etcetera, but not fitting very well with software projects. Because software by nature is very soft and you know that soft materials are easy to change, so you can see the amount or the volume of changes happening in software projects are way too high than any other conventional projects, so the software. Managers or software project managers introduced new method or they were started looking out for new methodologies and finally consolidated everything and published a manual called Agile Manifesto which is basically a different way of managing projects which are more suitable for software projects. So this Agile Manifesto lay down the basic principles of Agile project management and most of the software development and services organizations started to practice or follow the Agile methodologies and you have asked me about the basic difference. So the basic difference between agile methodologies from the traditional project management methodologies is that. These are more dynamic compared to the static and linear nature of traditional methods and dynamic in the sense they are more adaptable to changes where the traditional methods are more monolithic and change our kind of methods. So and another major difference is that agile methodologies encourage teams to. Do smaller and shorter cycles and iterate more while progressing with the development. But the traditional methods use very long cycles and less iterations in projects. Those are the major differences and the benefit of shorter cycles is that it can identify the issues or required changes earlier. In the project lifecycle than later. And it is always easier to accommodate changes if you find or identify them earlier in the project lifecycle. So that is what agile methodologies are. That is when the need for agile methodologies came up and that is how it developed. OK.
00:08:34
Now, that was quite a history of project management and you know how it has evolved into an agile approach. Now I think I’ll hand it over to Kiran Kiran for the next question.
00:08:44
Thank you, Sunuja. Hi Jayan. My first question is a very basic question on project management. So can you talk about the kind of projects that are well suited to agile project management?
00:08:56
What are the projects that are well suited to any project? That’s one-word answer? OK, which means most of the new age software projects where the technologies are used are challenging and changing at a very fast pace which also causes or needs to change or bring in change both in the technology as well as in requirements of features where the agile methodologies will definitely. A better so if you consider the projects or products being developed by the startups where an idea they will have an idea that is 80% mature and they’ll start the project or start the development and the rest of the 20% or 2030% will. Get refined as they progress. So inevitably there are changes going to come in the project and that is where agile methodologies of shorter iterations as I said early will definitely be of great help. Having said that, the same methodology, the agile methodologies can very well go with the traditional large. Maintenance projects or rewriting of very large software applications, etc.
00:10:33
OK, so you could say that agile is more focused on adapting to changes that can come in a project. And so if agile is more focused on accommodating changes in the project, do we pay a price in terms of the time and cost it takes for the project?
00:10:49
Yes. In fact, it is far easier to manage time and cost if you use agile than other conventional methods. This is again because the developer as well as the client or the end user of the software product will start seeing the product at very short intervals and it is always easier to accommodate changes if we identify them earlier in the process than later. So in the conventional method, what happens is the user and client, just gave out the requirement. The developer go back, they take their sweet time to come out with an output and they will come up with a completed product in front of the user and they will see that oh this is. Something which is not what I want or these are the changes that I want to make or this could have been better in this way. And finally to make changes the developer will have to completely go back and start from the beginning in many cases. But here what happens is the user is seeing the output at very short intervals. Maybe in two weeks’ time, they start seeing things and it is very easy to change whatever we have done in this two weeks’ time or even 3, three, or four weeks’ time instead of six months’ time. So that is how we manage both time as well as manage cost in agile methodology and I feel that is far easier. Better in Agile than traditional networks.
00:12:54
Yeah, yeah, that’s correct. Agile offers the flexibility to review the product at regular intervals and resolve the issues in the initial project development itself. Now my next question is regarding the progress and success of a project. So how do you track project progress and measure project success in an agile approach
00:13:15
So, In all the agile methodologies, we have very clearly suggested methods to measure progress. So for that let me introduce some of the terminologies like story points, velocity, then burn down charts etcetera. These are some of the tools. Methods are adopted in agile to measure progress. So what are they? So a project is usually split into smaller elements which are called user stories. And what is the difference? Even in the very early times of project management or software development we had function points because software is divided into functions. Then when Agile came in, there is a small change because each of the user features are written as a story which is called the user story, and similar to function points, in each of the stories we assign a story point that defines the size of the story. And now every project will have a set of stories in something called a backlog. Backlog contains the entire set of story user stories and each story will have a story point. Now the developers do what they do for each iteration which is sometimes called a Sprint which will be of let us say ideal length is. Saying like 2 weeks to four weeks and they know the team who are working and they take a few stories for a Sprint, they define these are the stories that we are going to do in a Sprint and how are they defining? They know the capabilities of the people who are working and they know what are the features to be developed and each feature has a size. So then a number of story points the team can handle in a defined Sprint, which is also called the velocity of the team. And depending on the velocity they take the stories from the backlog and fill up and plan their Sprint OK and once you identify the velocity then you know how many stories can be taken and they prepare their. Sprint plan based on the velocity and story points and the stories and now as a progress a chart floated which is called a burned-down chart which represents or which will give you how the project is progressing or how the Sprint is progressing. So these are the different tools that are used in agile methodologies to measure progress. And the best tool is the product itself. So after every Sprint there is something called a Sprint demo By definition that is to show whatever the team has completed to the end-user or the client or whoever is Who all are the stakeholders of the project. So this Sprint demo will clearly show the product and the progress of the work. So that is also very important to have this Sprint demo at the end of each Sprint. So these are the different ways that you can measure progress.
00:17:26
OK. And what about the extent of client involvement in the success of an agile project and what do you think? How involved should they be?
00:17:33
I think client involvement is very critical. And irrespective of the process, that’s what I say. But in the earlier processes or conventional project management processes, what happens is the client is only responsible to define what are the requirements and after that it is the entire project is on the developers and finally the client is only will get the final. Product or the output and then they will get an opportunity to comment and by that time all the errors or all the deviations from the features all must have happened. So in agile, definitely the agile methodologies define a lot more importance to the involvement of the client and the clients are usually. Or definitely should involve while the team is planning their Sprint because the client knows the priority and they can help the team to take which of the stories they should take into a Sprint. And the second thing is the client should be available for Sprint demos, that is at the end of the Sprint when the team is showing. Whatever they have developed in a Sprint, the client has a role to see and comment and do the review and give the feedback. Then there is something called Sprint retrospective which is after the demo. They, the team and the client sit together and see what all went good in this Sprint, what all were not. Up to the mark or requires improvement and needs to change in the next Sprint. All these are decided along with the client. So the client is very closely associated with an agile process during the execution of the project. Yeah, that’s correct. So it’s very important to have good client-team interaction for the success of a project. And my next question is regarding the challenges in project management. Since you have a long experience of managing software projects at InApp, what are the key challenges in project management in the software industry today and how are you tackling them? OK, this is whether it is agile or any waterfall or any other methodology that we use and the challenges may vary from people to people, but to me are my perspective on challenges if you ask. Are three definitely this must be a very common challenge that everybody must be facing which is managing people because especially in software projects we don’t have a lot of missionaries to manage other than a few computers. But it is all depends on the people. So managing people is a challenge. Then technology is Managing technology is another major challenge because technology keeps on changing and if you have a project running for six months, the technology used when you start the project may get obsolete by the time you finish the project. So you will have to selection of technology onwards. It is a big challenge. Then another definitely the nature of the software is change and to manage the change successfully is another major challenge. So these are the three major challenges, managing people, technology, and change. And if you take the first one, managing people, you can see that each individual is different and the. The attitude of people, their skill sets, their likes and dislikes of whether the technology or methods or the time of working everything are different and each of these are important and we will have to satisfy the individuals liking while we allocate work or not just liking their skills, their capabilities. All these will have to be considered, otherwise, they will adversely affect the productivity. So if you manage your work based on the people, the productivity will be very good. So the project manager will have to maintain a fine balance to satisfy all these factors while allocating work to get the maximum output from the entirety. A team is another set of people, so all these are applicable to each and every member of the team. So from my experience the best way to address this is by bringing in maximum transparency and visibility to whatever we do and trying and make it a very participatory process so that everybody needs to agree. And know about the decisions, that’s how you can manage people. And the 2nd on the technology, I would say the technology challenge starts with can say the selection of technology for a project and there personally I would like to use.
00:23:55
The term appropriate technology for a project than the latest or the greatest technology. What is the difference here? The appropriate technology depends on various factors like clients, preferences, people and skills, availability, then terms of licenses etcetera. So the latest or greatest technology may not be considering the client’s preferences because the client will have. Their own platforms are readily available and they would like to do or they may have one person to help them out technically and he will have his own capabilities and skills, in particular technology. So those are client preferences, then our own people, and availability of skills within the organization than some people may have problems with. Software licenses or they may prefer to go with software with some licenses. So all these will have to be considered and this will come or may not come with the latest technology. But that is why may or may not so it can be the latest but I would like to call it appropriate technology by considering all this. The architecture and design also should match with the requirements of the client. So projects should not be used for learning a new technology, rather a learned technology should be used for a project that I consider as a criteria for project success. Then how do you manage change so changes depend majorly on the requirements? If the client clearly knows what they want, then the changes will be less, but that situation will be very less. Then there is another gap. Whatever that client tells, the project team should understand or get whatever that is meant by the client. There can be a difference or gap in there in the teams and understanding. So clients may know the big picture but might not have thought about the final details and there can be some technical challenges on top of that. So there are a lot of reasons why changes are inevitable to an extent in most of the projects and how these can be managed is always a challenge. That is why we use many of these agile methodologies and shorter cycles and client demos, frequent demos to the client. All these will help to manage changes. So these are the three major challenges that are according to me, Yeah, so it’s about managing people, technology changes, and project change requirements, yeah.
00:27:18
OK, great. So I have one more question before I hand it over again to Sunuja. Can you take us through some of the challenges you have had to face when it comes to agile project management and how did you manage it?
00:27:30
That is like that’s what you’re asking about my job, that’s what I do. OK. So there are several projects giving challenges to project managers and project teams and. Or rather, all projects give challenges to the people who are doing the project. But if you ask me for some specific examples, maybe I can quote a recent one where we have provided a team of developers. OK, a team of not just a team of developers, developers and a project manager for A. Particular client for doing a project, and this particular client was also kind of a partner or rather InApp was a technology partner to this client and they were developing a product, software product Okay and the requirements were. Developed are the features which should go into this product but developed by the product product manager from the client side he has a very good knowledge in the domain and he knows what should go into and he developed and he was instructing or passing on that to the team and team is very happy because the product manager knows. What needs to go into the product or what they should develop and what are the priorities? And the project started and the products slowly started to take some shape and parallelly the company started to find new clients for the product and they were signed some. They got some clients and the clients started signing up and they started to show this product through the. Clients some of them bought this and started to use and when they started to use they found that this particular feature is missing or this should have been done in this way or in a different way. So the product manager started to pass that back to the team so the one client will seek some changes. The other client will see some other changes. So slowly as the client number of clients started increasing, the product features also started actually branching out and many different versions of the same product started to come in and the team was finding it very difficult to manage all these changes, all these versions. They don’t know which version goes to which client, which changes to be accommodated in which version etc. And these confusions are growing and this made the team become very frustrated, and unmotivated, and slowly everybody is all stakeholders becoming unhappy in the project. So this is a real situation where we brought in it though it was started or following a kind of Agile methodology or they were trying to follow Agile methodology but they were not very strictly following many of the best practices suggested by the Agile. So we brought a lot more strictness into the process. And add a lot more frequent communications and shorter cycles which definitely help to improve the output and the project. What we did was we kind of divided the features into a lot more smaller tasks and got a very clear understanding of these smaller tasks from the product manager and decided to go with smaller iterations. That is earlier we were going with something like four to six weeks for each iteration, which was brought down to two weeks and started to show to the product manager every two weeks which helped us to bring in a lot more easiness in bringing all the parts. Together to manage the project better. So this is 1 definitely one of the experiences that we have gone through recently and the agile methodologies in its real sense when we started applying helped us a lot.
00:33:24
OK. Thanks, Kiran. Jayan, Now let’s move the discussion to the current situation that we are in now, so with the pandemic going on. We are all working in isolation and you are actually having to manage a very distributed team. So has the approach to gel project management actually changed in your in your opinion? And if so, what changes have you had to make to maintain the progress of your projects?
00:33:54
Fundamentally there is no change because Project is a project and the timeline is a timeline. The team is a team. And features are there in projects and we need to develop. So there is no real change happened in the approach and needs to happen also. So fundamentals putting will remain the same however as we are all now distributed and confined to our homes and not meeting others. It will always be good to increase the frequency of progress reviews even within the team, not with the client but within the team. Otherwise there are a lot of casual meetings happening and you will come to know of the progress which may not happen in this distributed away from office. Kind of situation. So it is always better to increase the frequency of project reviews and the usual morning stand-ups. We can have a lot more detailed reviews once or twice a week that is in between sprints. Do these reviews and this will help to identify any kind of issues that are happening in the projects. Again, earlier than even in a sprint’s length, so that will help to fix the problems.
00:35:45
Yeah, it is definitely, yes, the frequency and also we should see how infrastructure is helping because. Definitely. Now the network speed, the computer speed, and all that are critical for the projects that success or even project communication. So those are also what we need to look at and make available, make it available to the people so that those won’t become a voter-like. In the project.
00:36:21
So I mean you’re talking about communication. So I mean how do you find it? I mean, do you find it? It’s equally effective when you compare it with the face-to-face meetings that you had pre-covered.
00:36:33
I think my experience in virtual meetings so far is good and also effective or I should say more effective.
00:36:45
However, we should also see because. Yeah. For anything we are there on the screen, we can see people and also we will be very productive in meetings because there are lot many meetings organized if everybody is very busy. They will finish whatever they want to do in a meeting and so the meetings are a lot more productive. However, there is a problem. Because of the long hours in front of these screens and video calls, I don’t know, it might generate some fatigue for people and we should encourage everybody to take frequent breaks from work to reduce the stress and strain that may vary from person to person. But I think this is a general thing that people may get fatigued. So another drawback sometimes happens when the people with whom we are talking did not switch on the video. So we lose the personal touch when we don’t see the other person while talking. Because it is not just words that communicate your face, your expressions, your movements, everything is communicating. We are missing if so definitely the video calls can to an extent fill that gap. But here the infrastructure has a big role, so we should see that definitely it does fill the gap. But there are certainly other issues that also we need to address.
00:38:40
Yeah, the lack of, you know, social interaction is actually a major concern.
00:38:46
Yeah, the personal touch in meetings.
00:38:50
Yes, right, right, Okay. So now we have one final question before we wrap up. It’s about developments that are happening in the agile approach. Now we know that these approaches actually evolve with time and as people use it. So what are some of the latest trends that you’re noticing in Apple in Agile project management? And what is more important now than it was some time back?
00:39:18
OK, so as I said in the beginning, Agile got introduced almost 15 or yeah 15 to almost 20 years back you can say, and many people, especially the software project people started to adopt it. The agile methodologies. But there were these large project teams. Let us say there are projects with 50 or 100 people projects. They were still reluctant to switch to agile practices because their timeline will be very long. So there is no meaning for a two weeks or four weeks Sprint because there won’t be anything ready. There won’t be anything to demo, so many of these things will have to be bypassed. So they were not following that. However, the people who were the promoters are pushing for Agile. They found something called Scaled Agile Frameworks which is basically one of the methods called a Scrum. At scale these are. To help these large projects. So that is where the agile methodologies are slowly moving to. So that all projects whether it is small or large can start adopting agile methodologies which is basically the scale to scrum or scaled agile frameworks breaking up of projects into smaller projects and for each project spawn of 1. As a complete project and adopt an agile methodology. Then there can be a integration project which again can be a agile method. So there are clear best practices or return frameworks which is 1 area where the agile methods are slowly moving towards. And also we can see that even non-IT projects have started to adopt agile methodologies. So there also they are customizing agile methodologies to suit their projects. And the main difference that I see between these two is that agile methodologies are outcome driven means the output is a measure. These and the other conventional methods are more practice driven. So that is a cultural trip from a practice driven to outcome-driven process.
00:42:13
All right. So thank you Jain for your time today. I know we have just touched the tip of the iceberg in this and that meant there is much more to be discussed on this topic. So we hope that you will join us again sometime to go a little bit more in-depth into the topic. And so thank you. Thank you again. I hope to see you. See you soon.
00:42:35
Thank you. Thank you. And Kiran, yeah, I enjoyed the conversation, and yeah, anytime. Please let me. Thank you. Bye, bye.
