 Okay, so today's topic of my discussion, the presentation area is the agile leader. So for the success of agile, so most of the agile leaders, so they always, they are responsible in leading the teams and they are responsible, jointly responsible in getting the success. So the main theme of my topic is whether they spend most of the time in developing the people or they should spend most of the time in delivering the solutions. So this is a main theme of the topic. So I have some slides which are in the certain slides in the Pichakucha's concept. Some slides keeps changing automatically and some slides keep, they remain stagnant. So how many of you know what is Pichakucha concept? So for the benefit of others who do not know what is Pichakucha concept, the Pichakucha is a Japanese concept where this animation or for interaction designers, they convey the whole concept in 20 slides. So each slide remains 20 seconds on the screen and they keep changing automatically. So that means when the presentation is done in Pichakucha style, the each slide, the person has to stick for 20 minutes or 20 seconds only. So if we doesn't stick, then automatically they changes out to the next slide. So some of my presentation is in the Pichakucha concept. So whatever I am going to present is out of my own experiences as a coach and as a trainer since last six, six and a half years. So the agenda which I am going to cover is first I will be discussing what are the current challenges in the agile teams because of lack of personal leadership style of agile leaders. So that I have observed in my experience since last six years. So that I will discuss initially first then I will come to what are the different leadership styles so which are available and what kind of leadership style is best suited for agile leadership kind of thing. So I will spend some time on that and then I come to what is the, what is the suggested recommendation based out on my own experience for an effective agile leadership quality. So in my experience what I have found is often agile leaders, you know, so the especially the, let's say the scrum masters, they focus currently in my more towards the lot of micro managing and they focus more on delivering the solution because they are jointly responsible for delivering the success. So I have seen good number of agile leaders spend time in delivering the solution but if they spend more time in developing the people and if they develop a people to develop the solution so that would be more appropriate approach and if they spend most of the time in developing the people then people will develop the solutions. So the agile leaders don't have to spend more time in focusing on micro managing delivering the solutions. So that is something which I found is certain thing that is lacking today. Also I see that especially agile leaders who come from traditional project management background so either they have not been able to understand what is the different style of leadership that is required for agile projects. Either whether they either they have to give one is the lack of understanding of giving the empowerment and autonomy the team. Also I feel there is some sort of a fear among them that you know so if you give more control what happens so there is some sort of a inhibition in such traditional project management people who come from that background. So to give the empowerment and autonomy. So that is something which is I see there is a major improvement area and also I see that you know the agile teams they focus on delivering the work but at the same time when there is a problem so they are not able to look at where is the problem and if there is a problem comes and how to what kind of techniques that are available to solve the problem. So just to give one of my experiences like in one of the project so every sprint they used to have some open issues and so they reached a certain stage where there could not fix so many open issues and they got accumulated and they reached a such a stage that too many open issues were accumulated and when the teams got stuck what to do next so then they were supposed to solve the problem so because they had to proceed further. So when they were asked to solve the problem so they started looking at tightening the testing activities so they felt the testing area was an area that needs to be improved but actually when I observed lot of people were not aware of even to do as root cause analysis if they had done as root cause analysis quickly they could have got the real root of the problem actually the root of the problem was somewhere else so there is insufficient unit testing was not done and maybe one of the reasons when they did the root cause analysis that definition of done was also not identified effectively because of this reason the defects were getting escaped to the multiple sprints so what I see is today the teams are not taught how to solve the problem where to locate the problem and if at all if they locate the problem what kind of problem solving technique like something like 5 I approach mind map mind map approach so certain techniques they are not aware also I see that you know so today many organizations if the organizations have to survive so they always live in constant sense of danger okay so there is a threat for them but you know whether how to in this in this competitive environment so so organizations have to always show some sort of a steady improvement okay so there's no point in thinking a breakthrough improvement so they should show a steady improvement so that can happen through the continuously if there is a improvement visibility so and I often see in many agile teams so the agile teams they don't take these things very seriously keep on spending the time in different iterations but at the after few iterations we really see that there is no a trend of continuous improvements so the whole idea here is the agile teams they look for breakthrough improvements some over expectations and different kind of expectations but actually what is required is if they take one step at a time if they take each iteration as a learning exercise and identify some improvement areas and taking the retrospectives seriously so they can always show some sort of a steady improvement and this kind of steady improvement is very important which always leads for sustainable pace of delivery so showing the sustainable pace of delivery is important it's not that in some sprint it's successful and some sprint is not successful so that is something in some another area where teams teams are not aware how to go about showing the steady improvement okay so for all this the personal leadership style of agile leader is makes great a lot of difference so this leader is help can help in creating an effective agile teams okay so let me tell you explain you certain thoughts of mine about different leadership style so so the leadership styles what I'm going to discuss is inspired from but I got inspired by a book called managing excellence by Bradford so here he talks about the leader can be an expert leader can be a conductor leader can act as a developer of a people okay so so let us see what kind of leadership style is more suitable for agile projects okay so leader has an expert so this person this kind of leadership style is very common for technology kind of roles so where the person is supposed to know be expert at the water technology is working on okay so these leadership style the people the expectation is that person should have more expertise okay and in this leadership style when the leader has an expert he's supposed to solve all the problems okay the all the reporters who are working under this leader say the good they go to him for the problem and he's supposed to give the solution okay and this kind of leadership style is very effective and will become effective when manager or a person who is leading the team is he's supposed to have more knowledge than the report is so in such situation this lead kind of leadership style is very effective okay and this type of leaders they are always highly focused on their work they don't focus too much they don't worry too much about the teams which are reporters which with whom they are working okay so as a result of that there are certain concerns in this leadership style especially in this kind of leadership style when the people who are working with this type of leaders their growth is bit limited because they most of the time the leaders take the decision and leader is an expert and he controls the whole team okay so which is completely against the principle of agile okay and these guys the this kind of leadership style the as such a leader when he is an expert they are all happy when you leave them alone they're happy and they work and they quite focused on their work but they don't worry about other team members leader as a conductor is the most common style which we have seen okay this is like where the coordination becomes very important such places this style is very effective so in this style the the leader as a conductor is going to be the central decision taker okay and he is supposed to coordinate quite a lot of things okay so he will manage multiple teams multiple individuals he is supposed to coordinate across all the departments and sit in this kind of roles this kind of leadership style is very suitable and very appropriate okay and this kind of leadership style they become effective when the organization requires treats the coordination is very much necessary for the peak performance so when the peak performance is possible only through coordination then in such situation this kind of leadership style becomes effective okay and the concerns in this leadership style is that whenever there are some conflicts happens in the team so that it get the conflict can tends to get pushed to the bosses and to fix okay so what are some good leader mates so good leader mates is that the person should be knowing everything what's happening in the department so this is a myth okay so another myth is leader should solve all problems he is like one stop solution provider so which is again a myth so another myth is leader should have expertise in all whatever he is handling which is again it's not possible from a any leader okay these are all good mates okay so let's now come to what is a appropriate leadership style which suits for agile projects the appropriate leadership style which suits for agile projects is a leader should act as a developer of a people okay so the the leadership style of agile leader is such that he should be more as a developer of people so let us see that what are certain things that he will do okay as a developer of people so these leaders they always create a teams which are jointly responsible for the success and they always create an a neuron meant where the teams are empowered okay and the people have helped each other okay so they create a sort of a mutual influence kind of behavior okay so so coming to the certain recommendations suggested recommendations for when agile leader behaves as a developer of people is that the leader when the leader behaves as a developer of people he should provide a lot of autonomy and trust okay so this way this is a fine this is okay I think good number of people know about this but can we expect by giving autonomy the agile teams when let us see the agile teams are new can they start suddenly start delivering everything so and it difficult to expect teams to become self-organized doing themselves committing themselves so as an agile leader when he act as a developer of the people what he should be doing is when the team depending on the teams formation stage let us say team is in when they are new maybe he should start directing the team more and as he keeps directing them when after some stage the team starts understanding each other and when they start understanding each is each other gradually he can move to the role of coaching and he can start change direction rather than self-directing he can start coaching the team and support them and once the team starts working together and when they move to a stage where they can jointly work as an effective team then the leader can trust the team and then he can be quite sure that okay if I give good autonomy now I think definitely people I can I can trust and teams can deliver okay so and they can commit together so it is a culture and it takes time so the agile leader when he acts as a leader as a developer of people he can't expect suddenly to become self-organized time from the day one so it said he has to spend good amount of time to bringing the team to this level and another thing what I observed is so lot of teams when I coach or when I train I see that and they do a lot of agile practices so doing agile practices is more of doing agile okay so there is a lot of difference between doing agile and being agile so being agile is more of a agile mindset so the value of the team comes from this kind the agile mindset what the team exhibits the behavior what the team shows so let's say like example in I've seen like they do they understand what is continuous integration but what's next after continuous integration many teams are not clearly aware so the next thing which once the continuous integration is put in place they should be aiming towards continuous delivery so if there is no continuous delivery if there is no frequent releases available from when the agile projects are happening then actually it is not true agile like example it's a Facebook Facebook does does a code push twice twice a day and if you heard of WordPress in the data in 2010 showed that WordPress used to do 16 product releases per day okay the flicker which was acquired by Yahoo they used to have a release every half an hour okay so how these organizations were able to do it so they were able to do only because of continuous delivery so I what I have seen in my experiences people understands continuous integration but the moving up the chain is not happening that's why I feel that's one of the reasons why they're not able to see the real agile benefits okay also I see when they do the sprint planning so they use their past velocity and past performance things like that and they agree on sprints okay these are some prod backlog items we do it so and they commit to the proator is it sufficient if you ask me I feel that it may not be sufficient it's not just agreeing to the sprint what are backlog items that can be taken in the sprint maybe it would be better a team to have some sort of an objective for that sprint let's say the team is doing add item delete let's say they're adding an item for the wish list for shopping cart functionality and they're developing a wish list and where that add item to the wish list modify the item and delete item to the wish list and assume these three are the three user stories if they just agree on this it's not sufficient maybe at the end of the sprint a basic shopping cart functionality we're ready so if that kind of objective is such in the beginning of the sprint that team is the product owners will get more benefits and also that's I feel is a truly true agile where every iteration or every sprint is an product increment or some sort of value and which goes to the part of the product so that team should spend more time in identifying the effective sprint objective also not just following agile practices I also see that if the teams are taught about certain lean approaches lean concepts it would be very effective to work in the agile projects so as a leader as a developer of people so he should see that these teams are all taught about the lean concepts so example the queue lens if the if your queue length is more it will naturally increases the weight time so weight times are all the queue lengths are bad so more and more the queue length it increases the weight time so the people should be taught how to manage their product backlog cues okay and bottlenecks so bottlenecks always impacts the throughput so team should be taught how to identify the bottlenecks and where is the bottleneck and bring down that bottleneck like example let us say three developers and tester is working on a particular thing so in that case what happens is the when the three developers are developing and only one tester is there so it keeps on the developers keeps developing more and whereas the tester is only one person the heat has less so more and more developers keeps developing that it increases the bottleneck so in such situation it's it's developing more items is not good so it's better to manage such kind of activities through the WIP limits so that is something which the teams can can experiment and can use in their work and also you know certain things causes delays the delays are always bad okay like let us say the time taken for a tester to test the bug and from the developer that itself takes one week and whereas testing that bug takes just a half an hour and that one week is a non-valuated activity so that's a waste so the team should be taught how to identify the waste let's say the developer the code is untested and it is not integrated so that's a waste so more and more such codes are left like that it contributes to the waste and waste are always creates delays so team should be taught how to do the remove this waste so that the lead time gets reduced so that so one of the technique could be like value stream mapping so if the teams are taught how to do the value stream analysis okay that would be effective okay and also the agile product development so many teams are not clear about what is the agile product development requires okay so agile the product development for a well-established organization and start development for a startup is different the kind of let's say minimum viable product MVP so when the MVP the approach used to for identifying MVP MVP for startup will be different from how to go about identifying MVP for a well-established organization so that kind of the clarity should be there for the team so depending upon the situation they should know what kind of strategy should be used for identifying MVP okay so lastly finally I also see that you know when the teams are working together as a in the beginning they start having good amount of motivation and engagement but after few sprints they lose the motivation and I have seen that that there is not a good amount of engagement so probably because certain sprints they're not able to see some success so that leads to the demotivation the team so as a leader as a developer of people it's not just taking driving the team to go fast at the same time the agile leader should take the team together okay so that can happen when the agile leader is being with the team I see good number of scrum masters they're not with the team they work from the desk so no improvement can be done at the desk okay so unless the person sees through the eyes then only it can happen so the scrum masters or agile leaders have to be along with the teams and see that you know they take the whole team together so so that is it about my topic of my presentation so thank you very much okay okay you need to say that the vendor is not agile and the teams teams are agile okay so even let's say we deploy tomorrow nobody's going to use it's a it's a dead code in the production so still should we just just because you know sake of being agile should we go and do this kind of deployment I think so what that comes to my mind is so it's always better to have some sort of work agreement in the beginning so work agreement between the agile teams and the vendors so these are certain things that needs to be done like example how you identify the definition of done when talking with the product owner and jointly arrive at the definition of done so arrive at some sort of a working agreement so that that is jointly done at the beginning itself and have an agreement so I think that will be one of the approaches that one can use it that would be the very ideal scenario if that happens but but let's say for some practical issues and the practical contract contractual issues that's not happening so it's a taken and it's a little it's a decision from the higher management that you go ahead your way let vendor go their way and they define that okay they gives you these five things you should be all set so you take the resumption and you build your system and then you are forced to do the you know go to the production yeah okay so yeah I think we'll take it I think sure sure the next session is going to start sure sure we can take it offline sure